https://cypress.io logo
Powered by
Authorization header set in intercept, not in xhr ...
# i-need-help
t
Hello, I have set up an intercept to set a token in the Authorization header like so, in the console.log the header is clear there and the request is being intercepted as expected, however in the network request none of the intercepted requests have the Authorization header set. Looking at a few different resources and it seems like this is the pattern recommended to use to do this, wonder if anyone sees what I can't
Copy code
cy.intercept(`${Cypress.env('API_BASE_PATH')}/**`, ({ headers }) => {
      headers['Authorization'] = `Bearer ${Cypress.env('token')}`;
      console.log(headers);
    }).as('authInterceptor');
I've also tried this way as well, if I do a console.log I can see the header is present, but then in the network request the header is not there still
Copy code
Cypress.Commands.overwrite('request', (originalFn, ...options) => {
  const optionsObject = options[0];
  const token = Cypress.env('token');

  if (!!token && optionsObject === Object(optionsObject)) {
    optionsObject.headers = {
      authorization: 'Bearer ' + token,
      ...optionsObject.headers
    };

    return originalFn(optionsObject);
  }

  return originalFn(...options);
});
h
Its possible you're running into an ordering issue
When you have multiple interceptors that match a given request, they evaluate in reverse order of how they were set. So if you're using an intercept to check if the headers were set by another intercept, that may be why you can't see it.
t
oh, I only had one interceptor active at a time, and the overwrite was written to replace the intercept.
h
Also if you're looking in the network tab of the browser, you won't see it there either. Cypress's network proxy runs in the node process, and that's where the intercepts are evaluated. I'm almost certain of that.
I filed a bug about something related to how intercept affects headers (specifics of the bug are not relevant to what you're seeing) but to reproduce it from the Cypress client, I had to write a little http server that would echo the headers back to me.
Because the changes to request headers happen after the request has already left the browser. It's like: 1. App makes request 2. Browser sends that request to the Cypress proxy process 3. Cypress proxy process handles intercepts 4. Cypress proxy process sends the request to its origin (or not, if stubbed or whatnot) 5. Cypress proxy process receives the response from the origin 6. Browser receives the response from the proxy
t
ahhh ok, I wasn't aware the intercept occured at that point
h
Yeah I don't think most people are, I only know it because I beat my head against a wall for like 2 days trying to find the stray header
t
is that the same case with overwriting the 
request
command as well?
h
I started cypress after intercept was the norm so I am not totally sure
I believe so though
Oh wait I’m mixing things up
About request
I don’t know in that case but probably
As a rule of thumb, anything related to network requests in Cypress has its meat in the node process
t
good to know, wasn't actually aware of that before. Seeing these requests in my api now with the bearer though, so I think I'm actually good
just kind of odd to verify when you're unaware lol
thanks for the info!
h
Yeah definitely odd to verify, glad to help!
5 Views
PreviousNext
Powered by