Hey Anthony, 2008/12/3 roja <[EMAIL PROTECTED]>: > Sorry was being mighty dense! Anyway, there still seem to be the problem > (WAnchor/bookmarkURL) as indicated in the "refresing session" email last > night. Here is another example:
I didn't get this first. There is another config option in the play: <reload-is-new-session>false</reload-is-new-session> Usually, I keep this to true, and then I could not detect anything unexpected. But when setting this to false, I could reproduce the same wrong behaviour as you experience. > With JS & Cookies... > > u: http://0.0.0.0:8080/test#/test/path > a: http://0.0.0.0:8080/test#/test/path > > As intended. > u: http://0.0.0.0:8080/test#/retest/path > a: http://0.0.0.0:8080/test#/retest/path > > > [2008-Dec-03 14:21:53.894961] 23524 [/test IQ4ZUmf2U4O5P4G8] [prefix] > "/"127.0.0.1 - - [2008-Dec-03 14:21:53.895710] "POST > /test?wtd=IQ4ZUmf2U4O5P4G8&rand=49253 HTTP/1.1" 200 24 > [2008-Dec-03 14:21:53.895401] 23524 [/test IQ4ZUmf2U4O5P4G8] [prefix] > "/retest/" > [2008-Dec-03 14:21:53.895429] 23524 [/test IQ4ZUmf2U4O5P4G8] [prefix] > "/retest/path/" As intended. > u: Click Link > a: http://0.0.0.0:8080/test/test/click/ > > > [2008-Dec-03 14:23:19.619314] 23524 [/test IQ4ZUmf2U4O5P4G8] [notice] > "Refreshing session" > 127.0.0.1 - - [2008-Dec-03 14:23:19.620306] "GET /test/test/click/ > HTTP/1.1" 200 1628 > [2008-Dec-03 14:23:19.703767] 23524 [/test IQ4ZUmf2U4O5P4G8] [prefix] "/" > [2008-Dec-03 14:23:19.704475] 23524 [/test IQ4ZUmf2U4O5P4G8] [prefix] > "/test/" > [2008-Dec-03 14:23:19.704508] 23524 [/test IQ4ZUmf2U4O5P4G8] [prefix] > "/test/click/" > 127.0.0.1 - - [2008-Dec-03 14:23:19.708738] "GET > /test/test/click/?wtd=IQ4ZUmf2U4O5P4G8&js=yes&ajax=yes&request=script&rand=1617829768 > HTTP/1.1" 200 9031 > 127.0.0.1 - - [2008-Dec-03 14:23:19.896953] "POST > /test/test/click/?wtd=IQ4ZUmf2U4O5P4G8&rand=17487 HTTP/1.1" 200 176 Oops! To be consistent with the no-cookie case, we should spawn a new session and thus discard the session cookie in the incoming URL. If you really want to have a path within the session, you need to use setRefInternalPath() > u: Click Link > a: http://0.0.0.0:8080/test/test/click/test/test/click/ Same problem as supra. This case was not considered yet in the implementation. > With JS & No Cookies > > u: http://0.0.0.0:8080/test#/test/path > a: http://0.0.0.0:8080/test?wtd=Jn5EzDavtNBIIntz#/test/path/ That's okay, given that you indicate that you want refresh to not spawn a new session. That has as inevitable consequence that hte session ID must be encoded in the url. > u: http://0.0.0.0:8080/test?wtd=Jn5EzDavtNBIIntz#/retest/path/ > a: http://0.0.0.0:8080/test?wtd=Jn5EzDavtNBIIntz#/retest/path/ OK. > u: Click Link > a: http://0.0.0.0:8080/test?wtd=Est1KLDaxNYFiihy#/test/click/ OK too (note: new session here). > u: Click Link > a: http://0.0.0.0:8080/test?wtd=xWaYheCjSznPjJxK#/test/click/ Same same. > Again, this all seems quite inconsistent... It's not that bad actually, except for ... > With cookies the second link click causes the repetition of the path. > Without it does not. ... this. > When no cookies the session is not appended to the link (should we be > doing this? and if so i feel there should be another internal helper > function that adds the session-id when it's needed (the non-cookie case) > but not when not.) I think the behavior is correct: without using cookies, and when wanting to handle a reload within the same session, we need the session ID in the url. If you do not like that, you should set <reload-is-new-session> true. There is an internal helper function, in fact there is whole lot of functions that try to sort out how to generate URLs. It turns out to be painfully difficult too, given all the different situations. As to the session-ID: in general you will want it in all URLs, even if you have cookie support, to avoid CSRF attacks. The only exception we allow is a refresh of the entire session, and this has the tacet assumption that a refresh of a Wt session does not lead to a business transaction (e.g. buying an item in an online shop), since that would still allow a CSRF attack. I think that assumption is fair, and, in any case, I would recommend against using cookies for session tracking anyway. (We only got that one right a few months ago). > Also should the link not make use of the aforentioned anchor trick? I.e. > producing the link as: "test#/test/path" I think that would be a valid improvement: setRefInternalPath("/test/path") could set the link always as "test/test/path", but when AJAX is available, catch an onclick to prevent following the link and instead change the internal path to "test#/test/path". I've implemented this in CVS, and it seems to work well. WAnchor::setRef() does not have that intelligence, it simply sets the given Url, and thus this will not change the behavior of your example: bookmarkUrl() deliberately removes any session information and generates a SEO-friendly URL. This will give the behaviour you are looking for (using the new CVS code) ? WAnchor *w = new WAnchor("", "link", root()); w->setRefInternalPath("/test/click/"); > I am sorry about all this by the way, but i am really trying to make use > of wt :) I think this is one of the tricky areas of Wt..., where we try to play well in the web, while keeping the desktop-like API. Regards, koen ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ witty-interest mailing list witty-interest@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/witty-interest
