[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: |
|
||||
| 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:
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 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? |
| 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, |
| 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. |
| 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. |
| 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". |