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

    Random conversation id's

    Stuart Douglas Master

      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
          Pete Muir Master

          Why do you want to do this?

          • 2. Re: Random conversation id's
            Norman Richards Master

            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.

            • 3. Re: Random conversation id's
              William E. Sollers III Newbie

              +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.

              • 4. Re: Random conversation id's
                Pete Muir Master

                Sounds like a good idea to me :) I'm concerned that trying to hook into current methods like the OP described would break something.

                • 6. Re: Random conversation id's
                  Christian Bauer Master

                  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.

                  • 7. Re: Random conversation id's
                    Stuart Douglas Master

                     


                    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

                    • 8. Re: Random conversation id's
                      Christian Bauer Master

                      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.

                      • 9. Re: Random conversation id's
                        Stuart Douglas Master

                        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.

                        • 10. Re: Random conversation id's
                          Norman Richards Master

                          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.

                          • 11. Re: Random conversation id's
                            Pete Muir Master

                            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.

                            • 12. Re: Random conversation id's
                              Stuart Douglas Master

                              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.

                              • 13. Secure conversation IDs seem critical to maintaining request
                                Marcus Adair Newbie

                                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.