symfony4在api密钥身份验证器中获取标头

Question

i want to pass the API token obtained in the login controller as an HTTP header to allow the ApiKeyAuthentificator to read it using $apiKey = $request->headers->get('apikey'); .

I used to make it work using query parameters but this seems unsafe.

---

• In the login controller

I set an apikey http header before returning the reponse:

$response = $this->redirectToRoute('home');                                  
$response->headers->set('apikey', $data->token);                 
return $response;

• In the home controller

After successful redirection to home, if I var_dump the headers, the header is not set and request->headers->get('apikey') returns null .

However , after redirection, if I open the network inspector and look for the POST request from the login controller, the header is set.

But the header is not set in the GET request of the home, which I guess is why I cannot get it in the home controller using $apiKey = $request->headers->get('apikey');

---

• In the ApiKeyAuthentificator

Same issue. Cannot access the HTTP header using $apiKey = $request->headers->get('apikey');

---

If I set a cookie, I manage to get it in the home controller and the authentificator, why can't I with a header ?

How to correctly set and access an HTTP header using symfony requests / responses, and make it accessible from the authentificator ?

Answer 1

You've misunderstood the purpose of HTTP request/response headers here. Headers themselves are not designed in this raw form, as you are doing, to indicate any kind of session or persistence. HTTP itself is very stateless, with no request being related to any other that comes along.

Your application can, and is, giving a header in its response but there is literally no reason at all why a web browser should include that same header again in future requests for the purpose of linking requests. Only a custom HTTP client/implementation, such as a bespoke native mobile/tablet app, would ever deliberately include an API key/token in HTTP headers directly. (No standard web browser would so this without some beefy Javascript implementation to handle literally all navigation.)

Cookies are exactly what you need here. Typically you don't need to worry about them too, because PHP has session variables of which you can store as much as you like, with a single cookie being used to associate future requests with a set of session variables. (Session identifier cookie, typically named "PHPSESSID".)

The login controller should be storing anything related to the user's authenticated session in PHP's session variables once it has verified the user is genuine. Once that has been done a cookie will be passed to the client web browser with no further action required from you.

--

This explanation is just conceptual though. Symfony being a very complete framework has taken care of this concept for you . The comment // or if you want to use an "apikey" header, then do something like this: is mainly for a custom web client (apps). If your goal is having a custom client side HTTP/web client then it's your job to remember token variables elsewhere in the app's memory, which would not be in a HTTP module as standard.

I think what you may need from the article I linked is specifically the part about storing authentication in the session . The HTTP client will then only need to provide an API key once.

--

As for safety, a HTTP header is no safer than a query variable to anyone smart enough to know how a HTTP request is structured. (This is basic knowledge of HTTP.) This is on par with post variables being no safer than query variables.

• If you're using a standard web browser the only benefit is not seeing the API key in the address bar, but then you should be using a session cookie for these clients anyway rather than an API key in every subsequent request.
• If you're creating a custom web client for an app then the custom header would be visible to someone snooping in on the HTTP traffic anyway just as easily as a query variable.

Enforcing HTTPS is the only way you could effectively hide a custom HTTP header or query variable from traffic sniffers, offering exactly the same protection to each part of the request, and subsequent response.