Glassfish Cluster Session Problems On Amazon EC2 Using Elastic Load Balancer - session

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.

Related

How to setup 2 identical Shibboleth SP on 2 redundant servers

For availability purpose, I have a redundant setup with 2 fronts and 2 backs.
Each front hosts a web server, serving the same pages.
Each front runs a instance of Shibboleth SP, redirecting to the same IdP.
Both fronts are behind a load balancer exposing a unique public address. The Load Balancer will have a session affinity set on the shibboleth cookie.
On the first connection, the user is not authentified and Shibboleth SP redirects to the ADFS with a relay state.
After authentication, the ADFS redirects to the LB public address.
Problem is, there is no shibboleth cookie yet. Can the redirection be handled by either instance of Shibboleth SP?
If not, how to properly manage 2 redundant instances of Shibboleth SP as described?
Thanks!
ADFS redirects the user back to the LB address which passes along the SAMLResponse to whatever node it selects, at which point the SP (either) will see a valid SAMLResponse and initiate a cookie. If the user gets pinged to another SP node, that cookie won't be seen by the SP as valid unless both SPs are sharing a common session store, just as a database, and it'll kick through SSO again. Usually session stickyness would be pegged to user's IP so that they always (or almost always) get redirected to same SP instance... and on the offchance their affinity changes they'll still have a valid IDP session and shouldn't see the login page.
A lot of this depends upon your application and how that's built, too... see: https://wiki.shibboleth.net/confluence/display/SP3/Clustering... TL;DR: avoid clustering the SP by leveraging it on a single entry point since it's lightweight (problematic but what I'd usually recommend), or live with sharing a session DB (which has a lot of it's own problems).

Status 419 on laravel project with Load Balancer

I'm using Digital Ocean Load balancer to divide all the requests into 2 separated servers. Both servers are runing the same Laravel application, but when those 2 servers are online and i try to do a post request, sometimes i receive a status 419 and sometimes 200, but when 1 server is offline, the requests works normally
I suppose you are using the default session driver, which is files. Because of this your sessions are set on one of the server and the other server doesn't know of this session. The csrf token set on the form is created and checked using the current session for the visitor, if this request is posted to the other server you will receive an error 419 because this server has no knowledge of the session.
To solve this, you should use a session driver that can be shared between servers like database, memcached or redis.

Is sticky sessions are different than cookie based sessions?

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.

How to maintain session on Amazon ec2 server? How to Prevent session creation for every request?

I am facing very dramatic behavior caused by Amazon EC2 server. I have one web application deployed at Amazon ec2 server which is developed using Spring and Java. For every request new session is created here. I have one scenario where i need to store some data into httpsession object but due to session changing at every time I lost my data.
Your response is respectable.
Thanks.
Please add comment if forget something to mention here and its required to understand.
Let me explain my scenario completely:
I have two machines which have apache installed and integrated with tomcat server using mod_jk connector eg. app0 and app1 machines, this both machines are requested by load balancer of ec2 server. To replicate session for each instance of server i have used DeltaManager jdbc store setting because ec2 does not support SimpleTCPCluster setting.
DeltaManger code:
<Manager className="org.apache.catalina.session.PersistentManager"
saveOnRestart="true"
minIdleSwap="-1"
maxIdleSwap="-1"
maxIdleBackup="20"
processExpiresFrequency="1">
<Store className="org.apache.catalina.session.JDBCStore"
connectionURL="jdbc:mysql://localhost:3306/tomcat"
driverName="com.mysql.jdbc.Driver"
connectionName="username"
connectionPassword="password"
sessionIdCol="session_id"
sessionValidCol="valid_session"
sessionMaxInactiveCol="max_inactive"
sessionLastAccessedCol="last_access"
sessionTable="sessions"
sessionAppCol="app_name"
sessionDataCol="session_data"
/>
</Manager>
This all works fine on my local machine but failed on production as there are two machines and they are handled by ec2 load balancer.
Please comment if any thing else required.
Issue with session was that jsessionid cookie was removed from the request due to the different path. App has a "/" (root) as a path and jsessionid had a path "/". This was causing jsessionid to be removed from the request and since server never received the jsessionid it was creating the new one all the time.
We fixed the issue by adding parameter - emptySessionPath="true" - to all connectors in /etc/tomcat6/server.xml.

Is it possible to connect to a site through a proxy and then disconnect in the same session?

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.

Resources