What are the different ways of maintaining session in a browser?
Consider a scenario;
I am browsing a secure site in Firefox and the browser crashes. Now when I open the browser again and I do Restore tabs, my previous session is restored back ? Is that handled automatically by the browser OR is it code-based ?
Also can we control session based on tab close vs window close, etc
Is there any connect between maintaining the session at server vs having the same at client side?
What are the different ways of maintaining session in a browser?
Different ways to maintaining sessions are :-
Cookies ( Most Standard way )
Url Rewriting
Html Forms hidden fields
Consider a scenario; I am browsing a secure site in Firefox and the
browser crashes. Now when I open the browser again and I do Restore
tabs, my previous session is restored back ? Is that handled
automatically by the browser OR is it code-based ?
It is handled by browser automatically if it was cookie based, other wise you will manage that.
Also can we control session based on tab close vs window close, etc
On server you can control session just by time, mean when it will invalid, but if you want to do something that will invalid session when close tab then according to me you can bind on close event in javascript and then delete the cookie that was used to manage the session, PHPSESSION ( in php's case )
Is there any connect between maintaining the session at server vs
having the same at client side?
Yup :)
when you create a session actually you are sending a cookie.
Think you are coding in php, and you create a session, now what happens is: a file will be created on the server (file is the default way to handle session in php but you can also change that) and a unique id will also create on server that will represent that session, think you create a session so a file will created with name sjflsj3lrh324l2hjlskdjfl3hl.session and a unique id will also created ex:- sjflsj3lrh324l2hjlskdjfl3hl.
Now when you store anything in session you actually are storing that in this file, and when you will send response to browser, you will also send a cookie on browser and the cookie value will be this id. So next time when you reopen that web, browser will first check if there was any cookie received from this domain before. If yes, then send that with request, and then on server php will check if request contains any cookie with it. If so, then it will check if that name file exists, and if exists mean there was a session. It will then open that file and all variables values that was saved in it will be restored in php variables.
Related
I have a public Apex app and I need a specific page to open in a different session. Not use the same session as the rest of the application.
Basically, I have in Chrome
Tab1 : Page A which requires authentication
Tab2 : Page B which is public
I need both pages to run in two different sessions.
At Page B level, I set "Rejoin Sessions" to Disabled
Now when I run the application, Page B opens in a new tab with a new session as expected, however, it kills the session of Page A and I'm redirected to login.
I'm using an Authentication Scheme with custumized session sharing:
Does anyone know how to solve that please ?
Thanks
Cheers,
The reason it kills your session from page A is because, on the client side, sessions are implemented using cookies. Both page A and page B are trying to use the same session cookie, with different session IDs, so whichever one writes to it more recently kills the other one.
If you view your cookies using your browser's F12 developer tools, you should see one like this:
Name Value Domain Path
ORA_WWV_APP_115305 ORA_WWV_FMN08hWNhlkjRDOIU_y yoursite.com /pls/apex (etc)
This is the session cookie for APP ID 115305, and the browser will send it along with every HTTP request to yoursite.com/pls/apex. Apex uses the Value to verify that you are allowed to have access to the session specified by the ID in your URL. If you modify either the cookie or the URL's session ID, your session is lost and Apex creates a new one for you.
So the Name + Domain + Path forms a sort of unique key here. You can only have one session for each unique Name + Domain + Path cookie.
I think the easiest solution here is to put your public page B in a separate Apex App. That way it'll have its own session cookie with a different Name.
(This is how the Oracle App Builder, which is also an Apex App, can have a separate session going at the same time without killing your app's session. Its cookies use a Name like ORA_WWV_USER_9872)
The alternatives are to use a different Domain or Path for page B, but that's trickier.
It looks like you've set up a custom Authentication Scheme, so I think your cookie would look like:
Name Value Domain Path
SESSIONCOOKIE ORA_WWV_FMN08hWNhlkjRDOIU_y yoursite.com / (etc)
But you're still using the same Authentication Scheme (and the same cookie) for both page A and page B, so they can't have separate sessions. This would be an instance where it might be nice if Oracle supported using a separate Authentication Scheme for each page, but they don't. This is what separate apps are for.
I am working on a project. After login i assign some value to session variable Like Session("userid")=XYZ. if i open any page inside application it will check for this value and if its not empty and has permission to access page i am allowing it.
Now if suppose i am accessing www.Domain.com/Pagename and close the tab and open the same link after copy paste it checks for session and it opens the same page which is absolutely fine.
But when i restart browser and try to open the page by link copy paste its throwing me back to login screen. Since Session is server side this should not happen. But i read on w3school that session is maintained using cookie, and cookie is lost after browser restart, so how can i maintain my session even after browser restart till it times out.It seems Both Session and cookie are contradicting each other. I didn't had this problem with similar code in asp.net application but in classic asp it doesn't seem to work.
I need to store a state of a paging component between page visits (specifically I need to save currently viewed page, number of items to show per page, and filter/search criteria text).
At first I thought about using localStorage to create a client-side-local-session. But this does not work in IE8, so I fall back to using session cookies when in IE8. But filter/search criteria is sensitive data so session cookies are not acceptable.
Now I am thinking about using server side session storage, but I would like to make the implementation transparent. The idea is to create a global javascript object (or jQuery plugin) called "local session". Local session implementation will send its content with every request (using jQuery AJAX beforeSend callback). So every request will send a fresh state of the clients "local session".
Server than will include all local session data with each freshly rendered page (i.e. only for non-AJAX responses).
I am using ASP.NET MVC and it would be easy to create a global filter that will be collecting this "local session" data and storing it in the server side session.
Two questions:
is storing sensitive data in javascript object any more secure than storing this data in session cookie?
would it be a good idea to send local session content as a header (I can do some optimization and only send it when it actually changes, or even only send the changes).
any other suggestions for implementing this requirement?
Note: using history API won't work in IE8, it also not quite what I need (page state should be persisted even if I get back to the page by following a link, not by clicking BACK button).
Note: It would be nice if the solution would work when cookies are disabled, but this is not a strict requirement though.
If you want to protect the integrity and confidentiality of what's sent to the browser to be stored in a cookie you could sign and encrypt the value using server-side secret key(s) like in Ruby on Rails version 4.
However, keep in mind that the cookie would be subject to replay attacks and there is a size limit.
I am building a small web application and in my application I am using the session object to store information across calls to server. This works quite fine in Firefox \ Chrome\ IE, but it seems to fail in Safari. In Safari the session keeps forgetting that I've stored values in it.
Why is this happening? what can be done?
The session is based on an id stored in a cookie. The server uses this Id to link to your session on the server. It's highly likely cookies are off here. Load up fiddler or turn on tracing to see what cookies are being sent over... You should see the one with aspnetsessionid in it, if not your browser prob has them turned off.
You may also want to take a look over here: Facebook API and Safari
Looks like, if any redirect is sent when you are establishing cookies, they will be viewed as 3rd party cookies and could cause issues with your server-side.
if your settings on Safari are set to not allow cookies, then this fails. I have just had the same issue on an iphone web app im writing. I enabled cookies and all worked fine.
The whole idea of the Session is that the values are stored server-side. Safari can't possibly cause the server to forget something. Either the value wasn't ever stored in the Session or Safari is failing to render the Session value.
Trying using a debugger to confirm if the Session holds the correct value when passing the value into the Session and when you're attempting to retrieve the value from the Session.
Generally speaking, when given a cookie that has no expiration period, modern browsers will consider this cookie to be a 'session cookie', they will remove the cookie at the end of the browsing session (generally when the browser instance closes).
IE, Opera, Safari and Chrome all support this behavior.
However firefox (3.0.9 latest proper release) appears not to follow this rule, from what I can tell it doesn't expire the cookies when the browser is closed, or when the user logs off or restarts the OS..
So, why does firefox refer to these as session cookies, when they last aparently indefinitely?
Does anyone know how Firefox handles session cookie expiration?
This is apparently by design. Check out this Bugzilla bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=443354
Firefox has a feature where you close Firefox and it offers to save all your tabs, and then you restore the browser and those tabs come back. That's called session restore. What I didn't realize is that it'll also restore all the session cookies for those pages too! It treats it like you had never closed the browser.
This makes sense in the sense that if your browser crashed you get right back to where you were, but is a little disconcerting for web devs used to session cookies getting cleared. I've got some old session cookies from months ago that were set by sites I always have open in tabs.
To test this out, close all the tabs in your browser, then close the browser and restart it. I think the session cookies for your site should clear in that case. Otherwise you'd have to turn off session restore.
Two ideas :
You have a problem with your session manager (the one included in FF3 or one included in an extension, like tabmixplus)
Use Firebug + FireCookie (https://addons.mozilla.org/en-US/firefox/addon/6683) to debug !
This should work. I used to be one of the cookie module testers, and I don't think there is any design reason this would behave differently (although if you crash, the session cookies might be designed to live on when you restart...)
Are you viewing the cookies in the "Preferences" menu > "Privacy" Tab > "Show Cookies..." button?
Also, have you tried a new profile?
I disagree with meandmycode above.
The HTTP spec https://www.ietf.org/rfc/rfc6265.txt talks about what a client should do with Set-Cookie headers with Expires:
If the server wishes the user agent to persist the cookie over multiple "sessions" (e.g., user agent restarts), the server can specify an expiration date in the Expires attribute. Note that the user agent might delete the cookie before the expiration date if the user agent's cookie store exceeds its quota or if the user manually deletes the server's cookie.
The logical extension of this is that the ONLY way the server has to require that the browser does not maintain a Cookie on exit is to set no Expires value (i.e a session cookie). If a browser does not honor that semantic then its not honoring the server's response.
Essentially the user agent is deciding to ignore the server request and act as if an Expires value had been set.
This is a bit of a concern in shared user environments. If I set a authentication cookie that is set to expire at the end of the session. This will persist in Firefox after the browser has been closed and another user starts up Firefox. Cookies are set with an expiry date for a reason!
I'm flummoxed that Mozilla have left this as it is for several years.
OK.. so I quit FF and switch off the PC.
Next day FF starts and opens the last set of pages (nice handy feature) BUT it restores the sessions and I'm logged back in to sites which have no "save my settings" feature.
I know because they are sites I built.
Whatever I do with php ini settings the sessions are restored.
They absolutely should not be restored.
Pages yes, but sessions with cookie ini set to '0' no.
I don't understand why this is not flagged as a security hole.
Sure I can do some additional checking on the server side, to see if a login should be allowed, based on time from last log in, but it shouldn't be needed.
A session should NOT persist.
FF is manipulating cookie expiry settings.
In my case, it was because of pinned tabs that automatically restored the session even if this option was disabled in Firefox settings. So if you unpin the tabs, the session won't be restored.
Well it is disconcerting to me. My system is set up so that users can hit EXIT whereby I destroy all session cookies. But if a user closes the browser without actually choosing to Exit, I'd like the session cookies cleared.
I actually tested it with Google Chrome, IE 9, and works fine. But Firefox is reluctant to kill this "session" (as reported by Firebug) cookies.
OK. This is what I did. I chose Exit from FireFox main menu and from then on, did it fine as expected (Dont know why).