I am searching for a Java library (or a simple class) that is able to manage server sessions for any protocol. My application is not related in any way to HTTP. The sessions have to stay alive between different connections, just like HTTP cookies do.
I guess the way to go is:
client connects to server
client sends the login informations
server replies with a status and a session ID (a long string, just like JSESSIONID or PHPSESSID)
client sends requests to server (with existing or new TCP connections), always providing the session ID
client asks to logout
server deletes the session and invalidates the session ID
I'm just looking for something existing regarding the session management part, even if it's really easy to implement. Otherwise I guess a Map and a random string generator will do the job.
http://docs.oracle.com/javase/1.5.0/docs/api/java/util/UUID.html#randomUUID%28%29
http://www.javapractices.com/topic/TopicAction.do?Id=56
randomUUID() method could be useful in java.util.UUID see above links. It guarantees the id is unique.
If you want to make your session data to be scaled across multiple nodes, you can even try out frameworks like hazelcast, infinispan etc. They also have a provision to generate unique id across nodes.
Related
I need to learn how a tomcat server identify different hosts to create unique sessions. Does it do it
according to Ip ?
Based on answer to this question, I want to be able to create multiple sessions for single client, on a server which uses simply httpServletRequest.getSession() to create new sessions. Is possible to give a predefined session Id to a server, so that that server creates that new session bound to that session Id ?
It doesn't do any identification. Each time a request comes in and you ask for a session to be created, it creates one. The generated session ID is sent to the browser in a cookie, and the browser sends back this cookie for all subsequent requests, which allows Tomcat to find the associated session.
I can't really understand what you're trying to achieve. A session doesn't identify a server. It identifies a specific client of a web app. Each client has its own session ID. Assigning a session ID to a server doesn't make much sense to me.
Turns out if you dont have any cookie, you are treated as a brand new user, and it gives you a new cookie. So not sending a cookie is enough to obtain another session Id.
I know following are the ways to maintain or session tracking in java but looking for a good one
URL rewritting
Hidden form fields
cookies
Session object like setAttribitute() and session.getAttribute()
If the client browser has blocked accepting and storing cookies then last 2 ways are not valid.In hidden form fields I need to pass the hidden values in each and every page inside form.So suppose If I am just using response.sendRedirect() Then hidden form field is of not use.The remaining is URL rewriting in which I will pass JsessionID in the URl.So My question by knowing the sessionID isnt the unauthorized persons can able to access the pages.
For example There are 3 pages login,register,send.So after login user can register and/or send.So if any one knows the sessionID cant he/she go direct to register/send page.If yes Please tell me how to prohibit this
As of Servlet 3.0 (Apache Tomcat 7 onwards) if you use SSL then you can configure your application to track sessions based on the SSL session ID. The downside is that everything has to be over SSL. The advantages are that the session is strongly tied to the SSL connection. Only the user that created the connection to the server that has the correct SSL session has access to the session. Even if an attacker knows the session ID, they can't access the session.
One word of caution, this form of session tracking is the least widely used so it may not have been as heavily tested as the more usual cookie and URL re-writing mechanisms.
Have a look at this link which outlines Best practices for using HTTP sessions
Including
javax.servlet.http.HttpSession.invalidate()
Use HTTPS
With standard solutions you can't.
You can add some measure of security by adding request originator IP address verification, but that's also fooled easily. (to clarify some here means very tiny itsy bitsy little bit of)
So the secure route is to not use URL Rewriting to maintain session in secure application.
However you may be able to get some security by keeping the JSessionID as a separate encrypted attribute that which will be decrypted by a middle-ware or a load balancing server sitting between the client and your application servers. This of course is just a thought, I haven't, fortunately ever had to try something like that out :-)
Session tracking & authentication are two diff things don't club them.
Understanding your requirement I see you want to secure the sessionid of the user.
Evasdroping: If someone is listing to the request & response in the middle he can take the sessionid and use it. The best way would be to use a SSL. This ensures no one is listening in the middle.
Sessionid stolen from Client side: Normally this should be taken care by the browser and OS. So your user is as secure as the system he has.
I need to figure out how to best authenticate users which are connecting from a C++ game client, against a mySQL database on another server, and I plan on writing a java web service to accomplish this.
Security is of primary concern, I need to make sure that the data flowing across the wire is encrypted, so I'll be leveraging SSL (originally I thought about message level encryption using ws-security however I think it's too much overhead).
What I really need to figure out is what kind of authentication mechanism I should provide. These users will be supplying usernames and passwords, and will be issuing a web request to a service.
I haven't decided whether the service should be a traditional SOAP web service or a RESTful one. The whole idea behind rest is to make the server stateless, and since the client will basically be establishing a session with the service, I don't see a point in using REST here.
Having said all that, what I really need to nail down is how exactly to perform the handshake and how to persist the session.
Are there any popular frameworks out there that provide APIs to do this against a mySQL database?
Again the client will offer up a UN / PW to the server, which needs to decrypt them (SSL should take care of that), authenticate them against the account info stored in a mysql DB, and then return some kind of hash or something similar so that the user's session can persist or the user doesn't have to log in anymore to issue additional requests.
Could anyone recommend a framework / some reading material for me to glance over?
Keep things as simple as possible.
HTTP is already stateless, and the idea of a login followed by a continued session is well established (session cookie). Use this paradigm and you won't have any troubles.
You also get the benefit of a very light-weight and open communication protocol and many good libraries for easy serialization / deserialization of common REST payloads like JSON or XML.
REST also means that you can use the same server with other clients quite easily.
I'd take a look at oauth:
http://developers.sun.com/identity/reference/techart/restwebservices.html
A well established pattern is:
1. log in & receive an oauth token
2. store token in db with user's internal id (and any other data such as token expiration time you wish to store).
3. send token to client, client persists token
4. client sends token for all future requests
5. server fetches user info from token
This method should work well with any client language and any backend datastore.
I would recommend to use REST. As authorization framework you can use standard container's jdbc or file realms on JAAS. If login/password pair is successful, store them at client side. After that, you can perform requests with auth credential supplied per request. I used jersey client for this. For [de]serialization from/to XML/json XStream library "do all dat math". Have a nice day.
What would be good/scalable user session alternative in following scenario:
users don't have to have cookies enabled
URL query string restriction of 255 characters is imposed
lot of GET requests (no hidden form fields)
application runs on several servers (web farm)
some users connect over proxy (same IP)
users connect over HTTPS
50 000 concurrent users
If you can guarantee that the client always connects to the same web server, you can use the SSL ID as a simple session tracking mechanism. Some web servers expose this capability and automatically use it for session tracking when cookies aren't supported.
The only solution that will work no matter what is to include a session ID in the URL itself. Adding a parameter to the URL is the simplest way to do this, but the ID can be embedded anywhere in the URL, i.e. as part of the path. You would use this ID to fish information about the user out of a database.
You will run into the usual problems, of course, with ID spoofing and having the session database be a bottleneck.
First, IMHO, there is no good alternative to session. The question is how do you obtain it when cookies are disabled. The answer is using URL parameter. So, you have to append session id to each request (including links and forms). All other requirements are not really relevant. Make your logic stateless, so you do not have scalability problems: all requests should arrive to your logic via load ballancer, so you can add as many servers as you want.
Maybe URL Rewriting or some URI shortening mechanism like http://tinyurl.com or http://goo.gl so you can pass your session details well under 255 chars.
Note: Not recommending to use these services but the mechanism.
First of all, your requirements are very tight.
The only option I see is using an approach like this: http://code.google.com/p/seaside/
In short: your system will generate statless urls like
http://host/app/#123445568978
Then you will go on the db to get the session object.
50000 users doing what? Continuous drag-and-drop with position updates to the server or clicking a text link every 15 minutes? In the last case: move everything onto a single server with a lot of ram.
Once a user is logged in, I create a Java session and store their userid and sessionid (sid) in the session, these two parameters are sent to GWT client and they are stored there in a base GWT client presenter (not as cookies). I am using MVP Architecture.
Every call made to sever there after is sent with these two parameters userID and SID, so I verify this on server, that the current session on server is equal to the session id provided and it belongs to given userid.
IF all is OK, only then I process the RPC request further.
Also, I am planning to make all my RPC handlers to extend a common RPC Handler which will accept these parameters.
I am new to GWT and GAE, any help will be greatly appreciated.
Thanks.
Using SSL and sending the session ID in the payload of every request are two good first steps. This LoginSecurityFAQ provides a good explanation with more details.
Anyone that can intercept the traffic on the wire/airwaves can take control of the user's session UNLESS you're sending session state over ssl/https.