Broken handling of temporary cookies
OmniWeb 5.5sp6 (on OS X 10.4.6 G5) seems to be ignoring temporary 'session' cookies returned by our servers.
Initial request headers: [FONT="Courier New"]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 [/FONT] Server Response headers: [FONT="Courier New"]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 [/FONT] Next client request headers (should contain JSESSIONID cookie): [FONT="Courier New"]POST /ibm/console/secure/logon.do HTTP/1.1 Accept: */* Accept-Language: en Accept-Encoding: gzip, deflate Referer: [url]http://buzz:2966/ibm/console/[/url] 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 [/FONT] WebKit 13302 correctly returns the JSESSIONID cookie in all subsequent requests (after the initial request). OmniWeb 5.1.3 also does the right thing. |
Ditto
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.
|
Similar?
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 [url]http://dev/[/url]
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. [CODE]127.0.0.1 foobar.org[/CODE] |
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 |
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.
|
Yes I have the same problems. I have already reported this a week ago.
[URL="http://forums.omnigroup.com/showthread.php?t=1648"]http://forums.omnigroup.com/showthread.php?t=1648[/URL] |
All times are GMT -8. The time now is 07:49 PM. |
Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.