I was wondering that session management in cloud environments are available in many options for Microsoft azure/ Amazon Web Services / any private cloud. What I was looking that which is the best session management technique which will fit in all the cloud environments.
I have gone through many site but could not decide which is the most suitable in all cases. I read somewhere that Sticky sessions are also one of the option for session management. So looking for an answer which states that is Sticky sessions are different from cookie based session management?
If yes then how to use it?
Thanks
Ravi
Sticky session are likely to stay on same server when the first request comes and provided from same server for each request. Where as cookie based session are nothing but keeping the data on client machine in browser. can be served from any server which is available.
Yes Sticky Sessions are different than cookie based sessions.
As sticky sessions are nothing but handled by load balancers which handles to get sessions in request from client and passes it to the same server where the first request came to that server. E.g. While loading an website request goes to server A, then sessions get stored on server A, while next request comes from user the request sent to the same server i.e. Server A, irrespective of how many servers present in the farm.
Whereas cookie based sessions are stored on client machine, and it gets added with each new request. So it can be read and supported on any server in farm irrespective which server generated and stored session while first login.
Related
I would like to use Spring OAuth2 with a load balancer.
I was thinking that if I use
authorized-grant-types="password,authorization_code,refresh_token"
I will just need a JdbcTokenStore and am good to go because each spring server has access to the same DB.
But now I am reading in this github link
Even with these (Jbc) services ... needs to be fronted by a load balancer with sticky
sessions
Why do I need Sticky Sessions with a JbdcTokenStore?
Any session-based interaction would need sticky sessions, since the session data is not shared between servers. For example, when you authenticate the user during the authorization code flow, they are authenticated and a session is created. If you weren't using sticky sessions then the authentication information might be lost between browser interactions with the authorization server. The session will be used to cache their initial request while they are logging in, and will also retain the authentication information while the user checks and authorizes the scope requested by the client.
First this app works perfectly fine in a non-clustered environment.
The problem we have is when the ELB routes first to one server in a cluster during a session, then to a second server. The second server can't find the session. e.g.
An iOS app passes a login call to a Glassfish 4 server cluster (we're using oAuth/Facebook tokens, so no Glassish security realms).
The Amazon Elastic Load Balancer (ELB) sends to server 1.
Session is authenticated and user logged in and a session cookie passed back to the app.
Immediately the app sends another request which needs authentication (is this a valid session).
The ELB decides to send the request to server 2
In our authenticate servlet filter, server 2 can't find a session with the id passed in with the cookie
The servlet says the user is not authenticated and the call fails.
Our code is pretty typical for finding the session (if no session immediately return fail):
HttpSession session = req.getSession(false);
//psuedocode
if session == null then session not authenticated log and return
else session authenticated, log and return
If the second call gets routed to the same server as the login, the second call works fine. Whenever a call (be it the second, third, fourth, whatever) goes to the second server, authentication fails because it can't find the session on the second server.
I'm looking to see if anyone has encountered something like this and how you have resolved the issue. Is it better to use sticky sessions on the ELB, or is Apache web server using JK or AJP a better choice?
Two potential issues off the top of my head:
Have you specified <distributable/> in your web.xml?
Could be a multicast issue. EC2 does not support multicast, which is what GlassFish uses by default. Check out this stackoverflow thread that discusses the topic, including non-multicast clustering.
I am using a jQuery plug-in to create a cookie (https://github.com/carhartl/jquery-cookie) and have been allowing the cookie to default to a "session cookie". Which is exactly the behavior I would like to have. My concern is that when I deploy my web site to Production, that it will be in a web farm on that environment. Can anyone help me understand what kind of issues, if any, that I will run into with session cookies on a web farm? The version of IIS on the web farm is IIS 7.5.
No issues at all. Cookies are stored on the client. They don't know or care about your server side infrastructure and how many nodes you have.
There are 2 types of cookies:
Session cookies - live only in the memory of the webbrowser and do not survive browser restart.
Persistent cookies - stored as files on the file system for a specified duration and survive browser restarts.
From the perspective of the server it makes strictly no difference. The cookie will be sent by the client on each request and the node that is serving the request will receive this cookie.
If on the other hand you are storing some information in the memory of the web server, such as for example using ASP.NET Session with the default InProc state then you will have problems. But this has nothing to do with client side cookies.
For a web application I could figure no session cookies stored . There was a string as
SSLJSESSION=0000SESSIONMANAGEMENTAFFINI:-1
From my understanding , this cannot be used to handle sessions , Still the application is handling the sessions properly .
Can anyone please tell me how session handling is done with the above technique ?
After a bit of browsing through WebSphere’s documentation, I found out that WebSphere (actually IBM HTTP Server as well as SUN One Web Server) support a feature called SSL ID Session Tracking. Basically, what this does is bind web application sessions to SSL sessions. This further does not require the web application to do almost any session handling since the server performs this on behalf of the application.
I was wondering if it is possible to log into a site with the normal login form (take facebook for example) through a proxy server. Once logged in, can a person disconnect from the proxy and use their normal ISP connection to access the members area on the site without logging in again?
Thanks!
It depends on how the site manages state. If sessions are tied to a particular remote host, then no. Otherwise, there's nothing preventing it. Typically a session is managed via cookies or something similar that the browser sends with every request. Thus whether or not the proxy is there is irrelevant to the maintenance of the session state.