You are here: Foswiki>Tasks Web>Item14445 (18 Sep 2017, GeorgeClark)Edit Attach

Item14445: Excel fails to open a password protected link to Foswiki

Priority: Urgent
Current State: Confirmed
Released In: 2.1.5
Target Release: patch
Applies To: Engine
Reported By: MichaelDaum
Waiting For:
Last Change By: GeorgeClark
During the 2.x development cycle we decided to return a HTTP 401 when rendering a template login page. The reasoning behind this move was that javascript code might use this return code in some way.

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:

  • some javascript application might fail to call a password protected REST endpoint ... I am not sure this really is an issue.
  • 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

-- MichaelDaum - 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.

-- Main.MichaelDaum - 18 Sep 2017

(09:06:49 AM) gac410: There was one -    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:
(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
(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 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.

-- GeorgeClark - 18 Sep 2017


ItemTemplate edit

Summary Excel fails to open a password protected link to Foswiki
ReportedBy MichaelDaum
Codebase 2.1.4, 2.1.3
SVN Range
AppliesTo Engine
Priority Urgent
CurrentState Confirmed
TargetRelease patch
ReleasedIn 2.1.5
Topic revision: r3 - 18 Sep 2017, GeorgeClark - This page was cached on 20 Sep 2017 - 13:52.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License