On Sun, Mar 11, 2012 at 5:21 PM, Sanjiva Weerawarana <[email protected]>wrote:
> On Sun, Mar 11, 2012 at 10:49 AM, Manjula Rathnayake <[email protected]>wrote: > >> On Sun, Mar 11, 2012 at 10:35 AM, Sanjiva Weerawarana >> <[email protected]>wrote: >>> >>>> Why does anyone want to get the actual cookie value on the server >>>> side?? The session is represented by the session object .. what more do you >>>> want the cookie for? >>>> >>> This is needed when we need to map some state in server side with >>> current session, for example the user who is logged in, need to be stored. >>> I came across this when developing sso relying party. Actually this is >>> available in JSP. >>> >> >> And initially I thought we can store logged in user value in a session >> variable. But when Identity server redirect user to assertion consumer >> service, the session is different from the jaggery app requested. That is >> why I had to maintain the session id and user id in host object >> implementation. >> > > The IS redirection happens before Jaggery app code runs, isn't it?? > The user try to access the Jaggery app. Then user is redirected to Identity server for authentication if user is not established a authenticated session. Then the Identity server redirect the user back to assertion consumer service(another jss). In ACS, the SAML response is validated and user is set authenticated against the session id with session index values in SAML response. This map is maintained in host object. So by passing the session id, we check if the session is authenticated or not. When user log out, the session id is removed from map. Or when Jaggery app get a log out request from Identity server, again the session id is removed from map by checking the value of session index. That is how the current implementation goes on. I will schedule a review on this to discuss issues in this week. > > I'm confused .. if the SESSION_ID is stored, where do you store it and how > do you get it back? The session is where state can be stored and the > session object (which is keyed off the session ID) is equally unique as the > session ID itself. > > I think there's a deeper issue around separating login status from session > status. This is the same problem we have in Carbon admin consoles .. we > confuse loggedin-ness with the lifetime of the session. It should be > different .. let me start a separate thread on that. > Yes, this is true, according to the current implementation, user logged in is depend on the lifetime on the session. I will fix these issues after the review. Thank you. > > Sanjiva. > -- > Sanjiva Weerawarana, Ph.D. > Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/ > email: [email protected]; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1 > 650 265 8311 > blog: http://sanjiva.weerawarana.org/ > > Lean . Enterprise . Middleware > -- Manjula Rathnayaka Software Engineer WSO2, Inc. Mobile:+94 77 743 1987
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
