[MAGNOLIA-5721] Magnolia not working in Chrome when HTTP-Authentication is configured Created: 20/Mar/14  Updated: 27/Feb/17  Resolved: 22/Feb/17

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: 5.3.7
Fix Version/s: 5.5.3

Type: Bug Priority: Neutral
Reporter: TLN Assignee: Evzen Fochr
Resolution: Fixed Votes: 1
Labels: devwl, koiinos, support, to-design
Remaining Estimate: 0d
Time Spent: 3.5h
Original Estimate: Not Specified

Issue Links:
causality
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:
Sprint: Kromeriz 84
Story Points: 3

 Description   

When I try access anything (e.g. /xyz.html) on an author system, Magnolia sends the login form instead, which is perfectly fine. However Magnolia sends this with status code 401, which is also correct from a point of view that it shouldn't be 200, but it's still a problem. Just read on.

On all author systems that I have seen live in my career the responsible server admin placed an additional HTTP Basic authentication in front.

This causes the following problem on Chrome:

  • User requests /xyz.html
  • Web server sends 401 and requests Basic authentication as configured by server admin.
  • Chrome displays login box
  • User submits HTTP authentication credentials
  • Web server accepts them, and Magnolia sends the Magnolia login form as 401
  • Chrome sees 401 and instead of displaying the page sent by the server (=login form) it displays the login box again, assuming a previous authentication failure
  • This happens three times, then Chrome says the page can't be loaded.

It works in all other browsers.

I filed this as a Chrome bug, but to my surprise they said the problem is with you, which I understand. They quoted RFC 2616:

10.4.2 401 Unauthorized

The request requires user authentication. The response MUST include a
WWW-Authenticate header field (section 14.47) containing a challenge
applicable to the requested resource.

You are violating this when you send the login form as 401 without including a WWW-Authenticate header, which you are really doing (or not doing) here.

The result is so common from my experience that I'm really surprised that this bug hasn't been addressed yet: All of my Magnolia customers are complaining that their author systems aren't working on Chrome. So, ... I thought I should file this as a bug now just in case you're really still unaware of it.



 Comments   
Comment by Evzen Fochr [ 18/May/15 ]

Dear customer, can I ask you for detailed description of your setup?
From my investigations till now, i guess that you use info.magnolia.cms.security.auth.callback.FormClientCallback in /server/filters/securityCallback/clientCallbacks/form@class ?

Comment by TLN [ 18/May/15 ]

Hi Evzen,

unfortunately this ticket has undergone a surprising lot of changes since you started working on it. I originally filed it for Magnolia 4.5.12, not making any statements about Magnolia 5 in any way. The person who changed it to Magnolia 5 must've had a reason, please ask him or her. The class you're mentioning, FormClientCallback, doesn't ring a bell, according to what I know the problem also happens with a normal 4.5 installation without any customization.

Regards,
TLN

Comment by Magnolia International [ 19/May/15 ]

tln, if you're using a stock configuration, the node Evzen pointed you to (/server/filters/securityCallback/clientCallbacks/form) basically says "use form login". If you're fronting Magnolia with another webserver which forces Basic Auth before it reaches Magnolia, you're gonna have to tell Magnolia about it. What happens when you set the class property in /server/filters/securityCallback/clientCallbacks/form to info.magnolia.cms.security.auth.callback.BasicClientCallback ?

Comment by Magnolia International [ 20/May/15 ]

On second thought, that probably won't help. Can you confirm fronting magnolia with another web server is what you're doing though ? Are both using the same credentials database, or what am I missing?

Comment by TLN [ 20/May/15 ]

Hi Grégory, even IF it would help, it wouldn't be the solution to the problem. Even in "stock configuration", as you call it, Magnolia must not violate the HTTP standard. It does violate the HTTP standard by sending 401 return code without a challenge header field.

Comment by Evzen Fochr [ 21/May/15 ]

Hi TLN, in this case magnolia do not violate HTTP standart. What you get as response from server depends on what you have set in your clientCallbacks. If you set there FormClientCallback, you get login form, if you set BasicClientCallback, you get page with header WWW-Authenticate.

Comment by TLN [ 21/May/15 ]

Hi Evzen, well, FormClientCallback is configured. If I try to open a protected page, I get the login form with 401 response code, but WITHOUT a challenge header. That's a violation of the HTTP standard, which I quoted earlier. I'm 99% sure if Magnolia stops violating the HTTP standard here, the scenario I described will work in Chrome without any further changes. That's all the ticket is about.
(All I just said is still referring to Magnolia 4.5 (4.5.17 in this case). I don't have Magnolia 5 ready to check it there, sorry.)

Comment by Evzen Fochr [ 25/May/15 ]

Dear TLN, if you have set FormClientCallback it means your server is set to use form-based authentication. Form-based authentication is not formalized by any RFC. If you set BasicClientCallback, you set your server to use Basic authentication and you get header WWW-Authenticate in 401 response.

Comment by TLN [ 25/May/15 ]

Hi Evzen, that's correct, form-based authentication is not formalized by any RFC. But HTTP response code 401 is. If you send 401, you must include the challenge, that's what the RFC says. However, your form-based authentication sends 401 without the challenge, that's a violation of the RFC hence, and that's ultimately the reason why the setup I described isn't working in Chrome.

Comment by Jan Haderka [ 12/Aug/15 ]

The problem here is backward compatibility in case of change of response type. As for sending challenge w/ 401 response, issue there is that there is no "challenge" for form based authentication.
This being said, we can only reevaluate this issue and decide on possible change n behaviour in next major version. Until then, the workaround in such setup is to disable form based authentication in Magnolia as well and allow same (basic) authentication as configured on the proxy.

Comment by Evzen Fochr [ 20/Feb/17 ]

We can solve this violation by adding "challenge" with custom scheme, for example named "FormBased" so header will look like "WWW-Authenticate: FormBased".
By this, no login window will be shown like for basic authentication scheme and we will go according to RFC 2616.

Generated at Mon Feb 12 04:07:46 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.