Handling Authorization header when following redirects within the same domain

[crucio-009]

I am working on a use case where a 303 redirect is sending us to a dynamically generated url which sends 401 when the client makes the GET call, we are using the Jetty HTTP Client and I can see that in org/eclipse/jetty/client/HttpClient.java we explicitly remove the AUTH related headers when copying the request. Any ideas how to reattach them when the request lifecycle reaches the GET call?

[sbordet]

You can preempt the authentication for the redirected URL as described here:
https://jetty.org/docs/jetty/12.1/programming-guide/client/http.html#authentication

[crucio-009]

Appreciate the pointer! In our case, each client is property-driven: before we issue the request we already know whether the active scheme is Basic, OAuth, or None. I can therefore resolve the credentials at setup time and register the matching Authentication.Result. My question is whether there's a recommended pattern for doing this dynamically—so whichever scheme is currently configured gets preempted for redirects without risking stale or duplicated headers as properties change. Any guidance on that workflow would be really helpful.

[sbordet]

My question is whether there's a recommended pattern for doing this dynamically—so whichever scheme is currently configured gets preempted for redirects without risking stale or duplicated headers as properties change. Any guidance on that workflow would be really helpful.

I'm not sure what you're asking here, nor what "properties" are.

Authentications are keyed by URIs, so if you have Basic authentication for /cart and Oauth for /login, then the proper authentication header will be added for those different URIs, as the authentication store will be queried using the request URI.

[crucio-009]

We’re building on Jersey with Jetty’s HttpClient underneath. During a POST, the server issues a 303 redirect to a dynamically generated URL. Jetty automatically replays the request as a GET, but it strips our auth header. We checked about AuthenticationStore and can preseed credentials there, yet we can’t predict the redirect URI in advance, security policy picks between Basic or OAuth via configuration, and the exact redirect host/path is only known once we get the 303 back. Because the abstraction layers hide the Jetty client, there’s no straightforward way for the higher-level code that sees the redirect to add the correct Authentication.Result before the follow-up GET is sent. What’s the recommended Jetty pattern for reattaching authentication to such dynamic redirects without manually disabling redirect handling?

[sbordet]

I don't understand.

If you cannot predict the redirect URI, then how can Jetty do it?

Jetty cannot keep the Authorization header if it does not match the URI, because that would be a security vulnerability.