Sorry, I did catch multiple browser scenario :) I will look at it. Conversations must be on the same session
Conversation = cid + session id Thanks; ________________________________ From: Gurkan Erdogdu <[email protected]> To: [email protected] Sent: Sat, November 14, 2009 9:14:01 PM Subject: Re: [jira] Created: (OWB-163) Conversations are not scoped to a particular session Hi; I think that this is the normal. When you delete cookie, your session is still valid on the server side until session times out/invalidated. If you send a get request via cid parameter, conversation is restored again using that cid. Conversations are deleted when session times out or is invalidated. I do not see any security hole on this. This is similar to session management without cookies. If you do not use cookies, then JSESSIONID is used on every url that server sends. Browser sends every request with JSESSIONID parameter. If somebody steals your session id, then he can simulate fake requests but security must be managed by the application in somehow. Thanks; --Gurkan ________________________________ From: Sven Linstaedt (JIRA) <[email protected]> To: [email protected] Sent: Sat, November 14, 2009 3:40:39 PM Subject: [jira] Created: (OWB-163) Conversations are not scoped to a particular session Conversations are not scoped to a particular session ---------------------------------------------------- Key: OWB-163 URL: https://issues.apache.org/jira/browse/OWB-163 Project: OpenWebBeans Issue Type: Bug Components: Context and Scopes Affects Versions: 1.0.0 Reporter: Sven Linstaedt Assignee: Gurkan Erdogdu Priority: Blocker According to the spec 6.7.4: "All long-running conversations are scoped to a particular HTTP servlet session and may not cross session boundaries." If I create a long running conversation and delete my browser cookies (or switch to another browser vendor) the conversation is still available by attaching the CID to the request URL. IMHO this is a high security risk, therefore I created this issue as a blocker. I stumbled upon this while trying to provide incremental instead of random CIDs to long running conversations. I am using a nightly build of the trunk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
