xsltforms-support

[Xsltforms-support] Authentication problems with Safari

[Conal T. <con...@ve...>]

I've come across a compatibility problem using XSLTForms with Safari 5 
on Mac and Windows. If Safari receives an HTTP authentication challenge 
when it submits an XML instance to a server, it fails to present the 
user with an authentication dialog, and the submission simply fails with 
a 401.

It seems to me that this is a bug in Safari's XmlHttpRequest object - it 
should trigger the browser's normal response to an authentication 
challenge (as other browsers do). I guess that a Javascript client of 
the XmlHttpRequest object is expected to explicitly set authentication 
credentials rather than leave it to the browser.

NB if you open the XML instance directly in the browser (i.e. not using 
an XForm) then Safari prompts the user for a password, and authenticates 
with the server. Once the browser has established an authenticated 
session with the server, then the XForm works fine. So a work-around for 
the problem is to ensure that not only the editable XML instances, but 
also the XForms themselves require authentication.

While I'm on the subject, does anyone have any example of capturing user 
credentials actually in an XForm (i.e. with a "credentials" instance?), 
and then using those for basic HTTP authentication? I suppose one have 
to use the digest() function to encode the credentials, and the 
submission header element to submit it?
-- 

Conal Tuohy
eResearch Business Analyst
Victorian eResearch Strategic Initiative
+61-466324297

Re: [Xsltforms-support] Authentication problems with Safari

[Alain C. <ala...@ag...>]

Hello,

Thank you for pointing at this compatibility problem.

Could you please use a browser debugger to check headers?

A simple Google search already gives interesting directions:

"Update: Travis Estill and David Kleinschmidt reminded me that 401 
responses shouldn't be returned without an Auth header and so a 403 is a 
better response code. This also helps to make Safari behave too." 
(http://www.peej.co.uk/articles/http-auth-with-html-forms.html)

"The solution was that I needed to add 
request.setRequestHeader("Content-Type", 
"application/x-www-form-urlencoded");" 
(http://stackoverflow.com/questions/2188957/user-authentication-with-xmlhttprequest-works-in-ie-not-in-chrome)

-Alain

Le 06/12/2011 01:10, Conal Tuohy a écrit :
> I've come across a compatibility problem using XSLTForms with Safari 5
> on Mac and Windows. If Safari receives an HTTP authentication challenge
> when it submits an XML instance to a server, it fails to present the
> user with an authentication dialog, and the submission simply fails with
> a 401.
>
> It seems to me that this is a bug in Safari's XmlHttpRequest object - it
> should trigger the browser's normal response to an authentication
> challenge (as other browsers do). I guess that a Javascript client of
> the XmlHttpRequest object is expected to explicitly set authentication
> credentials rather than leave it to the browser.
>
> NB if you open the XML instance directly in the browser (i.e. not using
> an XForm) then Safari prompts the user for a password, and authenticates
> with the server. Once the browser has established an authenticated
> session with the server, then the XForm works fine. So a work-around for
> the problem is to ensure that not only the editable XML instances, but
> also the XForms themselves require authentication.
>
> While I'm on the subject, does anyone have any example of capturing user
> credentials actually in an XForm (i.e. with a "credentials" instance?),
> and then using those for basic HTTP authentication? I suppose one have
> to use the digest() function to encode the credentials, and the
> submission header element to submit it?