13 Replies Latest reply on Oct 16, 2007 2:36 PM by jbmadair

Random conversation id's

swd847 Sep 17, 2007 2:19 AM

Is this the correct way to implement random conversation id's?

@Observer("org.jboss.seam.beginConversation")
 public void RandowmConversationId()
 {
 Manager.instance().updateCurrentConversationId("" + Math.round(Math.random() * Integer.MAX_VALUE));
 }

1. Re: Random conversation id's

pmuir Oct 14, 2007 12:21 PM (in response to swd847)

Why do you want to do this?
Actions
2. Re: Random conversation id's

norman.richards Oct 14, 2007 5:15 PM (in response to swd847)

I've always been worried about bookmarked URLs. If you bookmark a URL with, for example, id=5, it's not very farfetched to think that at some point in the future when you use the link that you will have an existing conversation with an id 5 that you'd be stepping into. If conversation IDs were large and unlikely to repeat, the risk of this would be reduced. I could also see why someone might care about conversation id uniqueness for logging/monitoring purposes.

It would not be a bad idea at all if we used an id generator component that users could override (maybe with a timestamp or GUID-based id) if they so desired.
Actions
3. Re: Random conversation id's

wsollers Oct 14, 2007 5:28 PM (in response to swd847)

+1 for a UUID. Random does not guarantee that the id will be unique at the time it is generated so there is a chance for a collision. A UUID on the other hand alleviates that concern.

Currently for monitoring purposes from an interceptor I use a UUID that I outject from conversation startup so that I can uniquely identify what sessions & principals are on my applications as well as what the state of their conversation / biz proc (outcomes exceptions etc...).

Basically a self rolled admin console results. Not necessary in a regular web app but in a DOD Logistical system a requirement.

Just my 2 cents.
Actions
4. Re: Random conversation id's

pmuir Oct 14, 2007 5:49 PM (in response to swd847)

Sounds like a good idea to me :) I'm concerned that trying to hook into current methods like the OP described would break something.
Actions
5. Re: Random conversation id's

norman.richards Oct 14, 2007 10:57 PM (in response to swd847)

http://jira.jboss.com/jira/browse/JBSEAM-2105
Actions
6. Re: Random conversation id's

christian.bauer Oct 15, 2007 2:43 AM (in response to swd847)

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.
Actions
7. Re: Random conversation id's

swd847 Oct 15, 2007 8:18 AM (in response to swd847)

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.

I have two use cases where this can happen:

1) A user bookmarks a page with the cid=2. They come back to your site later without using the bookmark, and while using it decide that they want to access the bookmarked page, but as cid=2 is already in use they will be redirected somewhere unexpected.

2) A user has mutliple windows open and then leaves your site until session timeout, when they come back they log in in one of the windows and continue working. They then try and use one of their pre-existing windows, and get redirected to an unexpected place because the cid was re-used while they continued to work.

2 is the reason why I wanted this, I know it is not a biggie, but it is confusing to the user, and whenever my users are confused the first thing they do is ring me, especially as my app encorages the use of multile windows (actually iframes, but the same principle applies). It seems to work ok, I have not noticed anything broken.

Stuart
Actions
8. Re: Random conversation id's

christian.bauer Oct 15, 2007 8:40 AM (in response to swd847)

1) No, they will get a new Session ID and the cid=2 is not used (assuming that they bookmarked a non-conversational page - which is the normal case). We are already discussing if appending the ID of a temporary conversation makes sense at all.

2) User error, agreed this might be useful for that case. So while it's not the same as playing the lottery it's still quite unlikely to get a collision because identifiers are constantly incremented.

I'm against this because I need incremental conversation IDs to debug my application, e.g. in the log.
Actions
9. Re: Random conversation id's

swd847 Oct 15, 2007 8:54 AM (in response to swd847)

The feature request is for the ability to overide the cid generator with a seam component. This would make it very easy to use incremental cid's in development and UID's in production to eliminate any chance of cid collision's, while still making it easy to debug.
Actions
10. Re: Random conversation id's

norman.richards Oct 15, 2007 9:35 AM (in response to swd847)

I've hit the problem many times before. Even if it were "quite rare", it's still worth providing another strategy for users who are concerned about it. Although I think we should change the default behavior, I am not inclined to do that because of the increased URL complexity. People are already turned off by seeing the conversation id in the URL. Having a strong converstion id would be even scarier.
Actions
11. Re: Random conversation id's

pmuir Oct 15, 2007 9:39 AM (in response to swd847)

I'm +1 on providing a UUID/GUID strategy, -1 on changing the default strategy. Anyway, I'm not convinced this is super high priority.
Actions
12. Re: Random conversation id's

swd847 Oct 15, 2007 9:24 PM (in response to swd847)

I have submitted a patch to the JIRA that uses a session scoped conversationIdGenerator. This is my first attempt at submitting a patch, so all comments/criticisms are welcome.
Actions
13. Secure conversation IDs seem critical to maintaining request

jbmadair Oct 16, 2007 2:36 PM (in response to swd847)

Huge ++ on making it easy to override conversation Ids.

The level of criticality is such that we'll have to make them secure regardless of whether we have to do it as a hack or are supported by a Seam feature.

I was actually hoping that conversation Ids would start fresh from 1 for each new session, since that's a completely acceptable solution as far as I can tell. But from testing it appears that Seam increments conversation Ids globally.

I'd be surprised if anyone with more than trivial apps (or blogs) really wants to have visibility into volume of conversation id's generated, there's just available for a competitor to read into that. So I'm guessing that a lot of developers just haven't thought about the implications enough yet otherwise there would likely be more requests for other options.
Actions

Go to original post