Wim Dumon wrote: > Ah! The thing that causes problems is 'reload-is-new-session'. Indeed, > if you don't have a session identifier in the URL and the user presses > reload, the only thing that Wt can possibly use to identify the > session is a cookie. But that is shared within the scope of a browser, > so it's a bad idea to set reload-is-new-session to true and tracking > to Auto. With reload-is-new-session false and tracking=URL, you have > the session ID in the URL.
Hi, Right, that's what I thought. I don't really see the use of 'reload-is-new-session' though - my normal expectation is that a reload is a refresh of the current page, not a new session. > We generally set reload-is-new-session to true, and encode relevant > state on where the user is in the application in the URL, so that when > the user presses reload, we can use the internal path API to return > the user to about the same location in the program. Hmm. In the context of my application the user isn't in a new place, they are in the same place but logged in. Presumably the same confusion would ensue if I changed the URL to have some simple difference that is the same for all logged in users, so I may as well let <tracking>URL</tracking> do the work of keeping things separate for me. Thanks, Graeme Gill. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ witty-interest mailing list witty-interest@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/witty-interest
