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?