Hot answers tagged

21

Sometimes it's not practical to store certain data in a session table on the database. If certain data gets updated a lot then it could bog down the database a lot as well. If that's the case and the data's not too important, it might be better stored in a separate cookie. When (1) happens you have to deal with the 4kb-per-cookie limit, so storing all of ...


18

Sometimes you can use IP address. If you're on a LAN or are otherwise dealing exclusively with users that have IP's statically distributed to single clients, using that address is perfectly fine -- sometimes preferable and necessary. But, usually you can't. If you're running a public site, most of the IP addresses that hit your server aren't static or ...


11

Cookies: in their early version, a text file with a unique client Id an all the other information needed about the client (e. g. roles) Cookies are tuples key-value originally addressed to retain data related to the client activity. This retention is what we know as session or application state. Fundamentally, they were made for holding the state of web ...


10

Three more reasons to add: Multiuser workstations and terminal servers exist. Many users could be running completely independent browser processes in separate sessions. IP addresses aren't persistent. It could be reassigned when a DHCP lease expires. The application should support roaming. For example, a user on a phone might drop out of WiFi range and ...


9

I would go for a solution where an unique ID is assigned to all visitors when they first hit the site. It doesn't matter if they're anonymous or authenticated. When anonymous users register, retain the unique ID. Store the shopping cart in the database. Storage is cheap, and it shouldn't be a problem performance-wise to do a query for the cart every now and ...


8

If you really must have session handling in your API then the client would be responsible to handle the session_id and add it to the URL if required. How exactly to handle this would depend on your technology stack. For example Rails defaults to cookies but (if enabled) would also accept a _session_id parameter as part of the URL. The relevant information ...


7

Treat an EAR like a pseudo-virtual machine An EAR is simply a collection of WAR files that share common configuration and libraries, usually from JARs. This enables a collection of inter-dependent services to be managed more easily within an application container. Thus you can think of an EAR as a simple form of virtual machine once it is deployed into its ...


7

Both methods have advantages and disadvantages, but the way I see it, database storage has two pretty large advantages. Reporting. You can't report on abandoned carts, conversion rates, etc. if the data is in the session. Session timeouts. I would be annoyed if I went to eat dinner and came back to find my cart was emptied because the session expired. I ...


7

Cookies: in their early version, a text file with a unique client Id an all the other information needed about the client (e. g. roles) Your definition of cookie doesn't really describe what they do. A cookie is a key-value pair that is set via HTTP response header (Set-Cookie) by the server and stored by clients that support them. Cookies are sent back ...


6

You shouldn't store it in session but at the same time you also shouldn't load the Properties file after each request because of the detrimental impact that repeated file I/O will incur. Store it on the ApplicationContext which allows the one Properties file to be loaded into memory once and can be used to the beneft of all users on all sessions.


6

The question is assuming you need sessions at all which in my market of clients is not needed. I happen to run several hundred eCommerce websites and a handful of them are getting high traffic. We do not use sessions ever as they are not scalable unless farmed out then they are just slower or require more setup. Sessions use up memory and database fetching ...


6

It can be expensive and painful, but in the end you need to have a local "cluster". Trying to simulate race conditions, contention and the like are very hard on a single PC (my interpretation of "local development environment"). From past experience I would suggest: Push very hard to get a production level cluster into your test/dev environment, You can ...


6

The usual approach is to simply provide a session token back to the client via headers or cookies if they failed to provide one, or provided an invalid one. This is especially necessary for web clients where the session can time out while they're on a page somewhere. This ensures you have your session immediately, without going to the "authenticate" end-...


5

The best is to store at Memcached as we can easily resolve the other issues (cache size, security, etc.) facebook is the #1 consumer of memcached. Please read if interested: http://www.facebook.com/note.php?note_id=39391378919 How to resolve the other issues? https://stackoverflow.com/questions/235470/how-to-effectively-implement-sessions-in-gae ...


5

I think the most common simple solution is where you set a timer on the client end that shows a message after a certain portion of the normal timeout window has passed then forcibly logs them out right before the session would expire anyway if they take no action. Local storage and auto-save introduce some issues with transactions and what saved really ...


5

Every session is going to have some authorization artifact it uses to track sessions. (In web applications, usually this is a token in a cookie, although it doesn't have to be in a cookie.) When your application grants those authorization artifacts, you can keep a link back to a user, and then manage them as a one-to-many relationship -- one user has many ...


4

You don't need to code any conditionals to get the appropriate translation for a given property, just a Locale for the current user; provide that when retrieving a ResourceBundle: ResourceBundle localeSpecificBundle = ResourceBundle.getBundle("bundleBaseName", userLocale); String translated = localeSpecificBundle.getString("someKey"); In addition, ...


4

Do the majority of providers attempt to route connections to a common public IP in order to maintain compatibility with websites like ours, or should I consider restricting sessions to an IP range instead? Short answer: IP addresses have no relationship to a user's identity. Furthermore, you cannot accurately predict what address, or block of addresses ...


4

Yes, the client - assuming a web browser - would send the cookie for that domain. You dont need to send it each time. Though a lot of applications do send the cookie back with each page so as to extend the expiration of the cookie. You probably dont need the 'success' field - either the session id stored in the cookie is going to be valid, or it isnt. ...


4

It's a bad idea. Assuming the default setup for sessions, you'd be replacing calls to the database with calls to the filesystem, you'd be moving from a storage that scales to one that generally doesn't. Sessions are extremely convenient, but they should be used as sparingly as possible, especially the (default) file based flavour. If you use them for ...


4

Why sessions are expiring? Is it because: They were inactive for a certain delay? In this case, just increase the delay. Or because recompiling the web application threw out application cache and current sessions? In this case, store sessions on a less volatile support, like the database. This would also give you the advantage to be able to run the web ...


4

You are assuming that session storage and database storage are exclusive. They aren't. But let's start by assuming they are. The advantage to session storage is three-fold: No need to explicitly insert data into the database. You just simply set a session variable and you're done. Simple and low-risk functionally. No need to manage the lifecycle of a ...


4

My personal approach would be not to use the session everywhere. I'd try to reduce its usage at the controller layer. In the controller I'd extract what I need for my business logic and the later will never know that there is a web session involved. This will make that logic portable to non-web applications, and will work with all its data in a type-safe ...


4

Never store sessions in a static variable! Static variable means that when another user logs in, the static variable will be updated it with the new session and the first user will work under the last user's session. Never user static varible in a web application. The only case where i use static variables is with constants(which are static by default); ...


4

One way to implement this would be to keep a separate authentication token for each browser session, instead of one shared authentication token. You can store that in a browser cookie, which is of course specific to that browser, and selecting the "log out" option would clear that browser cookie (and remove it from the database). Even if somebody were to ...


4

It should be unnecessary to use sessions for this scenario. When the client creates a new Tournament resource (represented in JSON) it can PUT or POST that resource to the server. Which one you choose will depend on who is responsible for the unique identifier for the Tournament. If the client already knows what the URL should be for that Tournament (say it ...


4

Your second solution is best solution. I believe this because it should fundamentally be the clients responsibility to inform the server that they are still active. The server can then do as it must from there. This gives the server all the control over what happens. The only control the client has is to designate if the user is still active or not. Which ...


4

This answer may help you in terms of replay attacks at the network level. The use of a "nonce" can also help protect against the same semantic request being made multiple times by the same client. In terms of a Man In The Middle (MITM) intercepting a hash and replaying it in place of a password, it is true that this is possible, but equally this is possible ...


Only top voted, non community-wiki answers of a minimum length are eligible