I know this is not a question which has code but I was asked a question about SESSION in an interview. Not session variable. Say I have same site open in 2 different tabs of my browser. In one tab i query for the search results of the hospitals in New York and in the second tab(same website) i query for the restaurants in New York. How I get the different results in 2 different tabs and how they don't get mixed up as the request is going from the same browser. Is there any session object that the browser is maintaining.? I could answer about SESSION variable in asp.net but couldn't answer hoe the above condition works. Please explain me the concept of please provide me links .
A session is a semi-permanent interactive information interchange, also known as a dialogue, a conversation or a meeting, between two or more communicating devices, or between a computer and user. A session is set up or established at a certain point in time, and then torn down at some later point. An established communication session may involve more than one message in each direction. A session is typically, but not always, stateful, meaning that at least one of the communicating parts needs to save information about the session history in order to be able to communicate, as opposed to stateless communication, where the communication consists of independent requests with responses.
session management is the process of keeping track of a user's activity across sessions of interaction with the computer system.
A session token is a unique identifier that is generated and sent from a server to a client to identify the current interaction session. The client usually stores and sends the token as an HTTP cookie and/or sends it as a parameter in GET or POST queries. The reason to use session tokens is that the client only has to handle the identifier—all session data is stored on the server (usually in a database, to which the client does not have direct access) linked to that identifier. Examples of the names that some programming languages use when naming their HTTP cookie include JSESSIONID (JSP), PHPSESSID (PHP), CGISESSID (CGI), and ASPSESSIONID (ASP).
More Information :
http://en.wikipedia.org/wiki/Session_(computer_science)
Related
I have seen some sites, where your authentication does note expire after your ip changes. How to create such session, and how safe is it?
So, how does session validate then? by some hardware information?
The fact that you have a session cookie is the validation.
Sessions work by creating a server-side resource with a random id. For example, a random id is created, iuwehrc3948hg3w09x4h, and an entry in a database is saved with it. That random id is sent as a cookie to the browser. The browser returns this cookie with every request, the server looks up the database entry with this id and gets the associated session data.
The "validation" is that the browser possesses a valid session id. The browser can only know this id if it was given to it by the server previously. Because the id is entirely random, it should practically be unguessable by any 3rd party.
Having said this, cookie hijacking is a concern, in which a 3rd party outright steals a valid session cookie (e.g. through a shared network, malware installed on the victim's machine etc.). In this case recording the IP address of the client in the session and validating it as well can help mitigate problems; but as you note, it also means that sessions have an extremely limited life span. The most practical solution to avoid session hijacking is to use HTTPS throughout.
This is not strictly a GWT question, but since the context I'm getting this question out of is GWT. I included the GWT and servlet tags.
Since multiple requests can belong to the same session, and each request has a remote user associated it (null or non-null), it makes me wonder if it's possible to have different users in a session.
Let's say a user logs in, logs out and relogs in using a different account, are we still in the same session on the server side?
EDIT to address the ambiguities raised by BalusC's answer:
- I'm not asking about having multiple users "at the same time". The question is whether it's possible to have more than one users to ever enter the same session.
Your question is rather ambiguous.
Is it possible to have multiple users in the same HTTP session
That depends on how you define "user".
If it's the logged-in user (which is usually stored in / associated with the HTTP session), then that's not possible. There can be only one at the same time.
However, if it's the client, then it's definitely possible to have multiple clients sharing the same session (and inherently also exactly the same logged-in user). This can be achieved via session fixation attack which can be performed with help of cross site scripting. Basically, when multiple clients use exactly the same JSESSIONID cookie.
Let's say a user logs in, logs out and relogs in using a different account, are we still in the same session on the server side?
This is essentially a different question than the one asked in the title. There's strictly no means of "multiple users in the same session" here when considering "at the same moment".
In any way, when the logout does not invalidate the session, which goes against "common practice", then this is indeed quite possible.
See also:
How do servlets work? Instantiation, sessions, shared variables and multithreading
How to effectively destroy 'session' in Java Servlet?
I was going through http wiki page and get to know that http is a stateLess protocol.
Every network transaction is not dependent on previous transaction. How a site(fb,google etc) maintain the session weather a user is logged-in or not using http.
Sorry if my question is below level.
By storing session variables, in PHP:
$_SESSION['var']
Just brainstorming some ideas for a Web App I'm building soon.
One of the cornerstones of the Web is Session Handling: Have the user log in, send a cookie with magic binary encoded pixie dust, trust the user blindly afterwards.
I just wonder if it's feasible to completely eliminate 'traditional' sessions for a web app that would normally use it, e.g. an online store.
The idea would be to have a 'server side session' that doesn't use the SessionID or anything, but the username instead. So there is exactly 1 session per user, not more. That would allow stuff like a persistent shopping cart to work.
Authentication would be handled similar to how Web Services work: Expect HTTP Digest authentication on every single page view.
Ignoring the fact that anonymous visitors would have to be handled differently, do you think this approach would be feasible? Or would the additional traffic/load for constant authentication be a deal-breaker in the long run?
First off, we don't use sessions at all.
We found that utilizing session complicated the code without any benefit. There are only two reasons to even consider using session state. The first is to reduce the amount of traffic to your sql server.. However, with load balanced web servers etc, session has to be stored in a sql server... Which kind of eliminates it's first point. But it's worse than that as the session has to be retrieved, deserialized, serialized, and stored on every single page load.
The second reason is to keep from having the browser pass the user id back to the application on each request. However, "session hijacking" is a fairly easy trick to pull off and is rarely taken into account.
So, instead, we use a highly encrypted cookie with non-guessable values that indicate exactly who the user is. We've coupled this with a changing, non-guessable, request id and have eliminated both session state (and it's unnecessary overhead) while at the same time improving security all around.
Can the cookie be stolen? Sure, but it has a very limited life that is the amount of time between two postbacks. Which means it will be found to have been compromised rather quickly.
So, I wouldn't say sessions are a "corner stone" of the web. Rather I'd say they are crutches that are often used improperly and should be avoided for both security and performance reasons.
All of that said, the only way you are going to tie this to a user id is if you force your users to login/create account prior to shopping.. Which no one is going to do unless they have no other choice but to be on your site.
Oh, and don't take my word for it:
4GuysFromRolla.com -> Session variables are evil.
aps.net -> Are session variables still evil?
Scott Hansleman -> Moving Viewstate to Session Pay attention to the part in bold covering memory consumption and it's ability to stay around for way too long.
Coding Horror -> Your Session has timed out This details just some of the problems associated with even using session
Wikipedia -> Session Hijacking What list would be complete without a link to wikipedia?
REST-like implementations such ASP.NET MVC do not require session state at all.
You should just use sessions. Even if its your own session implementation: eg. cookie contains random key used to store information the server. A cookie must be used or you will have to encode all links on the site with a query parameter that specifies the key -- bad idea!
I would then store the "session key", or what every you want to call it, with the persons username in the database.
When a user logs in to your site simply restore their previous "session".
Other then the query parameter option, which is a bad idea, you can track users by IP address. But this again is a horrible idea! Eg. many buildings have a limited number of Internet IPs and many times more internal computers.
There is no good way to track a user without using cookies.
Yes maybe you can use HTTP authentication but why bother? You are just going to introduce new issues and put limitations on your UI.
That actually is pretty much what a traditional session does -- provide a unique identifier to distinguish a browser "session", all you are doing is tying it to username rather then a random variable.
I would say just be very careful of how you generate your token, if it is reproducible you could easily accomplishes the goal of a session fixation attack by generating someone elses session and jamming it into a cookie. That is the reason that sessions are usually a random unique value.
The idea would be to have a 'server side session' that doesn't use the SessionID or anything, but the username instead. So there is exactly 1 session per user, not more. That would allow stuff like a persistent shopping cart to work.
That's just a session, but using the username as the session identifier - which is going to cause all sorts of problems - its open to replay attacks even if you encrypt it. You can't change the encrpytion per-request because that will break when the user opens a second window or presses the back button.
You can't rely on the client address - multiple users may share a NAT address, the same user may access your site from behind a cluster of load-balanced proxies.
like a persistent shopping cart
...implies that you have server-side data for the customer - since the size of this data will vary, you can't store it in the URL nor in a cookie.
Expect HTTP Digest authentication on every single page view.
That presupposes that you create accounts for every user, and that you're not concerned about the impact of the same user id being used by different clients. I don't think that this would require significantly more processing than a conventional session - but its still web-based session management with a different set of problems and vulnerabilities compared to the conventional approach.
What are the do's and don'ts about Cache VS Session VS Cookies?
For example:
I'm using Session variables a lot and sometimes have problems in a booking-application when users start to order products and then go to lunch and come back some hours later and continue the booking. I store the booking in the session until the user confirms or aborts the booking so I don't need to talk to the database and handle halfway bookings in the database when users just click the X in the browser and never comes back.
Should I instead use cache or cookies or some combination for this?
(Also when there is some error in the app, the session-object resets itself and I get more problems because of that)
I'm mostly doing desktop-programming and feel I lack lots of knowledge here so anyone who can expand on where to use Cache, Session, Cookies (or db) would be appreciated
Edit: From the answers it seems that a combination of DB and cookies is what I want.
I have to store the booking in the database connected to a session-id
Store the session-id in a cookie (encrypted).
Every page load checking the cookie and fetch the booking from the database
I have a clean-up procedure that runs once a week that clears unfinished bookings.
I can't store the booking as a cookie because then the user can change prices and other sensitive data and I had to validate everything (can't trust the data).
Have I got it right?
And thanks for great explanations to all of you!
State management is a critical thing to master when coming to Web world from a desktop application perspective.
Session is used to store per-user information for the current Web session on the server. It supports using a database server as the back-end store.
Cookie should be used to store per-user information for the current Web session or persistent information on the client, therefore client has control over the contents of a cookie.
Cache object is shared between users in a single application. Its primary purpose is to cache data from a data store and should not be used as a primary storage. It supports automatic invalidation features.
Application object is shared between users to store application-wide state and should be used accordingly.
If your application is used by a number of unauthenticated users, I suggest you store the data in a cookie. If it requires authentication, you can either store the data in the DB manually or use ASP.NET profile management features.
Web is by nature disconnected model and none of the options mentioned (Session, Application, Cache, ...) are reliable enough. Session will timeout, worker process recycles, etc.
If you really need to store the users progress, reliably and through extended periods, the database is your only solution. If you have users profile (if the user must log in), then it's straightforward. If not, generate a unique Id, store it in the cookie (or URL) and track the user based on that identification.
Just make sure the Id is encrypted and then base64 encoded string and not just a numeric value.
EDIT:
After your additional explanation in the original question and comment from Mehrdad Afshari, good solution for you would be to use Session but set the storage to Sql Server instead of InProc.
Here's more details and instructions how to set it up: http://msdn.microsoft.com/en-us/library/ms178586.aspx
Have in mind that you will STILL have the session timeouts, but they will survive application pool recycles, even server restarts.
If you truly need a permanent storage, custom solution with the database, as I originally outlined is the only solution.
Session is stored on the server will time out by default in 20 minutes (This is adjustable). I would store this in a cookie, or in viewstate(if available) to prevent the timeout.
If your state is stored InProc(the default setup), then having more than one server in a farm is going to cause you issues also unless you have implemented some sort of "sticky session" that will keep the user on the same server in the farm for subsequent calls.
I try to avoid session when possible(puts extra load and memory usage on the server), and keep viewstate turned off when possible to keep the page size low. Cookies are often the most lightweight option, but your users might have this turned off and you will need a fallback mode that still allows them to use the site.
Edit (adding clarification based on response from asker):
Viewstate is stored in a hidden field, and is a serialized representation of all objects in Viewstate storage. Viewstate is automatically used to store the page's state, but you can explicitly add and retrieve your own objects to and from Viewstate programatically if you choose to.
So yes, datasets can be stored in Viewstate.
First thing you must know! cookies are used by session! The server knows who is your user thanks to the cookie which is exchanged between the client and server every request (this works with HTTP headers set-cookie and cookie).
The real question is:
If you want to store user information during the navigation, then you should use session.
If your client doesn't support cookies, then you can decide to store a cookie inside each request, encoded in the URL (the server will use the URL instead of the cookie to find the right session for the request).
Then consider where you want to store your session:If your site must have high disponibility and high performance, then you must not store session inside the process but inside a database. This way you will be able to share the work among several web server.
But you will loose in simplicity (because objects you store in your session must be serializable), and you have one more round trip between your webserver and your database server.
I was always confused between LocalStorage, SessionStorage and Cookie, but not anymore.
Just link the words are self explainable what they suppose to do.
LocalStorage: Local Storage, what does that mean, just thing you don't know anything about technology, but by the itself you can guess.
It is some storage which stores data locally.
that what it is.
IT stores data in Browser without any expiration until user clear it through JavaScript code or Clear browser cache.
Session Storage: It seems like it also stores data but related to a session then how different it is from localStorage?
The main difference is your session storage data will be deleted once the session is finish or browser tab is closed or the browser is closed.
You can just try in browser console by setting
localStorage.setItem('name' , 'alex')
sessionStorage.setItem('session','seesion value')
and then close tab and open again, you can still find localStorage data but not sessionStorage data.
Cookie: So this is totally different from the above two.
A cookie generally used for the server-side purpose.
Stores data that has to be sent back to the server with subsequent
requests.
Its expiration varies based on the type and the expiration
duration can be set from either server-side or client-side (normally
from server-side).
Cookies are primarily for server-side reading (can
also be read on client-side), localStorage and sessionStorage can
only be read on client-side.
Size must be less than 4KB.
Cookies can
be made secure by setting the httpOnly flag as true for that cookie.
This prevents client-side access to that cookie
You should not use the Cache-object to cache session data, for the cache is shared between all users. Instead you could use Asp.Net Profile properties to store your data or you could add an event handler to the Session_End event and store the data if the user leaves the computer for too long.
Cookie is a piece of information shared between co-operating pieces of software, by storing client-specific information on the client's machine and later retrieved to obtain the state information.
chose the term "cookie" as "a cookie is a well-known computer science term that is used when describing an opaque piece of data held by an intermediary". The term opaque here implies that the content is of interest and relevance only to the server and not the client. The browser will automatically include the cookie in all its subsequent requests to the originating host of the cookie. A cookie has a name and a value, and other attribute such as domain and path, expiration date, version number, and comments. for more
Cookie Version:
Cookie: cookie-name=cookie-value; Comment=text; Domain=domain-name; Path=path-name; Max-Age=seconds; Version=1; Secure
Server-side session data can store large data and a client-side cookie data are limited in size sent from a website to server, cookies usually contains reference code by this saving data transfer size. Session closes as soon as browser closed, but cookies are exist longer. Browser sends a session ID to the server as a URL param, cookie, or even HTTP headers.
Cache is a hardware or software component that stores data so future requests for that data can be served faster; the data stored in a cache might be the result of an earlier computation, or the duplicate of data stored elsewhere.
Cookies are stored in browser as a text file format.It is stored limit amount of data.It is only allowing 4kb[4096bytes].It is not holding the multiple variable in cookies.
we can accessing the cookies values in easily.So it is less secure.The setcookie() function must appear BEFORE the tag.
Sessions are stored in server side.It is stored unlimit amount of data.It is holding the multiple variable in sessions. we cannot accessing the cookies values in easily.So it is more secure.