I've a large application working on and I am facing with hte problem of sessions a lot, it just unset or corrupt the session of my application sometime, all I got it undefined in my session.
By the way I need to know is there any alternative of sessions so I came to know after R&D that I may use cookie, but I think these things are same before .
So I am stuck, don't know how to get rid of my problem.
Now I've some questions as I am a beginner
what is the difference b/w sessions and cookie in sailsjs.
how to set and get cookie in sailsjs.
i am using sails version v0.94
Please guide me in this.
Session is a schemaless object that can be saved in memory or a persistent store such as Mongo or Redis. Using a memory store like Redis or Mongo helps to persist your sessions across multiple application servers or during an application restart.
The cookie tracks a user with a specific ID to associate with the session. Sailsjs, on top of Express, manages cookies and sessions automatically. When a user accesses your site it is assigned this cookie that has a unique ID. Then sails/express automatically will associate session information to that particular client based on their unique cookie. Sails does more than express by allowing you to use this with with sockets as well.
This is all done so you don't have to save and update session the same as a normal DB. You just set the property and move on.
The reason not use cookies is if you prefer to keep the information on the client and do not want to create overhead for your server to look for that value in memory or in a DB. You will want to make sure this information does not need to be secure.
To learn how to use cookies you should google "Expressjs Cookies" (remember sails runs on top of express, current version 3.x)
If you want an alternative to sessions / cookies you can look at web tokens http://jwt.io/
Remember sailsjs runs on expressjs if you can't find what your looking for, then always search for an express solution as well.
Related
It seems to me that as long as you only want to store simple values like a timestamp for last visit and maybe a userid in the session, there's really no point at all in using Redis as a session persistence with Gorilla sessions since they seem to be storing it in cookies on the client side anyways.
Am I correct or not in this assumption?
I understand that there's a size limit and also that if I were to store sessions on file (the other available storage option with gorilla sessions), it'd be impossible to scale beyond that machine but again, is this whole "session store" a non issue with gorilla sessions cookie store?
Btw, I've seen this question here and NO it doesn't address this issue so it's not a duplicate. What is the advantage of using Gorilla sessions custom backend?
Using Redis (or any other server-side store) can help avoid a whole class of problems, namely:
Large cookie sizes adding per-request overhead - even an additional 4K per request can be a lot on mobile connections.
Severely reducing the risk of cookie data being manipulated as it is stored server-side.
Ability to store more than 4K in the session (i.e. form data from a multi-step form)
... and in Redis' case, the ability to easily expire the server-side sessions (something that's more error prone with mySQL or a filesystem store.
A cookie is still required as it must store an identifier so the user can be associated with their server-side session. This isn't particular to gorilla/sessions whatsoever and is how nearly all other server-side session implementations behave.
If you think your use case is simple then sure, stick with cookie-based sessions. gorilla/sessions makes it easy enough to change out the backing store at a later date.
By browsing through the code of the Auth and Session snaplets I observed that session information is only stored on the client (as an encrypted key/value store in a cookie). A common approach to sessions is to only store a session token with the client and then have the rest of the session information (expiry date, key/value pairs) in a data store on the server. What is the rationale for Snap's approach?
For me, the disadvantages of a client side only session are:
The key/value store might get large and use lots of bandwidth. This is not an issue if the session is only used to authenticate a user.
One relies on the client to expire/delete the cookie. Without having at least part of the session on the server one is effectively handing out a token that's valid to eternity when setting the cookie.
A follow-up question is what the natural way of implementing server side sessions in Snap would be. Ideally, I'd only want to write/modify auth and/or session backends.
Simplicity and minimizing dependencies. We've always taken a strong stance that the core snap framework should be DB-agnostic. If you look closely at the organization, you'll see that we carefully designed the session system with a core API that is completely backend-agnostic. Then we included a cookie backend. This provides users with workable functionality out of the gate without forcing a particular persistence system on them. It also serves as an example of how to write your own backend based on any other mechanism you choose.
We also used the same pattern with the auth system. It's a core API that lets you use whatever backend you want. If you want to write your own backend for either of these, then look at the existing implementations and use them as a guide. The cookie backend is the only one I know of for sessions, but auth has several: the simple file-based one that is included, and the ones included in snaplet-postgresql-simple, snaplet-mysql-simple, and snaplet-persistent.
I store data in
HttpContext.Current.Application.Add(appKey, value);
And read data by this one:
HttpContext.Current.Application[appKey];
This has the advantage for me that is using a key for a value but after a short time (about 20 minutes) it does not work, and I can not find [appKey],because the application life cycle in iis data will lose.
i want to know is that another way to store my data by key and value?
i do not want sql server,file,... and want storing data on server not on client
i store users some data in it.
thanks for your helping
Since IIS may recycle and throw away any cache/memory contents at any time, the only way you will get data persisted is to store it outside IIS. Some examples are; (and yes, I included the ones you stated you didn't want just to have the list a bit more complete, feel free to skip them)
A SQL database (there are quite a few free ones if the price is prohibitive)
A NoSQL database (same thing there, quite a few free ones and usually simpler to use for key/value)
File (which you also stated you didn't want)
Some kind of external memory cache, a'la AppFabric cache or memcached.
Cookies (somewhat limited in size and not secure in any way by default)
you could create a persistent cookie on the user's machine so that the session doesn't expire, or increase the session timeout to a value that would work better for your situation/users
How to create persistent cookies in asp.net?
Session timeout in ASP.NET
You're talking about persisting data beyond the scope of a session. So you're going to have to use some form of persistent storage (Database, File, Caching Server).
Have you considered using AppFabric. It's actually pretty easy to implement. You could either access it directly from your code using the nuget packages, or you could just configured it as a session store. (I think) doing the latter would mean you'd get rid of the session timeout issue.
Do you understand that whatever you decide to store in Application, will be available for all users in your application?
Now regarding your actual question, what kind of data do you plan on storing? If its user sensitive data, then it probably makes sense to store it in the session. If it's client specific and it doesn't contain any sensitive information, than cookies is probably a reasonable way forward.
If it is indeed an application wide data and it must be the same for every user of your application, then you can make configuration changes to make sure that it doesn't expiry after 20 minutes.
It seems some web architects aim to have a stateless web application. Does that mean basically not storing user sessions? Or is there more to it?
If it is just the user session storing, what is the benefit of not doing that?
Reduces memory usage. Imagine if google stored session information about every one of their users
Easier to support server farms. If you need session data and you have more than 1 server, you need a way to sync that session data across servers. Normally this is done using a database.
Reduce session expiration problems. Sometimes expiring sessions cause issues that are hard to find and test for. Sessionless applications don't suffer from these.
Url linkability. Some sites store the ID of what the user is looking at in the sessions. This makes it impossible for users to simply copy and paste the URL or send it to friends.
NOTE: session data is really cached data. This is what it should be used for. If you have an expensive query which is going to be reused, then save it into session. Just remember that you cannot assume it will be there when you try and get it later. Always check if it exists before retrieving.
From a developer's perspective, statelessness can help make an application more maintainable and easier to work with. If I know a website I'm working on is stateless, I need not worry about things being correctly initialized in the session before loading a particular page.
From a user's perspective, statelessness allows resources to be linkable. If a page is stateless, then when I link a friend to that page, I know that they'll see what I'm seeing.
From the scaling and performance perspective, see tsters answer.
I was once in a project of web application developed on ASP.NET. For each logon user, there is an object (let's call it UserSessionObject here) created and stored in RAM. For each HTTP request of given user, matching UserSessoinObject instance is used to visit user state information and connection to database. So, this UserSessionObject is pretty important.
This design brings several problems found later:
1) Since this UserSessionObject is cached in ASP.NET memory space, we have to config load balancer to be sticky connection. That is, HTTP request in single session would always be sent to one web server behind. This limit scalability and maintainability.
2) This UserSessionObject is accessed in every HTTP request. To keep the consistency, there is a exclusive lock for the UserSessionObject. Only one HTTP request can be processed at any given time because it must to obtain the lock first. The performance and response time is affected.
Now, I'm wondering whether there is better design to handle such logon user case.
It seems Sharing-Nothing-Architecture helps. That means long user info is retrieved from database each time. I'm afraid that would hurt performance.
Is there any design pattern for long user web app?
Thanks.
Store session state in the database and put memcached in front of it.
One method discussed on StackOverflow and elsewhere is the signed cookie. A cookie that has information you would otherwise not be able to trust, along with a hash created in such a way that only your server could have created it, so you know the information is valid. This is a scalable way to save non-high-security information, such as username. You don't have to access any shared resource to confirm that the user is logged in as long as the signed cookie meets all criteria (you should have a date stamp involved, to keep cookie theft from being a long term issue, and you should also keep track that the user has not authenticated, so they should have no access to more secure information without going through the usual login process).
StackOverflow: Tips on signed cookies instead of sessions