Bug 13600 - authorization non working
Summary: authorization non working
Status: RESOLVED DUPLICATE of bug 5809
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 523.x (Safari 3)
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Nobody
URL: http://icalx.com/account.php
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-05 14:37 PDT by ricardo
Modified: 2007-06-23 04:13 PDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ricardo 2007-05-05 14:37:03 PDT
authorization do not work as an example try to login to icalx the panel for authorization do not open.

in the log the following error apear 

2007-05-05 20:41:07.900 WebKit[435] *** Assertion failure in -[BrowserApplication _commonBeginModalSessionForWindow:relativeToWindow:modalDelegate:didEndSelector:contextInfo:], AppKit.subproj/NSApplication.m:3057
2007-05-05 20:41:07.902 WebKit[435] Modal session requires modal window
Comment 1 Mark Rowe (bdash) 2007-05-05 16:03:49 PDT
I'm not able to reproduce this at all.  Can you please provide more information about the steps required to reproduce this?  Can you also verify that you do not have any Safari extensions (sometimes known as "plugins" or "haxies") installed, as they may be interfering.
Comment 2 ricardo 2007-05-06 02:28:23 PDT
(In reply to comment #1)
> I'm not able to reproduce this at all.  Can you please provide more information
> about the steps required to reproduce this?  Can you also verify that you do
> not have any Safari extensions (sometimes known as "plugins" or "haxies")
> installed, as they may be interfering.
> 
In an account with admin privileges works ok, but in a standard even a new one just fresh created  the authorization panel do not open when one try to login. (no haxies or plugins installed)
Comment 3 Mark Rowe (bdash) 2007-05-06 02:32:10 PDT
Without a valid username/password I have no way of knowing whether the authentication is working correctly or not.  It seems quite probable that this is a server-side configuration issue as the few sites that I regularly use with HTTP authentication appear to be functioning correctly for me.  We need more information to be able to reproduce this problem and determine where the issue lies.
Comment 4 ricardo 2007-05-06 12:25:51 PDT
I appologize if i didn´t explain myself correctly. the panel where the username and password should be introduced  do not appear at all.
So no need for a username/password pair if you get to the point where you can  them you are not finding the bug.

(In reply to comment #3)
> Without a valid username/password I have no way of knowing whether the
> authentication is working correctly or not.  It seems quite probable that this
> is a server-side configuration issue as the few sites that I regularly use with
> HTTP authentication appear to be functioning correctly for me.  We need more
> information to be able to reproduce this problem and determine where the issue
> lies.
> 

Comment 5 Brady Eidson 2007-05-06 12:30:01 PDT
That being the case, I still cannot reproduce this.  I'm using a relatively recent ToT build (21272) and visiting the above URL definitely gives me the authentication sheet.
Comment 6 ricardo 2007-05-06 12:33:19 PDT
is some kind of privilages permision problem. giving administrative privileges to an account make disappears the problem
Comment 7 Brady Eidson 2007-05-06 12:53:41 PDT
I understand thats your claim - which is why I tried with a non-admin account.  It worked just fine...
Comment 8 Troy Brandt 2007-06-07 14:49:20 PDT
(In reply to comment #7)
> I understand thats your claim - which is why I tried with a non-admin account. 
> It worked just fine...
> 

I've encountered a page like this as well. 

When visiting: <http://senpef.oceanic.net.fj/> I'm presented with an error page and never see the authentication sheet. 

2007-06-07 14:41:29  Rx <http://senpef.oceanic.net.fj/>
2007-06-07 14:41:29  Rx Status: 401 unauthorized
2007-06-07 14:41:29  Rx Headers:
{
    Connection = close; 
    "Content-Length" = 83; 
    "Content-Type" = "text/html"; 
    Date = "Thu, 07 Jun 2007 21:41:53 GMT"; 
    Server = "Microsoft-IIS/6.0"; 
    "Www-Authenticate" = Basic; 
    "X-Powered-By" = "ASP.NET, PleskWin"; 
}

Comment 9 Alexey Proskuryakov 2007-06-08 04:04:22 PDT
I can reproduce the problem on senpef.oceanic.net.fj, but not on icalx.com. Here are unmodified response headers:

$ curl -I http://senpef.oceanic.net.fj/
HTTP/1.1 401 Unauthorized
Content-Length: 83
Content-Type: text/html
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-Powered-By: PleskWin
www-authenticate: Basic
Date: Fri, 08 Jun 2007 11:00:54 GMT
Connection: close
Comment 10 ricardo 2007-06-09 17:32:24 PDT
I got to resolve my problem.

Seems that some of the nib file in the webCore framework  inside the webkit bundle has gotten the wrong permision with a no-read for unprivilege account.

I hope this could be of help

Comment 11 Troy Brandt 2007-06-12 10:39:52 PDT
I think the problem on <http://senpef.oceanic.net.fj/> is related to or the same as:

http://bugs.webkit.org/show_bug.cgi?id=5809

Someone may want to mark this bug as such since the original reporter has solved his problem. 
Comment 12 Alexey Proskuryakov 2007-06-23 04:13:41 PDT

*** This bug has been marked as a duplicate of 5809 ***