I've worked with Java EE (now Jakarta EE) since before it was named "EE" (i.e. servlets, etc.) but the last time I was deeply into session management was over 15 years ago. Now we have new technologies and trends such as the HTML5 Web Storage API and JSON Web Token (JWT). While one can debate the benefits of JWT for session tracking, there are some interesting benefits to keeping track of a session in a single tab using the sessionStorage.
So just to bring me up to speed:
Are the latest Java EE technologies (Java EE 8) still restricted to cookies and URL rewriting for session tracking, and
Do the most recent Java EE APIs allow me to provide custom state management, e.g. override how the container finds state (if I wanted to store a state identifier in sessionStorage instead of a cookie, for example)?
All the discussion I've seen seems to dance around this question. If someone could direct me to some existing documentation, if there is any, that would help, too. Thanks.
localStorage is for keeping data for the use in the browser across sessions. For session data, one would use sessionStorage. None of the data stored there ever goes to the server without being explicitly posted.
Session data could also be stored on the server side by the container. The state can be identified in any of the standard ways of an HTTP header or a cookie. The developer may use a home grown implementation to hold the session identifier. If Spring Session is used for session management, then the eager developer would need to implement a custom session ID resolver.
Related
if I understand correctly, the Play Framework uses cookies to store the whole session, while PHP just stores a Session-ID in a cookie and saves the real session itself on the server-side.
The Play Framework promotes good horizontal scalability with its approach. But I do not see the advantage, if I use any other framework and save my session into a database, for example with Symfony and Redis.
So how is the Play Framework better (for some use cases)?
The initial idea behind Play's architecture is that the designers wanted it to be stateless ie. no data being maintained between requests on the server-side - this is why it does not follow the servlet spec. This opens up flexibility with things like scalability as you have mentioned - this is in itself a big advantage if your application is large enough that it needs to scale across more than a single machine - managing server-side session data across a cluster is a pain.
But of course, anything other than a trivial application, Will have a need to maintain some session data and as you have mentioned yourself you would usually do this with a cache or DB. The cookie session Play uses is restricted to about 4Kb so is only intended for a relatively small amount of data.
The benefits of a stateless architecture are manyfold and are what Play's architecture is designed to exploit.
A bit dated but the relevancy still applies in this article.
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'm novice in Play framework,
We said that Play 2 is fully RESTful - there is no Java EE session per connection.
However, we can save data in different ways: Session, Flash or Cache!
Does not exist any contradiction?! or I misunderstood things?!
Could someone explain to me?
Session and Flash data are stored on the client itself, in a cookie. They are sent to the server on each request, in fully stateless architecture. If you have an pool with 3 servers, any of them will be able to process the request.
The cache is a temporary data storage. It does not certify that the data you insert will be available when you need them. Consequently, for each cached data, the server must be able to retrieve them, from a database generally.
In this way, the cache doesn't need to be shared between each server, according to the stateless architecture.
Are there any benefits to ColdFusion sessions vs J2EE sessions?
The ColdFusion session documentation mentions the benefits of J2EE sessions, but not any advantages of ColdFusion sessions. J2EE sessions have been available since ColdFusion MX (released in 2002), but there are still a lot of people using standard ColdFusion sessions. Are there any disadvantages of J2EE sessions that aren't present with ColdFusion sessions?
J2EE session management provides the following advantages over ColdFusion session management:
J2EE session management uses a session-specific session identifier, jsessionid, which is created afresh at the start of each session.
You can share session variables between ColdFusion pages and JSP pages or Java servlets that you call from the ColdFusion pages.
The Session scope is serializable (convertible into a sequence of bytes that can later be fully restored into the original object). With ColdFusion session management, the Session scope is not serializable. Only serializable scopes can be shared across servers.
Therefore, consider using J2EE session management in any of the following cases:
You want to maximize session security, particularly if you also use client variables
You want to share session variables between ColdFusion pages and JSP pages or servlets in a single application.
You want to be able to manually terminate a session while maintaining the client identification cookie for use by the Client scope.
You want to support clustered sessions; for example, to support session failover among servers.
There are no serious disadvantages to using Java EE session cookies, and there are some advantages to using them, as indicated above in your question.
The one disadvantage to Java EE tokens is that the cookies cannot be easily modified programmatically. CF Tokens can. You can modify CF Tokens to be session only. You can also modify them to be SSL-only and httpOnly.
You can make Java EE tokens SSL-only and httpOnly as well, but it involves JVM arguments.
In CF9, Adobe also improved the randomness of CF Tokens to be more on par with Java EE tokens.
I really don't think it matters which one you use (assuming you're on CF9 or higher). But Java EE Tokens are the closest to working securely out-of-the-box. But if you want to go beyond just setting the cookies to "session-only" and have them be SSL-only and httpOnly, you'll need to dig into the JVM settings. You cannot do that in your App.cfc.
CF native sessions don't use Session cookies, so can last across browser/machine restarts, whereas all Java EE servers by default use session cookies,so your session can only last as long as your browser is open.
I can't find where this behaviour is specified in the Servlet JSR, but in Servlet Spec 3.0 (i.e. not JRun) , you can set an expiry date for your Java EE session cookie in order to mimic the CF native session behaviour.
As nosilleg mentions, this is could be a bonus, but also could be seen as a security problem, depending on the security requirements of the app your're working on.
One of the main disadvantages of J2EE session variables in ColdFusion is that changes such as making them "secure" cookies takes place instance wide.
This means that every site that is running on that instance must run under https, including ColdFusion administrator itself. For servers that host multiple sites that require sessions, this will generally be problematic. Additionally, if you're running the ColdFusion Administrator from the built in web server, there's a bit of a process to get that working under ssl.
If you need the documented advantages of J2EE cookies, and need the cookie to be secure then all sites that requires sessions must be on https.
If you don't need any of the documented advantages of J2EE cookies, and you're running CF9 or later, then you're better off going with ColdFusion cookies.
Note that Railo still has the same issue but with more flexibility since the cfapplication tag has a sessiontype attribute where you can choose between j2ee or cf session cookies on a per site basis.
I had one tiny problem where I completely lost session variables between requests. I was using a cfhttp post with J2EE sessions. Imagine this scenario:
1. call.cfm in wwwRoot/test folder makes a call to an index page also in the same folder.
2. index.cfm sends the request to wwwRoot/test/controller/login.cfm.
3. login.cfm sets some session variables and sends the user to wwwRoot/test/index.cfm
4. index.cfm does not see the session variables created.
All the send requests are done via cflocation with addtoken="yes".
Turn off the J2EE session variables, and viola! It works just like the way it should.
cflocation and session variables
in the last line in the following bug report
https://github.com/grails/grails-core/issues/5296
it is stated that;
In an ideal world, it would be possible to turn off HttpSession creation for a whole Controller (all actions) and also turn them off for a particular set of actions.
This is however, a quite old bugreport, so my question is:
is this possible in an upcoming or todays version (1.3.7) of grails? If not, shouldn't it be?
The reason i seek this kind of behavior is due to development of RESTful API's in grails, where the very nature of REST is stateless.
Grails does not create a session if you do not access the implicit session object or use session-scoped services. We have multiple projects running in production, where we do not use sessions. As long as you don't access those objects, you won't see any sessions (no JSESSIONID cookies being sent with the response).