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
