I have a number of sites using Kohana's session handler set to use database sessions. Everything works fine until I turn on Resource Tracking in Safari's Web Inspector. After enabling resource tracking, the page refreshes (normal), but then if I refresh the page twice I get logged out. From what I can tell, the session id/key changes therefore it has no session. Upon watching the storage/cookies area, I can see the session id cookie change immediately.
I haven't been able to reproduce similar behaviour in any other browser, including Chrome (Webkit).
Any ideas what might be causing this?
This appears to be fixed in Safari 5.1, so in other words, no longer an issue. Still love to know why it was happening (in case there's another issue), but for now it's resolved.
Related
I develop a site where certain pages a user can only access when he is logged in.
For certain requests I would be better when I open new window. Mostly I use the session to store data including the user data.
To open a new window I use:
ScriptManager.RegisterStartupScript(this, typeof(string), "OpenWindow",
"window.open( '~/smsftd1', null,'height=400,width=600, status=yes,
toolbar=no, menubar=no,location=no' );", true);
It opens the window and it looks how I want it and how it should behave. The only downside is that all data I have saved with the session variables are gone.
If I redirect in the same pages or even open a new tab it works fine and all session variables are available.
When I search for the issue it was pointed out it is an IE issue (older versions). I changed the settings in the IE browser settings but it did not help.
The main issue is that I loose the authorisation the user made.
At the moment I removed to opening of a new window and just redirect.
If someone has done this I wish to know so I can organise a better flow.
The only option I could think of is storing data in a cookie instead of the session.
Any feedback please?
There is no direct answer, but you can check with fiddler or trash tool in firefox.
Please increase your session timeout.
Also check in global.aspx, that there is no event call when new window open.
The best thing is fiddler to check where you all history show about what are the cookie/session variable, link to redirect etc.
Please this link before doing anything.
After a few window.open calls my ASP.NET session times out
http://bytes.com/topic/asp-net/answers/287080-session-variable-window-open
Keeping ASP.NET Session Open / Alive
Add in web.config and try(reference from above link)
"<httpHandlers>
<add verb="GET,HEAD" path="SessionHeartbeat.ashx" validate="false" type="SessionHeartbeatHttpHandler"/></httpHandlers>"
I have a problem with saving session data with IE9. When users login the session is saved correctly. Now, if they browse through the application, the application stores the pagehistory into the session data (I use this for the applications back button). Unfortunately IE9 does not always save this data into the session (sometimes it does and sometimes it does not). It works perfectly with other browsers.
If you are using PHP, try adding a header like:
//vfranchi - necessary to IE8, so it won't throw a warning
header('P3P:CP="This site does not contain a P3P policy."');
I think this is related to IE8 not saving cookie information when the site doesn't have a explicit privacy policy. I had the same problem and that fixed for me.
Remember this statement needs to be before any output just like session_start()
Solved it by switching off IE8 compatibility mode.
I have a strange caching issue going on with IE9. The other day I set up a new website on my IIS server that was NOT running HTTPS, unfortunately I accidentally setup a redirect to HTTPS if you entered in HTTP. So because I didn't have it setup, the webpage didn't load becasue no HTTPS was running. I subsequently fixed the issue in IIS, and when I hit the web page with browsers other than IE9 it seems to work fine. For some reason in IE9 it just wont load the webpage (I think it is still trying to hit it on HTTPS).
I have tried clearing all temp files/cookies etc.., rebooted and still no luck. The only way I have been able to get IE9 to hit the web page was by going into 'F12 Developer Tools' and turn on "Always refresh from server" under the 'Cache' menu option. As soon as I turn that on it starts working. I turn it off and I cannot hit the website again.
Is there some other cache for IE9 that I don't know about that doesn't get cleared through normally processes?
I have a problem similar with yours. I fixed it by adding a random number in URL. Just like this: .....Index.asp?random=3283237431, hope this can help you.
I’m investigating a bug in my MVC3/.NET 4 site which runs on IIS7.5 with integrated pipeline that only manifests itself when accessed using IE6.
The process in pseudo is:
Browser requests Page A; server sets
a Session[] value and responds with
the page.
Enter data onto Page A and
http post the form back.
Server tries to get value out of Session[]
previously set in (1) but returns
null >> but only in IE6, 8(.
In IE7, IE8, IE9, Firefox 3.6, Safari 5.0.3, Chrome 10 the same code works without change.
In my global.asax code I put a Session_Start handler in and noticed some strange behaviour.
In IE6 this handler is fired upon every request made BUT the Session.SessionID value remains the same. All the other browsers mentioned above only have this handler fire the first time they make a request. So for IE6 even though the session ID is the same each time it is called it would seem that the fact that it is “start”ing a new session seems to have the effect of clearing the data for the Session ID and starting it again hence the null value.
One theory I had was that because some items on the page (images etc…) would be accessed with HTTP whilst the page itself is HTTPS could be why IE6 is causing this behaviour (new session per protocol perhaps?) but I turned off the code that forced HTTPS to be used on the page in question, so all requests would be HTTP. Unfortunately the same behaviour is still observed on IE6.
After a lot of Googling I found things that said stuff like underscores in the domain can cause this (no underscores present in mine), ensure IE6 is accepting cookies (my test VM was set like to accept all session cookies).
Finally in a last ditch attempt:
I turned every privacy and security setting I could find in IE6 to as low as it would let me
I added my test site (http://<my machine name>/MyApp) to the list of trusted sites
Clear temporary internet files and cookies
Still I get the same issue. I have thought of a way to fix it that involves not using Session for this case but I would rather not make changes due to IE6 when it works in all of the other browsers including decendant versions of IE.
Edit: Some further testing on another page and when accessed via IE6 the session value is correctly retrieved after being stored by access to another page. More specically:
Working Page - Search:
Do a search, results are display and
criteria are stored in session.
Click on one of the results to view it, details page gets criteria in order to build querystring for breadcrumb trail link.
Failing Page - 2 stage login:
Go to 1st stage login page, enter username and password, assuming correct store encrypted http only cookie value with username in.
Redirect to 2nd stage login page, store 3 index values (List<int>) into a "secret" word in Session
Enter 3 characters from a secret word and post back.
Access session to get 3 index values - get nothing.
The reason for the failure is evident due to the observations made in the more generic description above. This is just getting weirder by the minute (and more frustrating).
I'm using session-based cookies with my website. To my complete surprise, I noticed if I set a session cookie (not a persistent cookie), close a tab, and then reconnect to the site, the session cookies are still there. That's not what I would have expected, actually. I would have expected the session cookies to be deleted.
If you close the browser, a session cookie is deleted, so why not closing a tab to have the same result?
Therefore, I'm using PHP5 and jQuery. Is there anything I can do such that when a tab is closed I can fix this session issue? Unfortunately the onbeforeunload event on the BODY tag is not useful here because when you click away from a page it fires that event, not just closing a tab.
The session cookie is per-process not per window. So even if you selected New Window you'd still get the same session id. This behavior makes sense. You wouldn't want a user to re-sign in each time they opened a new window while browsing your site.
I'm not aware off hand of any real way around this.
This is by design and trying to change it is a very bad idea. What if a user opens a link in a new tab and closes that? Should the session in the original tab be destroyed? Of course not! This demonstrates why you should not even think about this.
A session ends when the last browser window closes. If you want something else, you:
do not want sessions;
need to make your own "mini-session" infrastructure;
are probably in for a world of hurt and bugs.
Session web storage can be used instead of cookies if you need to depend on tab closure.
You can also write a javascript that detects when a tab is closed and delete the cookie in the javascript
I found a work around.
I'm working in ASP.NET C#. I have a Master Page for all the pages of the site except for the Login page. In the Master Page Sever Page Load event I get the Url of the referring page and check if it contains the root of the the site, if not I redirect to the Login page and since it doesn't have that Master Page it displays.
This works if I try to get to a page from another site or if I enter the Url to the address box of the browser. So if you close the tab and you try to reenter from another tab or reopen the tab, even tho the cookie hasn't been killed you can't reenter the site without going thru Login. This works also even if you haven't closed the tab and your navigating between different sites in the same tab.
This is the code
if (Request.UrlReferrer == null || !Request.UrlReferrer.AbsoluteUri.ToString().Contains("root"))
{
Response.Redirect("~/Account/Login.aspx");
}
When navigating from within the site there's no problem even if you open a link to another page in the site to another tab it opens.
If you want to be additionally sure you can kill the session and authentication cookie in that if clause before redircting to the Login page.
This won't work when a user navigated to another site in the same tab and presses the browsers back to button because that works on cache and doesn't automatically send a request to the server.
So this doesn't kill the session or authentication cookie on closing the tab, but it can help prevent reentering the site without logging in after closing the tab.