Errors in mixed (non-)SPNEGO enviroment

[jaroel]

When this plugin is active and I try to access the intranet with a normal browser, I don't get the login form I'd expect. My browser does not support SPNEGO and Plone should show me the cookie plugin's login_form.

If I try to visit the intranet with a browser that is SPNEGO enabled (ie. firefox with 'network.negotiate-auth.delegation-uris' and 'network.negotiate-auth.trusted-uris' set), I get a login for because I'm not logged in (on my machine) as a domain user.

[jaroel]

Using the master branch instead of the pypi released version makes no difference.

[datakurre]

@jaroel Is this still an issue for you? What are you seeing instead of the login form?

I'm getting the actual error message originally triggering SPNEGO challenge...

AFAIK, the issue is that for SPNEGO challenge to work, Plone must return a 401 response with proper headers. It cannot use 302 to redirect you to login form.

However, the 401 response can include some html with redirecting browser to login form with the correct came_from-argument.

@hammertoe Any thoughts or tips for this? I've achieved simple cookie auth login form fallback described above by simply copying login url creation logic from CookieAuthHelper-plugin and locking response body with meta http-equiv="refresh" (so that ZPublisher cannot replace the body with Plone authorization error message). I'll clean it up and post a pull for this soon...

[hammertoe]

The way we’ve done it in a mixed environment is to disable the challenge facet of the spnego plugin. We then register a small .js file to load on the login_form page that it itself manually calls the spnego challenge. The js file includes a redirect to the desired page. ie. if the browser is able to load the linked JS file and do SPNEGO then it will reach the JS redirect away from the login_form. Otherwise the browser just sits on the login_form page.

I’m not sure the solution you describe would work in all cases, ie. if the browser can’t get a Kerberos ticket then I think the user will still be stuck.

-Matt

On 29 Jan 2014, at 13:57, Asko Soukka [email protected] wrote:

@jaroel Is this still an issue for you? What are you seeing instead of the login form?

I'm getting the actual error message originally triggering SPNEGO challenge...

AFAIK, the issue is that for SPNEGO challenge to work, Plone must return a 401 response with proper headers. It cannot use 302 to redirect you to login form.

However, the 401 response can include some html with redirecting browser to login form with the correct came_from-argument.

@hammertoe Any thoughts or tips for this? I've achieved simple cookie auth login form fallback described above by simply copying login url creation logic from CookieAuthHelper-plugin and locking response body with meta http-equiv="refresh" (so that ZPublisher cannot replace the body with Plone authorization error message). I'll clean it up and post a pull for this soon...

—
Reply to this email directly or view it on GitHub.

Matt Hamilton, Technical Director
Netsight Internet Solutions Limited
http://www.netsight.co.uk/matth
Tel: 0117 90 90 90 1 Ext. 13

Registered in England No. 3892180
Registered office: 40 Berkeley Square, Clifton, Bristol, BS8 1HU

[datakurre]

@hammertoe Thanks for your insight.

In our approach, when the browser can't get a Kerberos ticket, the user will see the 401 page from the plugin until browser reacts on meta <http-equiv="refresh" content="0;url=.." /&gt and redirects the user to login_form (with similar url that CookieAuthHelper uses with response.redirect). Then user can login via CookieAuthHelper. The only issue so far has been that when browser sends wrong ticket, windowsauthplugin will raise exception.

But I do like the JS approach, though, because it would completely hide the required 401 response from user.

Is there any more sane way for injecting js into login form than by customizing its template?

[hammertoe]

On 29 Jan 2014, at 14:56, Asko Soukka [email protected] wrote:

Is there any more sane way for injecting js into login form than by customizing its template?

You could register in in portal_javascript with a condition on that it on shows on a url containing login_form? TBH, we’ve normally customised the login_form by this point in a project. But I would really like a nice packaged up default way for this behaviour to work.

-Matt

Matt Hamilton, Technical Director
Netsight Internet Solutions Limited
http://www.netsight.co.uk/matth
Tel: 0117 90 90 90 1 Ext. 13

Registered in England No. 3892180
Registered office: 40 Berkeley Square, Clifton, Bristol, BS8 1HU

[datakurre]

I wonder, would there be notable performance differences in just registering a global viewlet (with similar condition in Python) instead of adding that conditional portal_javascript-entry against? Viewlet could be registered for a custom layer, which would be easy to turn on and off from add-ons with its own default GS-profile.

[hammertoe]

Maybe. I’m not experience enough in the viewlets machinery to know which would be better from a performance point of view.

-Matt

On 29 Jan 2014, at 15:12, Asko Soukka [email protected] wrote:

I wonder, would there be notable performance differences in just registering a global viewlet (with similar condition in Python) instead of adding that conditional portal_javascript-entry against? Viewlet could be registered for a custom layer, which would be easy to turn on and off from add-ons with its own default GS-profile.

—
Reply to this email directly or view it on GitHub.

Matt Hamilton, Technical Director
Netsight Internet Solutions Limited
http://www.netsight.co.uk/matth
Tel: 0117 90 90 90 1 Ext. 13

Registered in England No. 3892180
Registered office: 40 Berkeley Square, Clifton, Bristol, BS8 1HU