How can we manage session Object if the cookies is disabled ?. how url encoding is used for this?
The servlet container will handle this for you. If you look at the url in the first time you hit your site, it will have used URL re-writing to append a JSESSIONID to the URL.
This is because the first time the server responds to the client it doesn't know if the client supports cookies or not. It has also written a cookie with the session id in, so on the second request it checks for the cookie and if present stops using URL re-writing, if not it carries on.
You have to use encodeRedirectURL in response object, Please refer this blog it will helpful for you.
http://mytechbites.blogspot.com/2009/08/servlet-session-management-when-cookies.html
it adds jSessionId at the end of URL to map request with session you probably need to configure your server for that too
Use HttpServletResponse.encodeURL() to append jsessionid to your URL, but it is considered harmful.
Find more details here
HTTP Sessions are the recommended approach. A session identifies the requests that originate from the same browser during the period of conversation. All the servlets can share the same session. The JSESSIONID is generated by the server and can be passed to client through cookies, URL re-writing (if cookies are turned off) or built-in SSL mechanism. Care should be taken to minimize size of objects stored in session and objects stored in session should be serializable. In a Java servlet the session can be obtained as follows:
HttpSession session = request.getSession(); //returns current session or a new session
Sessions can be timed out (configured in web.xml) or manually invalidated.
Related
Update1:
Could you give me a short example on how to manage cookies and sessions in play2? (remember me function)
Okay I think I understand the main concept behind the play authentication.
Zentasks uses sessions. I know that sessions are only stored on the server.
And sessions in play2 are already signed. Cookies are not.
What if the users wants to be logged in even if he closes the browser?
I would need to use a cookie.
What should I do?
Do I create a cookie that creates a session?
for example
user has a valid cookie
get cookie val and create a new session
Or do I completely discard sessions and only use cookies instead. Because cookies are not signed automatically by play2 , I have to do it by myself, which I did.
response().setCookie("remember",Crypto.sign(rnd) + "-" + obj.getClass().getName() + "-" + rnd,12000);
(I know I didn't make it secure yet with the secured and http only flag)
I just don't want to invent a new and flawed system. I hope you can clear things up for me how to make authentication secure in play2.
The session scope in Play is nothing more than signed (secure) cookie (and they are stored on client's, not server's side!)
From above docs:
It’s important to understand that Session and Flash data are not
stored in the server but are added to each subsequent HTTP Request,
using Cookies.
so you can keep the logged in state by checking if the session scope's key exists and matches any of your user.
De facto session scope doesn't expire automatically, so your user will be logged in until he'll click on the logout action link (in which you need just to destroy the session's key) (only in some browsers)
This helped me a lot
http://bazaar.launchpad.net/~opensource21/permsec/trunk/view/head:/psec/app
I am confused on the documentation of the javax.servlet.http.HttpSession.
It says:
Sessions are used to maintain state and user identity across multiple
page requests. A session can be maintained either by using cookies or
by URL rewriting.
Now both cookies and URL rewriting are handled by application code in server (i.e. our code).
Then it says relating to when a session is considered as new:
The server considers a session to be new until it has been joined by
the client. Until the client joins the session, the isNew method
returns true.A value of true can indicate one of these three cases:
1. the client does not yet know about the session
2. the session has not yet begun
3. the client chooses not to join the session. This case will occur if the client supports only cookies and chooses to reject any cookies
sent by the server. If the server supports URL rewriting, this case
will not commonly occur.
I am not clear on when it is considered/meant that the client has joined the session.
I mean if I don't use cookies from my web application (or URL rewriting) and I have the following:
POST from IP A to server
200 OK from server to A
POST from IP A to server
In step 3 will the session.isNew() return true or false? It is not clear to me from the doc.
Will it return false (i.e. the session is not new) and I will have to call session.invalidate() in order to create a new session?
The reason this confuses me more is because I am debugging a piece of code where the client is an HTTP application but not a web brower and I see that in step 3 the session.isNew() does not return true although there is no cookies or url rewriting in the server code.
So I can not figure out what is going out under the hood.
Any info that could help understand this?
Here is a nice example of Session Tracking
Client has joined the session means that client made subsequent request and included session id, which can be recognized by your webserver. If cookies are enabled - jsessionid will be passed with cookies, otherwise - it should be include in the URL itself - like this http://localhost:8080/bookstore1/cashier;jsessionid=c0o7fszeb1.
In JSP c:url from Core Tag Library will handle URL rewriting for you.
In case of B2B communication you have to obtain session id by yourself and include it in subsequent requests manually.
Example:
POST from IP A to server
200 OK from server to A
A obtains session id from the response
POST from IP A to server and includes obtained session id
UPDATE:
Consider reading a great article - "Web Based Session Management: Best practices in managing HTTP-based client sessions." It's a general overview of how HTTP sessions can be emulated and is not tied to Java.
I do not have much experience in Java authentication frameworks and authentication workflow in general (only some theoretical knowledge), so for educational purposes I'm trying to create this type of authentication for my HTTP application:
Client Posts login+password to /login.
Shiro logs in the user by given credentials. Server returns client his sessionId.
Client requests some kind of resource /myresource?sessionId=1234567.
Shiro logs in the Subject by given sessionId. Then server does the regular workflow of getting the /myresource (with Shiro managing method-level access rights).
Basically I have these questions:
I guess I have no need for HTTP sessions nor Servlet sessions. Shiro has it's own session manager which is enough for my needs. Am I wrong?
Is it good practice to give client the real sessionId or should I send some kind of sessionToken (which is resolved to sessionId on server side)?
How do I login the Subject using sessionId (which the client should store locally)?
Are there any other things I need to know before doing this kind of authentication?
Thanks in advance.
I guess I have no need for HTTP sessions nor Servlet sessions. Shiro has it's own session manager which is enough for my needs. Am I wrong?
No, you're right. That's why Shiro is awesome. From documentation:
Shiro's Session support is much simpler to use and manage than either of these two [web container or EJB Stateful Session Beans] mechanisms, and it is available in any application, regardless of container.
e.g.
Subject currentUser = SecurityUtils.getSubject();
Session session = currentUser.getSession();
session.setAttribute( "someKey", someValue);
quoting from the doc: getSession calls work in any application, even non-web applications
Is it good practice to give client the real sessionId or should I send some kind of sessionToken (which is resolved to sessionId on server side)?
It is a bad idea to send plain sessionId. Specially, if you're sending data over unencrypted network. Either use something like HTTPS or use something line NONCE.
And, a side note, if over http/s POST data instead of having it in URL.
How do I login the Subject using sessionId (which the client should store locally)?
You meant how could you authenticate the subject once you have session ID? You can simply,
from the doc,
Subject requestSubject = new Subject.Builder().sessionId(sessionId).buildSubject();
Are there any other things I need to know before doing this kind of authentication?
Yes.
Read Shiro's Session Management
Lean about MITM Attack
About HTTPS and SSL
Some on Hash functions this, Apache Commons DigestUtils and may be this
Updates
About that subject authentication part - will it make the newly created Subject the currently authenticated subject? If not, how do I make it the "current" subject?
If you're talking about new Subject.Builder().sessionId(sessionId).buildSubject(), it will not. And I do not know how to set it as currentUser for the thread. Shiro's JavaDoc says,
[this way] returned Subject instance is not automatically bound to the application (thread) for further use. That is, SecurityUtils.getSubject() will not automatically return the same instance as what is returned by the builder. It is up to the framework developer to bind the built Subject for continued use if desired.
so, it's upto you how you bind the subject in current thread or further use.
If you were worried about how SecurityUtils.getSubject(); thingy works, well, in web-container context, it uses simple cookie to store your session-data. When your request comes through Shiro filter, it attached the current subject to request for it's life cycle (current thread). And when you as getSubject() it simply gets the Subject from request. I found an interesting thread here.
about nonce part: If he sends me some kind of hash instead of his sessionId - I won't be able to decode it to get real sessionId (to authorize him with that). Am I missing something here?
Nonce part -- it's a pain in the neck. Now rethinking, I think doing NONCE is just overkill. Let me explain some, anyways,
User logs in first time with his user-name and password. Set userid, nonce (say, UUID), and HASH(sessionID+nonce) ,call it hash1, on client side. Say, in cookie. Store this nonce on server side, may be in DB or in a Map as user_id <--> nonce,session_id
On subsequent request, make sure you passback userid, nonce and the HASH.
On server side, the first thing you will do is validate the request. Get the sessionId and nonce stored in the hashmap or DB based on user_id that was sent by the client. Create a hash, HASH(sessionId_from_db+nonce_from_db), call it hash2.
Now, if hash1 matches hash2, you can validate the request and since you have stored current sessionId on server side, you can use it. On request completion, set new nonce in cookie and on server side.
If you go through 1 -- 4, you'll realize you wouldn't require Shiro for authentication. (:
So, I am taking my words back, NONCE is not applied in this case unless you are too freaky about security over performance.
Why do MITM attack matter to me? My client (javascript ajax code) fetches data from it's server via ajax. So I do not think I should care about MITM in any way.
I think it should matter to you. MITM Attack means your requests/responses are being chained via a machine (MITM) to your router. If it's an unencrypted request, it's all plain text to the MITM. He can see all your requests... and possibly spoof the requests and may hijack session. let me find some example.... http://michael-coates.blogspot.com/2010/03/man-in-middle-attack-explained.html
I'm posting some strings in my Session with the call
request.getSession().setAttribute(key, value);
And making the redirect with
response.sendRedirect(urlRedirect);
In almost all cases the values is there after the redirect.
But sometimes I can only read this value in the next page view, not in the redirect. There is no common behavior.
Someone has faced the same problem?
Sessions are backed by a HTTP cookie. On first-time session creation, a cookie will be set in the response header. By default, cookies are bound to a specific context only.
So, if you redirect while the cookie hasn't been set yet, the session will get lost. To go around this, you need to encode the redirect URL.
response.sendRedirect(response.encodeRedirectURL(url));
This appends the jsessionid identifier to the URL which allows the servletcontainer to locate the right session without help of a cookie.
If you don't like the jsessionid thing, then consider implementing a filter like this which ensures that the client is aware of the session cookie before the request enters your controller wherein you fire the redirect.
Also, if you redirect to a different context, it won't be able to access the same session. To go around this, you need to configure the servletcontainer to share the session among the contexts. In for example Tomcat, check the emptySessionPath attribute of the <Connector> element in /conf/server.xml.
Such a behaviour can be caused by caching.
If the page you are redirecting to is retrieved from the browser cache, you obviously can't see the result of setAttribute() on it. So make sure it's actually requested by the browser.
Are you sure you need to do redirect through browser (response.sendRedirect()) and not on the server side (RequestDispatcher.forward())? Latter is faster as there are no network round trip.
The problem was solve by changing the way of submit.
The page was submitting the data only changing the value of location.href to the Servlet Action.
We only call the submit function from the page form, and the session attributes works fine!
I wants to know that How can i Manage Session if the client browser has disabled cookie feature..
If I wants to implement it in simple JSP - Servlet, then how can I do that ?
Thanks in advance...
Without cookies, you have two options. The first is passing a sessionId through Urls. This requires a lot of work on the server because every url you send back must have a sessionId appended to it (usually in the form of a query string parameter). For example:
/path/to/page
becomes
/path/to/page?sessionid=ASDFG-ASDFG-ASDFG-ASDFG-ASDFG
The other option you have would be to combine what information you have via http into a "unique" key and create your own session bucket. By combining the Http UserAgent, RemoteIp and RemoteXfip you can get close to uniquely identifying a user, but there is no guarantees that this key is 100% unique.
In the JSP side, you can use JSTL's <c:url> for this.
link
Easy as that. It will automagically append the jsessionid when cookies are disabled.
In the Servlet side you need HttpServletResponse#encodeURL() or -usually the preferred one inside Servlets- HttpServletResponse#encodeRedirectURL() for this.
response.sendRedirect(response.encodeRedirectURL("page.jsp"));
url rewriting
http://www.developertutorials.com/tutorials/java/implement-session-tracking-050611/page5.html
Each URL must be encoded using response.encodeURL("page.jsp")
This will add the Session ID onto the end of each URL so cookies do not have to be enabled.
Note that you will have to do this manually for every single URL in order for it to work.
See this link for more info.