Hi,
I am having challenges to login with Girder available under HTTPS.
Related to the following change:
"Authorization" is a standard RFC7235 header, which is automatically supported
by nearly any third-party HTTP client. Using "Authorization" as the preferred
header makes...
by brianhelba on 11:48PM - 06 May 19 UTC
changed 6 files with 11 additions and 12 deletions.
I don’t understand how I can give both the HTTPS Authorization header and the Girder Authorization headers at the same time. With Girder 2, I believe I had the following headers in my api/v1/user/authentication request and it worked well: Authorization=Basic myHTTPSBase64LoginPwd; Girder-Authorization=Basic myGirderBase64LoginPwd
If I do the same with Girder 3, Girder considers only myHTTPSBase64LoginPwd and it ignores Girder-Authorization
I guess that should be an easy fix server side (use ‘Girder-Authorization’ if available in request headers). However, on the client side, should “Girder-Authorization” be sent if URL starts with HTTPS ?
What do you think ?
Hi Julien,
Just so I understand, the issue here is that you have some front-end layer that requires you to log in via the Authorization header, but you also need a separate login header for Girder, so you’re passing both on the same request? (FWIW, this has nothing to do with HTTPS, all of this is inside HTTP-land.)
I’d be fine to change Girder to look for Girder-Authorization prior to Authorization, but a proper workaround, assuming you have control over the front-end service that needs the Authorization header, would be to configure it to not forward that header to Girder.