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.
Related
I am facing an issue understanding the oauth2 flow.
A user(identified by a user_id) initiates the GoogleAccounts connection in the browser.The request is passed to Servlet that sends Redirect String To Client (Javascript), which in turn redirects user to that Auth URL.
On User Consent, the response is returned to callback url (mapped to a servlet).
My Confusion here is when callback servlet is called,how do i identify to which user(user_id) does this authCode belong to?
Do i have to use state param of oAuth2 ?
Please help.
As the comments suggest, the state param is your friend. The simplest way would be to simply set state=user_id. An alternate approach would be to start a server session and store the user ID in the session object. This latter approach assumes you have a relatively simple server, or your cluster supports shared sessions.
I have a webapp where a user should be able to access the same session (jsession) through different clients (i.e. from a pc-browser and from smartphone-browser) at the same time.
Example:
A) Person X will access the system through his PC. For expample by browsing http://example.com/testapp?workon=123. The Server will create an new JSESSIONID send it back to the client and store some value - say 'abc' inside his session.
B) Now the same Person X will access the same URL from his smartphone and be able to retrieve the value 'abc' from the session in subsequent requests.
This will not work out of the box, because in B) the client will get a new Session and JSESSIONID which is different than the one provided in A).
When I now force the server to supply the same JSESSIONID to B) as it did in A) will they both be able to access the same session? Is this possible?
I'm asking this, because I want to achieve the following:
The application is running behind a load balancer that has sticky sessions enabled by using the JSESSIONID.
I want to achieve that B will be redirected to the same cluster-node as A) on subsequent requests of B).
The request-parameter "workon" here is just an example. In reality this is a token that the load-balancer cannot understand. Only the application is able to understand and decode the content of the "workon" parameter.
It will be no problem that the first request of B) will go to any node. Any node is able to decode the "workon" paramter any supply the correct JSESSIONID for it to the client. But subsequent request should be redirected to the same node as requests from A) go to.
I do not want to use Session-Sharing across nodes, because of performance issues. The sessions-data is rather large. I want to redirect B) to the same node as A) based on the first Request of B)
Any ideas?
Edit to reflectt questions in comments:
On request A) there is the request parameter "workon" this identifies some record inside a map. This record contains the user and the jsessionid for securely binding. so the load balancer cannot find out the user for the request. The user is not authenticated using any login.
On request B) (from the smartphone) the phone sends a userid and a token on the first request (inside the json/xml payload). the apllication checks that the token is valid for that user (again using some map), then finds the latest "workon" for that user and sends this "workon" back to the smartphone. On subsequent request (Those should go to the same node as A) the smartphone sends the token and the workon parameter.
you cannot use the JSESSION ID token directly if you want the node assignment to persist across different browser (a pc and a mobile as i nyour example)
you would need authentication for that - after authentication you set a cookie on the client which is unique for each user - do not use this cookie to check if the user is authenticated: it will open you to all kind of security issues. just make sure that after logon an user get always the same cookie value
use that cookie to implement sticky session in your load balancer. specific will change according to the balancer, but most of them should understand cookies.
the specific name and content of cookie varies across load balancers.
here is a sample with apache server
apache load balancer: http://httpd.apache.org/docs/current/mod/mod_proxy_balancer.html
http://www.markround.com/archives/33-Apache-mod_proxy-balancing-with-PHP-sticky-sessions.html/
here another one with haproxy:
Load Balancing (HAProxy or other) - Sticky Sessions
notice that for haproxy you should enable the 'preserve' option in configuration, so that the server is in control of the cookie content and can stick the same user to the same backend (after authentication)
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
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.
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