On Wed, Apr 7, 2010 at 3:44 AM, George Niculae <[email protected]> wrote: > Hi All, > > I'm investigating a solution for solving > http://track.sipfoundry.org/browse/XX-6132 > - what I've tried was to store the session id in Border component and to > compare it (on pageValidate) with the current session id (to figure out if we > are on the same session or it changed). If the original session id is > different than the current one than the browser gets redirected to home page > (so the page is updated and reflect the logged in user role).This approach > was tested in Firefox and it works OK. > > The only possible drawback I see is that the original session id should be > persisted in client scope (to be available also after session is invalidated) > - results in an additional query parameter in each URL, like: > https://localhost:8443/sipxconfig/acd/AcdPresenceServer.html?state:Home=BrO0ABXckAAAAAQEADiRjb21tb24kQm9yZGVyAA1vcmlnU2Vzc2lvbklkdAANYmY5cWtnZGZpNDRsNw%3D%3D
As long as Home=BrO0ABXckAAAAAQEADiRjb21tb24kQm9yZGVyAA1vcmlnU2Vzc2lvbklkdAANYmY5cWtnZGZpNDRsNw%3D%3D is an encoded Tapestry value representing the id it looks OK to me. Usually such ids can be safely kept in URLs In addition, I think that it would be even better if we can hide that encoded id in a cookie (instead of putting it in URL) - URLS would look nicer Cookies are defined in the browser, on the client side and I guess that Tapestry has ways to manage them. +1 Mircea > > On Tapestry site it says that: > > "Client persistence does not scale very well; as more information is stored > into the query parameter, its length can become problematic. In many cases, > web browsers, firewalls or other servers may silently truncate the URL which > will break the application. > > Use client persistence with care, and store a minimal amount of data. Try to > store the identity (that is, primary key) of an object, rather than the > object itself." > > Since we would only store the session id I think we are safe, but would like > to know your thoughts about this > > Thanks, > George > > > > > _______________________________________________ > sipx-dev mailing list [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev > sipXecs IP PBX -- http://www.sipfoundry.org/ > _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
