That is the behavior of any product - they don't use the same session ID after we login in.. In case they do - then its a security hole.. So there should be a way LB can handle this...
Thanks.. Sent from my mobile device On Jul 23, 2013, at 4:37 AM, Afkham Azeez <[email protected]> wrote: > I would consider this as a major blocker at the platform level & not just > ELB. None of the products would work with any type of LB when session > affinity is enabled. > > -- > Afkham Azeez > Sent from my phone > > On Jul 23, 2013 5:58 AM, "Afkham Azeez" <[email protected]> wrote: >> So, how can we fix this to work with LBs with session affinity? Not only >> ELB, this breaks session affinity in other LBs too >> >> -- >> Afkham Azeez >> Sent from my phone >> >> On Jul 23, 2013 12:09 AM, "Prabath Siriwardena" <[email protected]> wrote: >>> We need to generate the session id after user logs in. Earlier it was the >>> same session id before user logged in and even after user logs in. Which is >>> a security hole. >>> >>> Thanks... >>> >>> Sent from my mobile device >>> >>> On Jul 22, 2013, at 11:55 PM, Sameera Jayasoma <[email protected]> wrote: >>> >>>> Hi Devs, >>>> >>>> I set up a simple cluster with one AS and one ELB. This ELB is improved to >>>> work with Hazelcast clustering. AS joined the cluster and ELB correctly >>>> dispatched requests to the AS node. Then I started testing the management >>>> console access. When I entered the correct username/password and submit, I >>>> got the login page again. But I should have got the successful login >>>> message. I saw the successfully logged in message in server logs of AS >>>> node. >>>> >>>> After analyzing debug log messages of ELB, I noticed an unexpected >>>> behaviour of the AS node. Every time I login into the management console, >>>> AS node creates a new http session. I.e. "Set-Cookie" header is presents >>>> in the login response from AS. I compared with a previous release of AS >>>> and this behaviour was not there. So there has to be a recent change to >>>> the authentication process of the Carbon management console. My guess was >>>> correct. In fact there was a change done by Prabath to regenerate the http >>>> session every time a user logs in or logs out of the management console. I >>>> think this change was introduced to fix a bug in the system. Prabath can >>>> please explain why? >>>> >>>> This new behaviour of the authentication process cause the ELB to break. >>>> Session affinity implementation of ELB is responsible for this. Let me >>>> explain. >>>> >>>> SynapseCallbackReceiver checks for a HttpSessionDispatcher instance in the >>>> synapse context object in the response path. LoadBalancingEndpoint is >>>> responsible for setting the HttpSessionDispatcher in the synapse context >>>> object in the request path. HttpSessionDispatcher extracts the new session >>>> cookie( from the Set-Cookie header), if any and creates a corresponding >>>> session object in the ELB side. This session object maintains session ID, >>>> associated member node, session expiry time etc. All the subsequent >>>> request with this session cookie are routed to the same member node. In >>>> the current implementation LoadBalancingEndpoint sets the dispatcher to >>>> the synapse context only if the request is not bound to any session. I.e. >>>> request does not have any session cookie, a new session. >>>> LoadBalancingEndpoint does not sets the dispatcher if the request contains >>>> the session cookie. >>>> >>>> With the recent fix in the authentication process, it creates a new >>>> session even thought the login request is bound to an existing http >>>> session. Now when this login response which is in a new http session(with >>>> a Set-Cookie header) reaches ELB, ELB does not create the corresponding >>>> session object. Because the dispatcher is not set in the synapse context. >>>> That was because the login request was bound to an existing session. But >>>> the AS node invalidates the existing session and new created a new one. >>>> Therefore logged in session is lost in the ELB. >>>> >>>> IMO the correct fix wold be to set the dispatcher to all the requests if >>>> the session affinity is enabled in ELB. Let me know your thoughts. I will >>>> do the necessary modifications. >>>> >>>> Thanks, >>>> Sameera. >>>> >>>> -- >>>> Sameera Jayasoma, >>>> Architect, >>>> >>>> WSO2, Inc. (http://wso2.com) >>>> email: [email protected] >>>> blog: http://sameera.adahas.org >>>> twitter: https://twitter.com/sameerajayasoma >>>> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections >>>> >>>> Lean . Enterprise . Middleware
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
