8

Hopefully this is a simple question for someone out there.

Basically upon receiving a request to my MVC controller, I want to:

  1. Add an "Authorization" header to the response
  2. Redirect to another application sitting on another domain
  3. Read the "Authorization" header at this external site.

It appears the act of redirecting, strips out all my custom headers and redirects.

My question, how can I add a new header, AND perform a redirect, AND have that header show up in the headers for the receiving host [at the end of the redirect] to read?

user1265146
  • 1,985
  • 5
  • 16
  • 20

2 Answers2

11

You can't. That's not how HTTP works. First, a "redirect" is just a 301, 302, or (since HTTP 1.1) 307 status code with the Location header set to the URL the client should go to. It's the client that initiates the request to that URL, so you have no control over what headers they send.

Second, HTTP is stateless, so the fact that an Authorization header was sent in some response at some point has zero bearing on anything that happens in any future requests. Web browsers and other HTTP clients skirt around the stateless nature of HTTP by using sessions on the server-side and cookies on the client side. The client sends the cookie to the server with the request. The cookie matches an item in the session store on the server, and the server loads up the data from that session to give the appearance as though state was maintained.

Third, cookies don't work in this situation, because they are domain bound and are not sent along with requests to domains they did not originate from. So, even if you were to create session to maintain the authorization, the other site would never see it.

FWIW, the basic premise here, sharing authentication state with a different domain, is exactly what technologies like OAuth were developed for. So direct future research in that direction.

Chris Pratt
  • 232,153
  • 36
  • 385
  • 444
  • @chrris Thank-you for the very thorough response. I actually am using OAuth, but with a very specific use case where we do not redirect for the login, it is all handeled by the 'trusted app', now I would like to stick the token into the header so that another 'trusted app' could read the claims and process accordingly... all without the redirect to the idP. Alexei mentioned doing it in the client, which is possible because I have the token on the client. I just need to be able to add the auth header and have request fire off in a new tab / window. I assume this is possible? – user1265146 Aug 05 '13 at 16:51
  • 2
    What you're describing is the very thing OAuth and HTTP as a protocol disallows on purpose. It's not *you* who determines what is and isn't a "trusted app", it's the *user*. That is done through authentication with a known entity. Once a different entity is involved, authentication is necessary again because the user has not trusted that new entity. There's no way to skirt around this *by design*. To be able to would be a huge security flaw. – Chris Pratt Aug 05 '13 at 21:53
2

No - 302 redirect are handled by browser and it will not re-attach headers.

Options:

  • server side proxy
  • use cookies instead of other headers (if it is the same domain, not your case per 2)
  • manual redirect client side (may be ok since you are making AJAX call anyway).
Alexei Levenkov
  • 98,904
  • 14
  • 127
  • 179
  • Tell me more about this 'manual redirect client side (may be ok since you are making AJAX call anyway).' – user1265146 Aug 05 '13 at 16:29
  • I like this idea... tell me more about this 'manual redirect client side (may be ok since you are making AJAX call anyway).' I would need to set auth header and have it to open in a new window or tab. – user1265146 Aug 05 '13 at 16:44
  • @user1265146 - "manual" as as get normal 200 response from your server that contains something like `{header:XXXX, location:url}` and make second AJAX request to that location. Now since you probably want to post to other domain you may not be able to make that request at all (unless that other domain supports CORS). – Alexei Levenkov Aug 05 '13 at 18:10