[ http://jira.jboss.com/jira/browse/JBSEAM-2105?page=comments#action_12382364 ] Christian Bauer commented on JBSEAM-2105: ----------------------------------------- Ahem, conversation IDs are _already_ globally unique because by definition, they are combined with the unique session ID. There is no way you can "step back into conversation 5" from a bookmark with a reasonably short session timeout. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-2105?page=comments#action_12382439 ] Christian Bauer commented on JBSEAM-2105: ----------------------------------------- Yes, which is, combined with the new session ID, globally unique. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-2105?page=comments#action_12382516 ] Christian Bauer commented on JBSEAM-2105: ----------------------------------------- It's still a unique request. The only scenario where a collision might happen is the one described by the user, with the two open tabs and a session timeout. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-2105?page=all ] Stuart Douglas updated JBSEAM-2105: ----------------------------------- Attachment: patch_file I have created a patch for this issue, I use a session scoped ConversationIdGenerator component to generate the conversation id's. This component can be overridden by the user to generate conversation id's any way they want. I am not sure if this any good or not, this is my first attempt at submitting a patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-2105?page=comments#action_12382861 ] Marcus Adair commented on JBSEAM-2105: -------------------------------------- Is there any chance that instead of incrementing conversation Ids globally they are incremented per session? This solves (1) security problem of showing volume of generated conversation Ids to the public and (2) keeps conversation Ids small with low level of extra URI parameter cruft. I'm all about making it possible to override the generator as well, since people will have other considerations, but if there aren't some corner cases that I'm missing then this is probably the override I'd prefer anyway and perhaps it would be a good default for a lot of people. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-2105?page=comments#action_12383080 ] Marcus Adair commented on JBSEAM-2105: -------------------------------------- Perhaps I'm mistaken, but according to a test by another member of my team, the conversation id is currently globally incremented, meaning that although it is only valid within a single session, the number is incremented at the application level, so two users in two sessions starting four conversations would have conversation Ids 1, 2, 3, and 4. If this is the case then the global increment is precisely what we perceive as a security problem, so I'm in agreement with you, Norman. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-2105?page=comments#action_12383121 ] Marcus Adair commented on JBSEAM-2105: -------------------------------------- I am actually realizing that while its accurate to say that global increments on conversation ids is a "security problem", the subtlety is that exploiting the problem is not what people typically think of in terms of hackers finding ways to break in or create problems, but rather is the leakage of private business data that could be exploited at a strategic level by a competitor or some other external party. I guess that's stating the obvious, but in case the subtlety is lost I figure it doesn't hurt to point out explicitly where the danger is. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-2105?page=all ] Norman Richards closed JBSEAM-2105. ----------------------------------- Resolution: Done The conversation id strategy is now overridable. I did not implement any alternative strategies, as I don't know which (if any) alternative strategies are truly going to be of general interest. I did try to implement your proposed strategy, so please let me know if this is going to be sufficient for you or if you anticipate needing something a bit more. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira