I'm experiencing something a bit odd and I can't make heads or tails of it... I'm using Meteor to send the sessionId to from the client to the server but on every refresh of the page, the sessionId I get is different, which shouldn't be, am I correct?
Client
Meteor.call('logSession', Meteor.default_connection._lastSessionId);
Server
Meteor.methods({
logSession: function(sid) {
console.log(sid);
}
})
Any reason why the sid is always different?
Thanks!
The _lastSessionId is created for each websocket session between the client and server. It represents the websocket's session & state on the server side and not a cookie or something persistent.
When you refresh/open a different tab a new websocket would be created and this is why the session id is different.
Each Session ID represents the state of the data the client has on the server. This means the server 'knows' what data the client has on each session depending on the subscriptions so that it knows what to send down & what to change if something changes, for that particular tab.
When you refresh the page, you're using using a fresh new state so Meteor doesn't attempt to reconnect using a previous session id and restore your previous state, because there isn't a need to resume a previous state in terms of subscriptions since the user would expect the page to be fresh.
If you want to use some form of persistence available along tabs such as cookies use localStorage instead:
localStorage.setItem("foo", "bar");
console.log( localStorage.getItem("foo") );
=> "bar"
Related
I am trying to understand, how exactly the session management mechanism in a stateless web application works. Currently I am using Play Framework but I think the mechanism should be the same for all of the stateless web frameworks
this is from the documentation of play framework: (link)
It’s important to understand that Session and Flash data are not stored by the server but are added to each subsequent HTTP request, using the cookie mechanism
and
Of course, cookie values are signed with a secret key so the client can’t modify the cookie data (or it will be invalidated).
Now my question is, if the server does not save anything about a session id, how does it authenticate a session coming from a client?!
I did a lot of searching, but I couldn't find out, how the session management on the server side really works.
Now my question is, if the server does not save anything about a
session id, how does it authenticate a session coming from a client?
What play does is it signs your session data through a key say KEY(Its the application.secret that you set in application.conf) and produce a alphanumeric data. Then it attaches both data and encrypted data to cookie and sends it back
ENCRYPTED DATA= 5d9857e8a41f94ecb2e4e957cd3ab4f263cfbdea
DATA = userEmail=sil#st.com&userName=silentprogrammer
If you Inspect the cookie(Right click on browser->Inspect element->Application->Cookie->Your url) in the browser of your running application you can see something like
"5d9857e8a41f94ecb2e4e957cd3ab4f263cfbdea-userEmail=sil#st.com&userName=silentprogrammer"
For each request it gets the data part(userEmail=sil#st.com&userName=silentprogrammer) signs the data again from the KEY and checks it to the alphanumeric data coming from request i.e. 5d9857e8a41f94ecb2e4e957cd3ab4f263cfbdea if the both are equal(if data and encryption key is same) the session is confirmed otherwise session expire. You can confirm this by changing the data part from cookie in browser and sending the request again the session will not exist.
This is what I have observed
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.
I did a little bit of Web Programming here and there but I never quite understood what's meant by the word Session.
I've googled a bit here and there, read the Wikipedia article, but could never quite grasp the meaning of it.
So, what's a Session?
Session is a way of persisting your information across multiple pages and requests. When you visit the login page of any site and you provide your username and password, you won't need to provide them again on subsequent pages.
This is done by attaching a session id, unique to your request, and is sent back and forth as you navigate pages.
Session Id could be stored in cookies (file on your system), in the URL as part of query string or in the database
A session is a place for storing data for a particular visitor of your site.
You can store data there that is also available on the next page request from that visitor. If some data is stored 'in the session', it means that the data is stored somewhere (possibly in the database of the server or in files) which the server can then use to construct the web page.
The visitor will receive a temporary cookie which contains a session id, an identifier which is used to associate that visitor with the session data that is stored on the web server.
The session id is sent to the server with each request and the server can lookup the stored session data (which can then be used to construct the web page).
It's the concept of keeping state around over an inherently stateless protocol like HTTP.
If you want to keep track of a logged-in user, for example, and maybe some data associated with that user, you could send that data between the server and the client each time, which of course would be terribly insecure. Or you could keep it in a session store on the server, for example a file or a database, and just exchange an identifier for the storage location between client and server. That's usually done via cookies these days, but could also be a parameter in the URL.
To make it simple:
If you first visit the site, the server gives the client an identifier. With this the server can identify a client across several request from the client to the server. The identifier is deleted after a preset time.
The combination of this identifier and the timeframe the identifier is valid, is called session.
Hope that helps. :-)
Session: An interaction between user & server, which has an ID associated with it. So that server can pin-point & serve the users according to their requests. Cookies are basically used for storing the session information because by default HTTP is state-less.
How to maintain session in my grails application. Here is my requirement.
I have to generate session id (in server side) based on the user-name (which comes from client side while log-in).
After log-in, the server should pass the session id to client and sets timer to validate the session.
For every request, the client should pass the session id to server, so that the server is able to check whether the session is alive or not based on the timer.
If the session is valid, the server should process the request and has to increment the timer.
If the session in invalid, the request should not be processed by server.
Please let me know if you any idea/tutorial/suggestions.
Thanks in advance...
This looks exactly how the http session behaves, so you have that functionality out of the box. Just use the session variable to access session attributes. (see here). And this question tells you about how to configure the timeout.
This is my server code, please take a look at the comments in the code.
var app = express.createServer();
app.get('/', function(req, res){
// create a session with the value of an email for example: me#gmail.com
});
// down here I want to check the session if the session exist
if( there is a session with value me#gmail.com){
//do stuff
}
The way sessions are implemented in Connect / Express doesn't allow for a custom session ID. This is partly because of security. So there's a bunch of things you can do.
Store everything in the session. Create an index somewhere (perhaps in a database) that maps email addresses to session IDs, so you can look up sessions by email.
Store only the email in the session. Keep the actual session data elsewhere (perhaps in a database), where you can fetch it by email address.
Create your own session middleware, perhaps based off Connect's code. The actual session code in Connect is a mere 300 lines. But be very careful to keep security features intact.