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
