Could someone tell me what should happen if a client initiates a request to a servlet container with a made up (valid) JSESSIONID ? supposing the servlet doesn't have this jsessionid in its records (we're not hijacking a session, just making one up), will the servlet accept this session and use it for all subsequent calls or will it disregard it, make up its own jsessionid and return it to the client?
If a HttpSession cannot be found based on given JSESSIONID, it will just be ignored. A new one will be created whenever demanded by the code and a new JSESSIONID cookie with a new ID will be set.
Related
So I am building this Webservice client and the Webservice (server) requires that I maintain a session and use a unique key, (not the JSESSIONID) generated by the client, only for that session. So I did the obvious.
((BindingProvider)service).getRequestContext().put(BindingProvider.SESSION_MAINTAIN_PROPERTY, true);
Now this works great and I store the unique key and JSESSIONID is part of the headers etc.
The problem I have is that when I want to create a new session. So, another user logs in, I create a new unique key, authorize the user and get a new JSESSIONID. The authorization call seems to still add the other JSESSIONID to the headers and so the Webservice rejects the call. I am not sure how to tell my client service to create a new session? Do I just go new Service.getPort() and use that instance (doesn't seem best practice)? Can I create a Spring bean with a prototype scope (didn't seem to work but maybe I have scoped the wrong bean)? I even tried removing the JSESSIONID from the headers but it never seems to exist when I handle the message. If you need any thing (logs/traces/code) just shout and I'll edit the post.
I'm developing a single page jQuery & Backbone.js web app. The backend is a JBoss 6 application server.
Until now we had the following structure:
There is only one servlet (front controller). Every request from the JavaScript client goes through here.
In the servlet - at the first request of a certain JS client - I make a look p to a stateful session bean. For the next requests of this client, I store the result of the look up in an HTTP session container. So every JS client has exactly one stateful session bean. This connection is kept by a session cookie.
Now I have an additional requirement:
When the user has two browser tabs (in one browser), they should have two isolated instances of the web app in every browser tab. Because of that I have a problem with session cookies because this session cookie is for all browser tabs.
I have to change the structure so that:
The servlet has to generate a new session ID for the first request of a certain JS client. This session ID is communicated to the client.
With every POST to the backend the JS client has to send this session ID.
My question is:
Until now I saved the result of the look up in an HTTP Session object and I hadn't to think about generating a session ID. But now I have to store this somewhere else, where?
Has anybody experience with this kind of setting and can help me?
Update:
Thank you BalusC for this very interesting approach.
When I understood you well, this means:
All individual JS clients of the tabs of one browser share one HTTP session object. And in this HTTP session object, every tab has its own entry point. That sounds really good. So I still can use the whole HTTP session infrastructure and don't have to reinvent the wheel.
Autogenerate an unique value on the initial GET request which you store and pass around on every subsequent postback as a hidden input value. Use this unique value as identifier of the session attribute representing the view-scoped data.
During the 1st request on a brand new session, do:
Map<String, ViewData> viewScope = new HashMap<String, ViewData>();
session.setAttribute("viewScope", viewScope);
(the ViewData represents the view-specific data you'd like to track across postbacks on the same view)
During every GET request, do:
String viewDataId = UUID.randomUUID().toString();
viewScope.put(viewDataId, new ViewData());
request.setAttribute("viewDataId", viewDataId);
During generating the HTML, do:
<input type="hidden" name="viewDataId" value="${viewDataId}" />
During every POST request, do:
ViewData viewData = viewScope.get(request.getParameter("viewDataId"));
// Get/set view-specific data in there.
Make sure that jQuery also passes this hidden input around (which shouldn't be a big problem if you already properly use $(form).serialize() or e.g. AjaxForm plugin to ajaxify the forms).
If you're familiar with Java EE's MVC framework JSF, then it may be useful to know that its #ViewScoped annotation works roughly the same as described above. See also a.o. How to choose the right bean scope?
You can use session tracking with URL rewriting. See here:
Session shared in between tabs
I'm consuming some web services done in java using a Rest architecture, my client it's a mobile application that uses HttpConnection to retrieve the data. In order to control authentication and authorization I'm using cookies, managed by a #SessionScoped class, however I don't know how to make the session persist through requests. The problem basically is that I inject the Session manager in other services that are #RequestScoped, however since the session is not persisted I always retrieve differente instances for the #SessionScoped class, thus deleting all the cookies or records I had before. Looking at the request headers I noticed the cookie JSESSIONID, I think this is sent by tomcat in order to persist session, so tried already to send the same cookie in the next request, however I got no results.
The comments were right... to persist a session you just have to send the JSESSIONID cookie back to server in the next request, the problem in this case was that HttpConnection in JavaME only has the setRequestProperty method to include a header value, now if you set the same value two times it overwrites the last one. Since I was using a custom cookie and the JSessionID cookie, I setted them in the following way:
connection.setRequestProperty("Cookie","sessionId="+ApplicationPreferences.getInstance().getSessionCookieHeader());
connection.setRequestProperty("Cookie","JSESSIONID="+ApplicationPreferences.getInstance().getJavaSessionCookieHeader());
When the correct way to do it is concatenate the cookie strings and then setting a Cookie header with them all:
String myCookies="sessionId="+ApplicationPreferences.getInstance().getSessionCookieHeader()+";"+"JSESSIONID="+ApplicationPreferences.getInstance().getJavaSessionCookieHeader();
I have a web application in which we use JSF framework.
I have been diving deep into the security part for web application and hence I was looking to generate my own unique session ID(using encryption algorithm and assign it to every new session which gets created once user logs in.
Can anyone please guide me on how to set manual generated session id in session and ensure with each request that session id is transmitted.
Thanks.
I really doubt you'll generate session IDs that are more secure than the ones generated by the container, but here's what you could do, without using any container-specific extension.
Create a servlet filter which intercept every request to the server.
When a request comes in, check if a session already exists for this request (using getSession(false)). If one exists, then extract your specific cookie MY_SESSION_ID from the request, and compare its value to the one that is stored in the session. If they don't match, reject the request.
If the session doesn't exist, then create it (using getSession(true)), generate your super-secure session ID, store it as a session attribute and add the cookie MY_SESSION_ID to the response.
This has the disadvantage of creating a session automatically, even if it's not strictly needed. But that's the case most of the time when using JSPs of component frameworks.
Attempting to do this at the JSF application layer is unlikely to be successful; I would perform this task at a lower level API. I am assuming a servlet container.
I can think of two approaches:
do this at a container level via a server-specific SPI (if one even exists)
do this by rewriting requests/responses via a servlet Filter
There is insufficient information to comment on the viability of the first approach.
In the second, you would have to determine the name of the session cookie (it is usually JSESSIONID, but does not have to be). Your API would:
map the filter to all application requests
maintain a map of container session ids to "secure" ids
use the filter to rewrite any session cookie in the request with the session id
use the filter rewrite any session cookie in the response with the secure id
use a listener to remove invalid sessions from the map to avoid memory leaks
I've always taken for granted the JSESSIONID cookie created for every fresh request for a given client when developing applications using the servlet specification. But after giving it a bit of thought, isn't is more logical for the servlet container to create a cookie header only after the session has been requested and created in code? For clients who have their cookies disabled, won't it end up creating a new HttpSession for each request made?
Please let me know if the question is still unclear so I can edit it. TIA.
A new Session will not be created by the Servlet container by default unless the Servlet actually creates it explicitly. Just because in the Header a JSEESIONID is being populated does not mean that there has to be a seesion on the server. An exception to this is in JSPs that by default create a Session if one is not there unless <%# page session="false" %>
As far as not having cookies turned on:
A web container can use several
methods to associate a session with a
user, all of which involve passing an
identifier between the client and the
server. The identifier can be
maintained on the client as a cookie,
or the web component can include the
identifier in every URL that is
returned to the client.
If your application uses session
objects, you must ensure that session
tracking is enabled by having the
application rewrite URLs whenever the
client turns off cookies. You do this
by calling the response's
encodeURL(URL) method on all URLs
returned by a servlet. This method
includes the session ID in the URL
only if cookies are disabled;
otherwise, it returns the URL
unchanged.