> From Craig McClanahan: > The "jsessionid" path parameter is indeed added by the call that Struts > automatically makes to response.encodeURL() when setting up URLs for you. > Without this automatic feature, you'd have to call encodeURL() yourself in > order to ensure that your application works when your client does not have > cookies enabled. >... > There is no configuration parameter to turn this off, and there won't be. > The important principle you should get used to is that the actual contents > of the request URL is pretty meaningless in a web application based on > Model 2 design patterns. You're far better training yourself (and your > users) to ignore the URL completely rather than obsessing over the > detailed contents.
What are of concern to site maintainers are the security implications of passing the jsessionid in the URL. Consider the following scenarios (assuming user has cookies disabled): 1) The "Referer" header now contains the jsessionid. An example exploit on this would be on a struts-based web email site. A malicious 3rd party sends an html email to a user which contains an html link back to the 3rd party's site. The user opens the email in the struts-based web client and clicks the link. The malicious 3rd party now has the session id and can impersonate the user, as long as the session hasn't timed out. Note that the referer header is sent on https-to-https links as well in most if not all browsers, so using SSL doesn't solve the problem. 2) User A wants to share a struts-based link with User B. They copy the URL they are on and send it to User B. User B clicks the link and is inadvertently logged in as User A, as long as the session hasn't timed out. So, a site that wishes to avoid these risks might impose a "cookies must be enabled" rule. This rule is commonly imposed by major web sites - mail.yahoo.com, for example. Note: I'm not suggesting that this is the reason that yahoo chose to require cookies, but it establishes the fact the enforcing a "cookies only" policy is common today. My understanding (and I'd be pleased to be wrong) is that with non-customized Struts, imposing a rule like this and keeping the jsessionid always out of the URL is not possible. This seems restrictive, and perhaps should be re-evaluated. One part I'm not clear on is whether or not this can be solved at the App Server level. Perhaps if the app server doesn't honor the jsessionid parameter as a session establishment method, this might be a way around the problem. Though even there, it seems in scenario 1 above that the malicious 3rd party would still receive the jsessionid, because struts will send it regardless of app server settings. The malicious 3rd part could then forge a cookie containing the jsessionid, and they'd still be able to impersonate the user by passing the id in via a cookie. Regards, Tom Wadzinski -- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>
