I spent a while tracking down and trying to figure out what was going on and why my site wasn't working in production, and it turns out that it looks like the Static Web App service is modifying my request headers.
The authorization header that I am attaching to my request is not the same header that is being received by my function apps. I don't really want to post the tokens here but for some reason my functions are getting a completely different bearer token which is not the one I'm attaching to my requests and sending up.
@m-sterspace This is by design as we internally set the authorization header to proxy calls to functions.
is it possible to send your auth token as a different header and grab it on the Functions end.
@mathewc
Hey, yep, sorry if my first message sounded testy, I had been up too late trying to figure out what was going on and sent it when I was a little grumpy, pre-coffee. Overall I want to express kudos on this service, I am quite enjoying the preview and think this makes a lot of sense as a service.
I had actually just finished implementing using X-Custom-Authorization as a workaround header and it is working as desired, however, is it just the "Authorization" header, or is there a list anywhere of headers that will get modified and should be avoided?
Also, it would be great if this behaviour could be added to the local / debugging runtime (even if it just blanks out or replaces the headers that might be modified with dummy values instead of allowing them to pass through) so that any header issues can be caught locally.
@m-sterspace Thank you for trying out the service and i am very glad you liked it.
Its bad on our end we did not document these details in time for the launch.
@miwebst do you have a list of other headers? I can think of Auth headers being passed in.
Hey,
thank you guys! I was also having trouble with this. Took me some time to find the solution here, but finally I could solve my issue. To understand a problem resulting from different behavior in local debugging and remote deployment is very time consuming for now.
So just wanted to say thank you to both of you and add support to m-sterspace suggestion: A hint in the documentation / a list would be nice, any support or warning for local debugging would be great!
@m-sterspace Thank you for trying out the service and i am very glad you liked it.
Its bad on our end we did not document these details in time for the launch.
@miwebst do you have a list of other headers? I can think of Auth headers being passed in.
Hi, did you alread document this behavior in the meanwhile? Thanks
This should be fixed when using bring your own functions: https://docs.microsoft.com/en-us/azure/static-web-apps/functions-bring-your-own
Is there a way for change the Header that Blazor WASM uses when using Authorization Message Handlers? By default, it puts the retrieved token into "Authorization" (as expected), but if I wanted to put it into "x-mm-authorization" for example to workaround this problem, can I easily override that?
If not, do I need to manually retrieve an access token and then use a standard HttpClient object with my custom header?
Most helpful comment
@m-sterspace This is by design as we internally set the authorization header to proxy calls to functions.
is it possible to send your auth token as a different header and grab it on the Functions end.
@mathewc