"If a new users is performing a login in the same browser, I would make sure that the old session is invalidated before the new user is logged in."
The old user may perform important operation ( may by ajax call), may hold important info in the session. Before invalidate the old session, I need to check and wait. That again will be a pain for user. Even if I make the session invalidate, what will be the state of the application for the old user? automatically logged out? I can get the required feature by means of url rewriting, cookies etc. But there are brawbacks of using those. Its always better modern frameworks like S2 handle these concerns rather than developer to worry about. Thanks Rajib Nils-Helge Garli wrote: > > Maybe there's something I jut don't get, but two users sharing the > same issue sounds more like a security hole than a feature to me... If > a new users is performing a login in the same browser, I would make > sure that the old session is invalidated before the new user is logged > in. > > Nils-H > > On Sun, Jan 18, 2009 at 8:54 AM, RajibJana <rajibj...@gmail.com> wrote: >> >> By conversation, I want to mean http session independent conversation. So >> two >> simultaneous users sharing the same http session can work independently, >> storing/retriving their own properties throughout the application without >> having conflict with other user . >> >> Thanks >> >> Rajib >> >> >> Nils-Helge Garli wrote: >>> >>> I agree conversations would be a nice feature, but aren't >>> conversations usually just different states in the application for the >>> same user? I'm having difficulties understanding how it would solve a >>> problem of two simultaneous users sharing the same session. I would >>> say that is more of a login/security issue... >>> >>> Nils-H >>> >>> On Sun, Jan 18, 2009 at 8:26 AM, RajibJana <rajibj...@gmail.com> wrote: >>>> >>>> This is not a authentication/authorization issue alone, app needs to >>>> maintain >>>> various user session specific info that need to be accessed in other >>>> action >>>> classes, enterprise level web app needs that. ( Thats why in SEAM, that >>>> is a >>>> highlighted feature). >>>> >>>> I can implement spring security, thats not the issue, issue is to have >>>> stateful conversation in S2. >>>> >>>> The only solution in S2 is: restrict user to login into app using the >>>> same >>>> session. >>>> >>>> "Restriction" is always bad, IMO. >>>> >>>> Thanks >>>> >>>> Rajib >>>> >>>> >>>> >>>> dusty wrote: >>>>> >>>>> Allowing a user to login again to a different ID using the same >>>>> session >>>>> is >>>>> a FAIL. >>>>> >>>>> It is not really a S2 issue, but an authentication implementation >>>>> issue. >>>>> It is true that S2 does not provide a default >>>>> authentication/authorization >>>>> implementation, but Spring Security does the job very well. Why >>>>> reinvent >>>>> it? >>>>> >>>>> Having a stateful conversation that is independent of the users HTTP >>>>> session is an interesting feature, but not really a basic requirement >>>>> of >>>>> all enterprise web-based applications. There have been several >>>>> suggestions on how you might do this using tokens in the URL, etc. S2 >>>>> does provide the tools to make this happen with interceptors. >>>>> >>>>> My recommendation is to either a) implement Spring Security or b) >>>>> improve >>>>> the session handling of your current authentication mechanism so that >>>>> a >>>>> new session is required in order for someone to login as two different >>>>> users at the same time. >>>>> >>>>> >>>>> >>>>> >>>>> RajibJana wrote: >>>>>> >>>>>> Sorry for replying late, as there is time diff ( living in India) >>>>>> >>>>>> >>>>>> Yes, the app wants SEAM conversation feature. Does S 2.1.6 provide >>>>>> any >>>>>> such feature or any other future version? >>>>>> >>>>>> >>>>>> Thanks >>>>>> >>>>>> Rajib >>>>>> >>>>>> >>>>>> newton.dave wrote: >>>>>>> >>>>>>> Dale Newfield wrote: >>>>>>>> One running browser instance shares session across all windows. >>>>>>>> Using >>>>>>>> Safari and Firefox in tandem will allow two sessions from one >>>>>>>> machine. >>>>>>> >>>>>>> The OP wants a SEAM-like solution, but S2 doesn't have that >>>>>>> functionality built-in (nor do most other frameworks, AFAIK). >>>>>>> >>>>>>> It *would* be a nice feature to add, though. >>>>>>> >>>>>>>>> 2) If one opens two window instances ( not tabbed one), logs into >>>>>>>>> the >>>>>>>>> app by giving different user info [...] >>>>>>>> I would like to know what browser shows this behavior. >>>>>>> >>>>>>> I can never remember which is which, but IIRC IE (pre-6, don't >>>>>>> remember >>>>>>> after that) would give different sessions per-window, FF wouldn't. >>>>>>> In >>>>>>> any case, I agree that it's a bad idea to rely on browser behavior >>>>>>> (unless you're controlling browser deployment, but I don't like that >>>>>>> much either :) >>>>>>> >>>>>>> Dave >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >>>>>>> For additional commands, e-mail: user-h...@struts.apache.org >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> -- >>>> View this message in context: >>>> http://www.nabble.com/Struts-2-session-problem-tp21513305p21524962.html >>>> Sent from the Struts - User mailing list archive at Nabble.com. >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >>>> For additional commands, e-mail: user-h...@struts.apache.org >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >>> For additional commands, e-mail: user-h...@struts.apache.org >>> >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/Struts-2-session-problem-tp21513305p21525105.html >> Sent from the Struts - User mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >> For additional commands, e-mail: user-h...@struts.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > > > -- View this message in context: http://www.nabble.com/Struts-2-session-problem-tp21513305p21525810.html Sent from the Struts - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
