[andybryant]

OmniWeb 5.5sp6 (on OS X 10.4.6 G5) seems to be ignoring temporary 'session' cookies returned by our servers.

Initial request headers:
GET /ibm/console/ HTTP/1.1
Accept: */*
Accept-Language: en
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US) AppleWebKit/420+ (KHTML, like Gecko, Safari) OmniWeb/v577
Connection: keep-alive


Server Response headers:
HTTP/1.1 200 OK
Content-Type: text/html; charset=ISO-8859-1
Content-Language: en
Server: WebSphere Application Server/6.0
Set-Cookie: JSESSIONID=0000e6dWCKIph-pue6RdJAJwnMc:-1; Path=/
Transfer-Encoding: chunked
Date: Thu, 27 Apr 2006 00:03:38 GMT


Next client request headers (should contain JSESSIONID cookie):
POST /ibm/console/secure/logon.do HTTP/1.1
Accept: */*
Accept-Language: en
Accept-Encoding: gzip, deflate
Referer: http://buzz:2966/ibm/console/
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US) AppleWebKit/420+ (KHTML, like Gecko, Safari) OmniWeb/v577
Content-Type: application/x-www-form-urlencoded
Content-Length: 41
Connection: keep-alive


WebKit 13302 correctly returns the JSESSIONID cookie in all subsequent requests (after the initial request). OmniWeb 5.1.3 also does the right thing.

[ebob]

I have not done the detailed analysis, but I have seen the same problem with my new PHP application's authentication system. I'm using sneaky peek 10.

I ran into something a couple days ago. I'm programming in PHP and my authentication/session framework would not work on my local machine where I have apache virtuals tied to names I set up in Netinfo Manager like http://dev/

The cookie was successfully created and everything but was set for 'dev.local' which was not what I was browsing and so my session didn't work. Other browsers set the cookie for just 'dev' and I think this discrepancy is what, at least for me, is breaking my session handling. The same auth setup works fine on a remote server.

Same problem here. I've spend two day debugging what the hell is wrong with my web framework and today I noticed it isn't my framework which is broken. I'm running Twisted Web server on 8500 port at localhost and it's session system doesn't work because OmniWeb doesn't offer any cookies. There's temporary cookie assigned to domain localhost.local.

I've found a simple workaround for this. Edit /etc/hosts and put assing some domain name to 127.0.0.1.

127.0.0.1 foobar.org

[David Shepherdson]

I can add a 'me too' to this bug. We're running a document management system on one of the servers at work, and when I try to log in to it using a server name of just 'web' OmniWeb stores the cookies with 'web.local', which means the system claims I can't log in because the browser isn't supporting cookies.

When I use the full server name (web.internal.company-i-work-for.net), it works properly, letting me log in.

(Safari, on the other hand, works with both server names.)

So this bug is still there in OmniWeb 5.5, I'm afraid.

(I can give more specific details etc. if required.)

David

[byped]

Exact same thing happened to me. I thought I was going crazy and my application was totally broken before I found this thread. The /etc/hosts workaround pretty much makes it a non-issue, but it'd be nice to have this fixed so other don't have to butt their heads against it.

[ianm2]

Yes I have the same problems. I have already reported this a week ago.
http://forums.omnigroup.com/showthread.php?t=1648