RE: session tracking enforcement
Hi, Is there any way to enforce a session cookie (JSESSIONID)to be send to the client (browser) from servlet. No, because the Servlet Spec says Servlet Container must work even on clients that don't support cookies (or have cookies turned off, which is becoming a more and more common use-case). Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: session tracking enforcement
Is there any way to enforce a session cookie (JSESSIONID)to be send to the client (browser) from servlet. No, because the Servlet Spec says Servlet Container must work even on clients that don't support cookies (or have cookies turned off, which is becoming a more and more common use-case). Session cookies (those that don't persist) are becoming quite common actually because even small devices are able to keep that bit of session state quite easily. Also, device makers want their devices to work on the widest variety of systems, and session cookies are used just about everywhere, whereas URL rewriting is less common. Nost web users allow cookies, and fewer still restrict session cookies that comes from the primary site (as opposed to one generated by those advertising goofs). While the container may not support this enforcement, you could at least warn users using a series of redirects. 1) On first load, if no session cookie exists (or your own session-oriented cookie if you like), add the cookie and redirect to a cookie checker page. 2) If the cookie checker page does not detect the cookie, then it can display a warning/error to the user telling them that session cookies are required to use your site. If it finds the cookie, then it can redirect either back to the main page or to whatever page you want them to go to next since you know they have the cookie. David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: session tracking enforcement
Hi, Session cookies (those that don't persist) are becoming quite common actually because even small devices are able to keep that bit of session state quite easily. Ahh yes, small devices. Good point. I based my earlier assertion on research I read recently showing a (and this is a good thing) jump in use of cookie blockers, popup blockers, spyware blockers, etc. But I bet the authors didn't consider small portable devices like cell phones etc. But that's details, the main point I made still holds, and that's that the Servlet Spec mandates Tomcat's behavior in this area. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: session tracking enforcement
Is it true, that new sessionId will be resend if a new session get created? --- Shapira, Yoav [EMAIL PROTECTED] wrote: Hi, Session cookies (those that don't persist) are becoming quite common actually because even small devices are able to keep that bit of session state quite easily. Ahh yes, small devices. Good point. I based my earlier assertion on research I read recently showing a (and this is a good thing) jump in use of cookie blockers, popup blockers, spyware blockers, etc. But I bet the authors didn't consider small portable devices like cell phones etc. But that's details, the main point I made still holds, and that's that the Servlet Spec mandates Tomcat's behavior in this area. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: session tracking enforcement
But that's details, the main point I made still holds, and that's that the Servlet Spec mandates Tomcat's behavior in this area. Absolutely, Yoav! I certainly didn't mean to imply anything negative about your response, only that the original inquiry could be handled/checked by his application fairly easily, even if the servlet spec doesn't allow it to be enforced through configuration. Besides, when using servlets, it's really not much work to encode urls for those users who don't support cookies, and then you can handle a wider range of clients as you accurately pointed out. David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: session tracking enforcement
In my case it looks like I do have encode all URLs: firewall problem with stripping out sessionId left me with no choice ;) Is it right way of doing it? Thanks a lot. Mark. --- David Wall [EMAIL PROTECTED] wrote: But that's details, the main point I made still holds, and that's that the Servlet Spec mandates Tomcat's behavior in this area. Absolutely, Yoav! I certainly didn't mean to imply anything negative about your response, only that the original inquiry could be handled/checked by his application fairly easily, even if the servlet spec doesn't allow it to be enforced through configuration. Besides, when using servlets, it's really not much work to encode urls for those users who don't support cookies, and then you can handle a wider range of clients as you accurately pointed out. David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: session tracking enforcement
In my case it looks like I do have encode all URLs: firewall problem with stripping out sessionId left me with no choice ;) Is it right way of doing it? ACK! There's a firewall that's stripping out session ids from URLs but will let cookies through? There's a security no-brainer in charge... smile Or maybe it's just an Microsoft bigot in control, though security no-brainer may still apply... (Sorry -- sort of -- for my poor taste in jokes.) I can't answer about right way since firewalls that block standard web access will tend to cause standard web applications to no longer work. That's like blocking port 80 and 443 and then saying that is it right to make your web site work on port 8080. It's the firewall that's messed up, not your application. Unfortunately, you may have to work with it regardless of the poor decision of the firewall owner. Certainly, if you want, you can use the redirect scheme to detect if the cookie is there. In fact, you can even just check if the session can be maintained through the redirects since Tomcat will fall back to cookies if it can for its session id. And in the end, if your session works either way, then you don't have to force people to use session cookies. But people who want to use ANY authenticated web application will have to allow session cookeis or URL session ids because it's the way web applications handle state management. Good luck! David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
