Item14445: Excel fails to open a password protected link to Foswiki.
Current State: Closed
Released In: 2.1.5
Target Release: patch
During the 2.x development cycle we decided to return a HTTP 401 when rendering a template login page. The reasoning behind this move
Problem is that Excel is not happy with this kind of behavior: an HTML (login) page that does not return HTTP 200.
When clicking on a link in an Excel sheet pointing to a password protected Foswiki, Excel rejects to delegate this request to
the default browser showing a popup window with an error message of some sort (can't open resource, something like that).
This clearly is an error in Excel, which unfortunately we have to work around in some way.
Analysis: Instead of directly handing over the link to the browser, Excel first tests
the link beforehand, presumably using its own internal client which is not the default browser.
When this request returns anythinng other than a HTTP 200, will it abort the procedure and not
open a browser (tab). This error happens with Firefox as well as Internet Explorer,
whether the user already opened the browser or not, whether the user already authenticated or not.
Therefore, in order to please M$ Excel, we have to revert the change we did to
and return a normal HTTP 200 again.
There are two regressions:
KerberosLogin of LdapContrib has to generate a HTTP 401 on its own again to initiate the kerberos handshake ... This is an issue which will be fixed in the next release of LdapContrib
- 27 Jul 2017
As discussed on the Development.ReleaseMeeting02x02_20170918
we will remove the 401 http status from the template login manager itself. Note that UI::Rest still creates a 401 in case
a REST handler requires authentication. However all of the other scripts don't produce a 401 when using a template login manager.
- 18 Sep 2017
(09:06:49 AM) gac410: There was one - http://foswiki.org/Tasks/Item14445 Excel can't handle the 401 return when authentication required. Task says we should return 200.
(09:07:32 AM) MichaelDaum: yes
(09:07:51 AM) MichaelDaum: reading up on the history of this change I think what we did went a little bit over the top
(09:08:13 AM) MichaelDaum: not that I want to excuse excel for its flaws
(09:08:45 AM) MichaelDaum: but we have to live with excel, and people wanting to link to their wiki from within office documents
(09:09:01 AM) gac410: IIRC the rfc's state that you only can return a 401 if you also include the Authentication header to cause authentication to happen. so i'm not sure we are correct returning a 401 anyway
(09:09:17 AM) MichaelDaum: yes we are
(09:09:39 AM) MichaelDaum: it has got a basic auth challenge in it
(09:10:05 AM) MichaelDaum: point is we don't _have_ to return a 401
(09:10:31 AM) MichaelDaum: note that initially we only were talking about REST calls needing authentication
(09:10:54 AM) gac410: right, and UI::Rest does it's own thing anyway.
(09:11:16 AM) MichaelDaum: hm, where was the feature request ...
(09:11:57 AM) gac410: for the 401 vs 200? I'll have to dig for it again. I remember a long discussion over that a long time ago.
(09:12:39 AM) MichaelDaum: https://foswiki.org/Development/Use401ForCookieAuth
(09:13:02 AM) MichaelDaum: is that the right one?
(09:14:19 AM) gac410: y I think so
(09:16:15 AM) MichaelDaum: the bulk of the changes for this feature is implemented in https://github.com/foswiki/distro/commit/b193c40c72710f8a98586e53992e5df6a2e9215a
(09:16:27 AM) gac410: I hesitate to suggest this but ... as the 401 is "correct" and we are working around an excel / MS bug, I thnk that this should be configurable. :(
(09:17:37 AM) MichaelDaum: my reasoning goes as follows: 401 is only of use for REST calls, but not for any other action, i.e. VIEW
(09:18:14 AM) MichaelDaum: that's the change I'd like to propose: keep 401 for REST but not for the rest
(09:18:41 AM) gac410: well Rest and Jsonrpc (any mechanized login) view login does return a normal html page, so it probably should be a 200 anyway.
(09:19:29 AM) gac410: I've seen a similar related bug on some browsers. Where I would get a "useless" browser login prompt, which I canncel, to then get the template login.
(09:19:50 AM) gac410: It was one of the alternative cell phone browsers which I now can't remember
(09:20:26 AM) gac410: Ah... Dolphin browser. Ages ago when I was using it, I always got a double-login on trunk
(09:21:29 AM) gac410: Apache login will still work ... I hope ... because the login mechanism happens due to the auth scripts match, and foswiki never sees it.
(09:21:53 AM) MichaelDaum: makes sense: the basic auth challenge triggers the browser popup ... just to render foswiki's own ui to log in.
(09:22:37 AM) gac410: y. It was really annoying and I didn't relate it to our 401 response at the time.
(09:23:20 AM) MichaelDaum: note that UI::Rest will trigger its own 401 in case the REST handler requires authentication ... no matter what login manager is configured
(09:23:47 AM) gac410: Right. I think I looked at that last time we discussed this.
(09:24:55 AM) MichaelDaum: so from what I see setting the 401 in TemplateLogin.pm can simply be dropped.
(09:25:17 AM) gac410: I think it's okay go go ahead with this change. *Template* login should return 200 when displaying the login page. Scripts that don't want a html page would continue to return a 401
(09:25:56 AM) MichaelDaum: okay. let's record this decision in the task.
(09:26:07 AM) gac410: Okay. Sounds good.
- 18 Sep 2017
Removed http 401 from template login
- 12 Dec 2017
Reopening - bad fix. We can't just remove the Status header. Need to return a 200. Fixed 2 unit tests that were looking for the 401. Left the old code commented out, as there might be people who have implemented the custom Foswiki authentication mechanism. This will give them a clue.
- 18 Dec 2017