You are here: Foswiki>Tasks Web>Item14445 (31 Jan 2018, MichaelDaum)Edit Attach

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

Priority: Urgent
Current State: Closed
Released In: 2.1.5
Target Release: patch

Applies To: Engine
Component:
Branches: Release02x01 master Item14288 Item14454 Item14380 Item14537

Reported By: MichaelDaum
Waiting For:
Last Change By: MichaelDaum

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

Foswiki::LoginManager::TemplateLogin::forceAuthentication()

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

Development.Use401ForCookieAuth: the original feature proposal that triggered the change to 401
Item11515: task item covering the FP
Change set that implements the bulk of the feature

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

-- GeorgeClark - 18 Sep 2017

Removed http 401 from template login

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

-- Main.GeorgeClark - 18 Dec 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
Component
Priority	Urgent
CurrentState	Closed
WaitingFor
Checkins	distro:4bd6441340da distro:d9c5e1e57fa8 distro:3f487ae34e83
TargetRelease	patch
ReleasedIn	2.1.5
CheckinsOnBranches	Release02x01 master Item14288 Item14454 Item14380 Item14537
trunkCheckins
masterCheckins	distro:d9c5e1e57fa8 distro:4bd6441340da distro:3f487ae34e83
ItemBranchCheckins	distro:d9c5e1e57fa8 distro:4bd6441340da distro:3f487ae34e83
Release02x01Checkins	distro:4bd6441340da distro:3f487ae34e83
Release02x00Checkins
Release01x01Checkins