Re: [OT] Session ID in the URL
On 16/06/05 22:47nbsp;Max Cooper wrote: I think this is a weird requirement, and it may be worth re-evaluating why you want to know this (are you fighting the technology, or leveraging it?). But here are two tips that might help if you decide that you really need to know: 1. request.getPathInfo() -- the jsessionid might be a pathInfo thing. 2. see if the full URL contains your jsessionid, or even just the string jsessionid. getPathInfo() might be interesting for this. Have you tried it Michael? I have use getPathInfo in my code but without setting up my appserver and running it I can't tell. But surely some of the struts taglibs that do the URL re-writing for links and images use JSESSIONID? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Session ID in the URL
On 6/17/05, Adam Hardy [EMAIL PROTECTED] wrote: getPathInfo() might be interesting for this. Have you tried it Michael? I have use getPathInfo in my code but without setting up my appserver and running it I can't tell. No, getPathInfo does not work. I guess I will just stick my own key value into request. But this is just bells and wistles kind of thing ;) Thanks for helping anyway! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Session ID in the URL
On 16/06/05 05:51nbsp;Michael Jouravlev wrote: Was celebrating too early. Does not work. Here what happens. * Very first request to the app. Session is created on server. * Application redirects to whatever location, server sets cookie with jsessionid in the response, and at the same time adds jsessionid to the URL * Browser navigates to the redirected location, it replies with jsessionid in the cookie, so next time server won't rewrite URL. But!!! There is another jsessionid, which was appended to the URL in the redirected request. I want to detect this one. The problem is, that redirected request contains *both* session ID in cookie and session ID in the rewritten URL. Stupid isRequestedSessionIdFromURL() returns false, because it thinks that I should be happy by isRequestedSessionIdFromCookie() returning true. But I want to know both pieces of info: that there is session ID in the cookie, and that there session ID in the URL! It's not stupid, it returns a boolean informing you where the session.getId() gets its info from. Makes sense to me. Although you have my sympathy, wanting something from the API that it just doesn't want to give. Why do you need it? Looks like you would have to hack tomcat to get it. Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Session ID in the URL
On 6/16/05, Adam Hardy [EMAIL PROTECTED] wrote: It's not stupid, it returns a boolean informing you where the session.getId() gets its info from. Makes sense to me. Makes sense to me too, but I also want to know is there session ID in the URL. Any advice how to find this out? Although you have my sympathy, wanting something from the API that it just doesn't want to give. Why do you need it? Looks like you would have to hack tomcat to get it. When both methods return true, they identify the first request after session has been established with browser which supports cookies. I try to keep GET requests clean to encourage browser to keep its page history from growing. When I detect this request to an action mapping, I redirect to same action mapping to clean URL up. After redirection URL will be clean, because session ID will be contained in cookie only. With isRequestedSessionIdFromURL() returning false I cannot do what I need. And doing two redirects each time is not acceptable :) Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Session ID in the URL
On 16/06/05 15:37nbsp;Michael Jouravlev wrote: When both methods return true, they identify the first request after session has been established with browser which supports cookies. I try to keep GET requests clean to encourage browser to keep its page history from growing. When I detect this request to an action mapping, I redirect to same action mapping to clean URL up. After redirection URL will be clean, because session ID will be contained in cookie only. With isRequestedSessionIdFromURL() returning false I cannot do what I need. And doing two redirects each time is not acceptable :) It seems to be hard-coded behaviour that you can't do anything about unless you want to write some javascript to check the URL and put a token in the query string for the next request. Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Session ID in the URL
On 6/16/05, Adam Hardy [EMAIL PROTECTED] wrote: It seems to be hard-coded behaviour that you can't do anything about unless you want to write some javascript to check the URL and put a token in the query string for the next request. Nah, I cannot rely on Javascript. I guess I should drop the idea. Nobody will notice anyway. People don't click Back buttons that often. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Session ID in the URL
On 16/06/05 17:13nbsp;Adam Hardy wrote: It seems to be hard-coded behaviour that you can't do anything about unless you want to write some javascript to check the URL and put a token in the query string for the next request. Stupid me. Even quicker would be to check if you have the first request that establishes the session, and then put some token in the form or querystring, to mimic the JSESSIONID. Then you can just check for your token. I'm just thinking what the test would be to check if it's the first request. getRequestedSessionId == null? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Session ID in the URL
On 6/16/05, Adam Hardy [EMAIL PROTECTED] wrote: Even quicker would be to check if you have the first request that establishes the session, and then put some token in the form or querystring, to mimic the JSESSIONID. Then you can just check for your token. Yes, I guess I can do that. I'm just thinking what the test would be to check if it's the first request. getRequestedSessionId == null? HttpServletRequest.getSession(false) shoud work. I will try and report ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Session ID in the URL
I think this is a weird requirement, and it may be worth re-evaluating why you want to know this (are you fighting the technology, or leveraging it?). But here are two tips that might help if you decide that you really need to know: 1. request.getPathInfo() -- the jsessionid might be a pathInfo thing. 2. see if the full URL contains your jsessionid, or even just the string jsessionid. -Max On Wed, 2005-06-15 at 21:51 -0700, Michael Jouravlev wrote: On 6/15/05, Dave Newton [EMAIL PROTECTED] wrote: David G. Friedman wrote: See the HttpServletRequest API for these methods: boolean isRequestedSessionIdFromUrl() (pre 2.1) boolean isRequestedSessionIdFromURL() (2.1 or later) boolean isRequestedSessionIdFromCookie() This answer is better than mine :) Was celebrating too early. Does not work. Here what happens. * Very first request to the app. Session is created on server. * Application redirects to whatever location, server sets cookie with jsessionid in the response, and at the same time adds jsessionid to the URL * Browser navigates to the redirected location, it replies with jsessionid in the cookie, so next time server won't rewrite URL. But!!! There is another jsessionid, which was appended to the URL in the redirected request. I want to detect this one. The problem is, that redirected request contains *both* session ID in cookie and session ID in the rewritten URL. Stupid isRequestedSessionIdFromURL() returns false, because it thinks that I should be happy by isRequestedSessionIdFromCookie() returning true. But I want to know both pieces of info: that there is session ID in the cookie, and that there session ID in the URL! getQueryString() returns null, because session ID is not treated as regular query parameter. iamsad. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Session ID in the URL
On 6/16/05, Max Cooper [EMAIL PROTECTED] wrote: I think this is a weird requirement, and it may be worth re-evaluating why you want to know this (are you fighting the technology, or leveraging it?). I can explain but remember, that you asked it first ;) It will take some time :) The point is, that I am obsessed with Back button. At best, I want Back button be disabled. If it cannot be achieved, then when I click Back, [stale] page should be reloaded according to current server state, thus it would not actually be stale. At worst, when a caching browser like Opera keeps everything in history and does not reload a page, I would have to check for double submit using either tokens or model data like object IDs or timestamps. Anyway, Netscape, MSIE and Firefox behave like I want. Maybe other browsers too, but I am on Windows, so I cannot tell how Safari or Konqueror behave. Old Netscape, MSIE and Firefox do not accumulate pages in the history, if location of the next page is the same, as location of previous page. Obviously, it is not possible to maintain same location in the interactive application simply because I need to POST input data. Here comes trick with redirect: browser is supposed to drop the request, which preceds redirect. So, whatever I input into my action, I always redirect to the exact same location. Browser does not remember about POST location which preceds redirect. It only remembers the GET location which I redirect to. Because it is always the same (for an action), browser thinks that it is the same page, and does not add in to page history. So, as long as I stay on the same action and redirect to the same location, browser simply reloads the content but thinks that it is the same page (it is not the same, of course). Check out this link: http://superinterface.com/wizard/signupWizard.do Please, open it in a separate window. I hope you do not use Opera ;) What you see is a login dialog. URL in the address bar does not contain jsessionid, but New User Signup link does, it looks something like this: http://superinterface.com/wizard/signupWizard.do;jsessionid=987234?cmd=Init The page was loaded with one simple GET, session was established, and server rewrote the link to include session ID. From here you can either click the link to sign up (GET), or try to login (POST). If you submit with POST, wizard perfoms two-phase request (aka Redirect-After-Post aka Post-Redirect-Get, see Struts Dialogs, it does the same): first it submits input with POST, and here goes the session ID from URL. Then it redirects and loads the page. After redirect, server already knows that browser supports cookies, so it does not append session ID to URL. URL is clean now, browser forgot about POST request because of redirect, so session ID never appears in the address bar and never affects browser history. See, that Back button is not enabled? What if you clicked the New User Signup link instead? When page is loaded for the first time, the link is rewritten and contains session ID. When you click it, it is sent to the server using GET, but this actually does not hurt, because the link contains the command to initialize the wizard. Commands are treated by wizard in the same way as POST requests, they are inputs. So, application redirects in the same way as for POST request, and it comes cleaned up. So, in this particular application everything is great, and session ID does not mess things up. See, that Back button is not enabled! This happened simply because page history is empty, er, it contains only one page: signupWizard.do. Browser does not know that I serve a bunch of different pages from this address. Until you get to the user page, which is served by a separate action, Back button is not enabled and you simply cannot go back and see stale page and resubmit it. This is cool not only because you cannot resubmit a stale page (I need to check for stale page anyway, because not all browsers behave like MSIE and Firefox), but because you get the feeling of desktop application. If you messed up with login five times, you do not need to click Back button five times to get to the previous page. Because in a regular application it won't be previous page, it will be five pages down in the browser session history. This was just a preface ;-))) Now, I have another example where it does not work, here: http://superinterface.com/strutsdialog/allsamples.html If you open browser anew, and go to Login Dialog (init) link, you'll see, that when session is established, address bar shows session ID. So, next time I submit or reload the same action, I get a different URL, that is, without session ID. This is different enough for browser to create a new entry in the session history. I want to detect that session ID is in URL, and to do a second redirect, only once, on startup. Hopefully you managed to read all this and tried the examples ;-) Point is, that on Opera my applications behave the same as other. No, actually,
[More OT] Re: [OT] Session ID in the URL
Is anybody else getting a lot of message duplicates this evening? We're having email server strangeness so I'm not sure if it's me or... uh... not me. Dave Michael Jouravlev wrote: On 6/16/05, Adam Hardy [EMAIL PROTECTED] wrote: Even quicker would be to check if you have the first request that establishes the session, and then put some token in the form or querystring, to mimic the JSESSIONID. Then you can just check for your token. Yes, I guess I can do that. I'm just thinking what the test would be to check if it's the first request. getRequestedSessionId == null? HttpServletRequest.getSession(false) shoud work. I will try and report ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [More OT] Re: [OT] Session ID in the URL
+1. From: Dave Newton [mailto:[EMAIL PROTECTED] Is anybody else getting a lot of message duplicates this evening? We're having email server strangeness so I'm not sure if it's me or... uh... not me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Session ID in the URL
Michael: check out http://www.manfred-wolff.de/struts/articles/HowTo-Back.html for handling BackButtonAction If that does'nt work check out overriding reset() method in ActionForm take a look at http://www.laliluna.de/struts-hibernate-integration-tutorial-en.html HTH, Martin- - Original Message - From: Michael Jouravlev [EMAIL PROTECTED] To: Struts Users Mailing List user@struts.apache.org Sent: Thursday, June 16, 2005 12:28 PM Subject: Re: [OT] Session ID in the URL On 6/16/05, Adam Hardy [EMAIL PROTECTED] wrote: It seems to be hard-coded behaviour that you can't do anything about unless you want to write some javascript to check the URL and put a token in the query string for the next request. Nah, I cannot rely on Javascript. I guess I should drop the idea. Nobody will notice anyway. People don't click Back buttons that often. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Session ID in the URL
Does anyone know, how to find out that URL contains session ID in it? Usually this happens only once in the beginning of a session, if browser supports cookies. I even don't need the value itself, I just want to know that fact, that session ID is appended to URL, not sent as cookie. Session ID is separated with semicolon, and is not treated as query parameter, so I cannot read as parameter. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Session ID in the URL
Michael Jouravlev wrote: Does anyone know, how to find out that URL contains session ID in it? Session ID is separated with semicolon, and is not treated as query parameter, so I cannot read as parameter. Check for sessionId in getQueryString? Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Session ID in the URL
See the HttpServletRequest API for these methods: boolean isRequestedSessionIdFromUrl() (pre 2.1) boolean isRequestedSessionIdFromURL() (2.1 or later) boolean isRequestedSessionIdFromCookie() Regards, David -Original Message- From: Michael Jouravlev [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 15, 2005 4:16 PM To: Struts Users Mailing List Subject: [OT] Session ID in the URL Does anyone know, how to find out that URL contains session ID in it? Usually this happens only once in the beginning of a session, if browser supports cookies. I even don't need the value itself, I just want to know that fact, that session ID is appended to URL, not sent as cookie. Session ID is separated with semicolon, and is not treated as query parameter, so I cannot read as parameter. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Session ID in the URL
David G. Friedman wrote: See the HttpServletRequest API for these methods: boolean isRequestedSessionIdFromUrl() (pre 2.1) boolean isRequestedSessionIdFromURL() (2.1 or later) boolean isRequestedSessionIdFromCookie() This answer is better than mine :) Must... keep... reading... JavaDocs... Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Session ID in the URL
D'oh! Thanks, David! On 6/15/05, David G. Friedman [EMAIL PROTECTED] wrote: See the HttpServletRequest API for these methods: boolean isRequestedSessionIdFromUrl() (pre 2.1) boolean isRequestedSessionIdFromURL() (2.1 or later) boolean isRequestedSessionIdFromCookie() Regards, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Session ID in the URL
On 6/15/05, Dave Newton [EMAIL PROTECTED] wrote: David G. Friedman wrote: See the HttpServletRequest API for these methods: boolean isRequestedSessionIdFromUrl() (pre 2.1) boolean isRequestedSessionIdFromURL() (2.1 or later) boolean isRequestedSessionIdFromCookie() This answer is better than mine :) Was celebrating too early. Does not work. Here what happens. * Very first request to the app. Session is created on server. * Application redirects to whatever location, server sets cookie with jsessionid in the response, and at the same time adds jsessionid to the URL * Browser navigates to the redirected location, it replies with jsessionid in the cookie, so next time server won't rewrite URL. But!!! There is another jsessionid, which was appended to the URL in the redirected request. I want to detect this one. The problem is, that redirected request contains *both* session ID in cookie and session ID in the rewritten URL. Stupid isRequestedSessionIdFromURL() returns false, because it thinks that I should be happy by isRequestedSessionIdFromCookie() returning true. But I want to know both pieces of info: that there is session ID in the cookie, and that there session ID in the URL! getQueryString() returns null, because session ID is not treated as regular query parameter. iamsad. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
