For me it works. remove every bookmarkUrl and use setRefInternalPath - but is there any way to use without setRefInternalPath? So the URL doesn't change?
Greetings Torsten Koen Deforche schrieb: > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/witty-interest > > ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
