Authentication failure on some sites

Bug #700041 reported by Allen Lowe
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Midori Web Browser
Confirmed
Undecided
Unassigned

Bug Description

Hi. I am using midori 0.2.4 from the midori/webkit PPA on for ubuntu. This problem exists from many revisions ago, and needs to be addressed sometime:

For some sites needing user authentication, midori does not present an authentication dialog. Eg. myrp.rp.sg, which gets me to my intranet. The error screen I get for this url is shown below.

Thank you for your attention.

------------------------------

(From myrp.rp.sg)

You are not authorized to view this page

You do not have permission to view this directory or page using the credentials that you supplied because your Web browser is sending a WWW-Authenticate header field that the Web server is not configured to accept.
Please try the following:

Contact the Web site administrator if you believe you should be able to view this directory or page.
Click the Refresh button to try again with different credentials.
HTTP Error 401.2 - Unauthorized: Access is denied due to server configuration.
Internet Information Services (IIS)

Technical Information (for support personnel)

Go to Microsoft Product Support Services and perform a title search for the words HTTP and 401.
Open IIS Help, which is accessible in IIS Manager (inetmgr), and search for topics titled About Security, Authentication, and About Custom Error Messages.

Moved from FS: http://www.twotoasts.de/bugs/index.php?do=details&task_id=846

Revision history for this message
Allen Lowe (lallenlowe) wrote :

Comment by Natanael Copa (ncopa) - Wednesday, 16 June 2010, 21:25 GMT+1
can you check if the intranet site requires ntlm auth?
  Comment by Mervin Beng (mervinb) - Saturday, 19 June 2010, 03:31 GMT+1
I believe it does. Can you suggest how I can verify this?
  Comment by Jean Louis (JeanLouis) - Wednesday, 04 August 2010, 18:44 GMT+1
I think that FS#800 is related from 0.1.4 version ...

Revision history for this message
Michael Moroni (airon90) wrote :
description: updated
Changed in midori:
status: New → Invalid
Revision history for this message
Nelson Rodriguez (nelson-ubuntuone) wrote :

Why was this marked as invalid? Today I downloaded Midori browser and tried to use my company Sharepoint site (hosted with IIS and having NTLM authentication) and I could not get in, because the login popup is not presented.
This is a bug.
Or state that NTLM authentication will not (ever?) be supported.

Changed in midori:
status: Invalid → Confirmed
Revision history for this message
Nelson Rodriguez (nelson-ubuntuone) wrote :

This is one site you can try:
https://sharepoint.ngcsoftware.com/

Revision history for this message
gue5t gue5t (gue5t) wrote :

It seems like WebKitGTK+ should support NTLM authentication but it doesn't seem to work in any of the situations I was able to test. From the standpoint of the code in Midori itself, there should be no difference from other authentication methods.

Revision history for this message
gue5t gue5t (gue5t) wrote :

I get a dialog if I add something like "WebKit.get_default_session().add_feature_by_type(Soup.AuthNTLM)" (that's the equivalent pygtk code). I'm not sure if it actually *works* since I don't have credentials for that example site, but I'll keep poking around and see what I come up with. Thanks to mcatanzaro for pointing me to <https://developer.gnome.org/libsoup/2.52/SoupAuth.html#SOUP-TYPE-AUTH-NTLM:CAPS>.

Revision history for this message
gue5t gue5t (gue5t) wrote :

It looks like enabling NTLM auth at all (by adding the feature to the SoupSession) causes Soup to include an "Authorization: NTLM TlRMTVNTUAABAAAABYIIAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAwAAAA" header in every request it sends, which is not how things should work. I had hoped to be able to remove this header by connecting to a signal like "request-queued" on the SoupSession or to "resource-request-starting" on the webview but the header hasn't been added by these points, and calling disable_feature on the SoupMessage at those points seems to have no effect.

I'll have to give up on this for now, sorry. I think it's likely that the best place to fix this is in libsoup itself.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.