Hello - In HTTPRequest.py, the HTTPRequest._servletPath is initialized
from REQUEST_URI, if present in the request env, and then falls back to
SCRIPT_URL.
This poses a problem for us because we are using apache with mod_rewrite
to transform the url before it gets to Webware. Apache does not seem to
allow modifying of the REQUEST_URI variable, but it does allow
modification of the SCRIPT_URL variable. The result is that our lovely
mod_rewrite'd uri is ignored by Webware when calculating the
_servletPath of the request. Is there any reason why REQUEST_URI is
prioritized before SCRIPT_URL? It seems more logical to reverse the order.
Example of the problem:
url submitted by the browser: http://mydomain.com/es/path/to/servlet
url after modification by mod_rewrite: http://mydomain,com/path/to/servlet
REQUEST_URI value : /es/path/to/servlet
PATH_INFO value: /path/to/servlet
SCRIPT_URL value: /path/to/servlet
the _servletPath is: /es
This means that cookies are written to the path of "/es/" rather than
the path of "/" which causes users to think their session has been lost.
We worked around this by forcing our own value for _servletPath, but it
could also be resolved by reversing the priority of SCRIPT_URL and
REQUEST_URI when setting the request's _servletPath.
Regards - Ben

Thread view

Hello - In HTTPRequest.py, the HTTPRequest._servletPath is initialized
from REQUEST_URI, if present in the request env, and then falls back to
SCRIPT_URL.
This poses a problem for us because we are using apache with mod_rewrite
to transform the url before it gets to Webware. Apache does not seem to
allow modifying of the REQUEST_URI variable, but it does allow
modification of the SCRIPT_URL variable. The result is that our lovely
mod_rewrite'd uri is ignored by Webware when calculating the
_servletPath of the request. Is there any reason why REQUEST_URI is
prioritized before SCRIPT_URL? It seems more logical to reverse the order.
Example of the problem:
url submitted by the browser: http://mydomain.com/es/path/to/servlet
url after modification by mod_rewrite: http://mydomain,com/path/to/servlet
REQUEST_URI value : /es/path/to/servlet
PATH_INFO value: /path/to/servlet
SCRIPT_URL value: /path/to/servlet
the _servletPath is: /es
This means that cookies are written to the path of "/es/" rather than
the path of "/" which causes users to think their session has been lost.
We worked around this by forcing our own value for _servletPath, but it
could also be resolved by reversing the priority of SCRIPT_URL and
REQUEST_URI when setting the request's _servletPath.
Regards - Ben

Ben Parker wrote:
> Example of the problem:
>
> url submitted by the browser: http://mydomain.com/es/path/to/servlet
> url after modification by mod_rewrite: http://mydomain,com/path/to/servlet
>
> REQUEST_URI value : /es/path/to/servlet
> PATH_INFO value: /path/to/servlet
> SCRIPT_URL value: /path/to/servlet
>
> the _servletPath is: /es
>
> This means that cookies are written to the path of "/es/" rather than
> the path of "/" which causes users to think their session has been lost.
But isn't that the correct _servletPath? Why should the cookies be lost?
The browser uses the url starting with /es/, so this should be just the
right cookie path for your application.
-- Chris

Christoph Zwerschke wrote on 5/24/07 3:04 AM:
> Ben Parker wrote:
>
>> Example of the problem:
>>
>> url submitted by the browser: http://mydomain.com/es/path/to/servlet
>> url after modification by mod_rewrite: http://mydomain.com/path/to/servlet
>>
>> REQUEST_URI value : /es/path/to/servlet
>> PATH_INFO value: /path/to/servlet
>> SCRIPT_URL value: /path/to/servlet
>>
>> the _servletPath is: /es
>>
> >
>
>> This means that cookies are written to the path of "/es/" rather than
>> the path of "/" which causes users to think their session has been lost.
>>
>
> But isn't that the correct _servletPath? Why should the cookies be lost?
> The browser uses the url starting with /es/, so this should be just the
> right cookie path for your application.
>
We're trying to do something sneaky and have the language code be the
first element in the URL, which Apache strips out and sends through to
Webware as a CGI environment variable. That was for search engines to
see the language code as the first element in the URL, rather than at
the end of the URL in an extra path field of query parameter. We want
Webware to set the cookie using "/" as the root path.
I may need to do a more in depth review of the use of _servletPath
within Webware before I can argue it more effectively.

Ben Parker wrote:
> We're trying to do something sneaky and have the language code be the
> first element in the URL, which Apache strips out and sends through to
> Webware as a CGI environment variable. That was for search engines to
> see the language code as the first element in the URL, rather than at
> the end of the URL in an extra path field of query parameter. We want
> Webware to set the cookie using "/" as the root path.
Ok, now I understand the problem better. Your cookies will probably
work, but only as long as you stay in the realm of one and the same
language, right?
If you're doing things like that, one solution is to overwrite
Application.sessionCookiePath() e.g. by putting the following in the
__init__.py file of your default context:
import new
def contextInitialize(app, path):
app.sessionCookiePath = new.instancemethod(
lambda self, trans: '/', app, app.__class__)
I think the best solution will be to add a "SessionCookiePath" setting
to Application.config. The default sessionCookiePath() method will then
evaluate that "SessionCookiePath" setting and use it, or if it is set to
None, then use the servletPath.
-- Chris

Christoph Zwerschke wrote on 5/24/07 12:49 PM:
> Ok, now I understand the problem better. Your cookies will probably
> work, but only as long as you stay in the realm of one and the same
> language, right?
>
yes, but we want the session to follow them when they switch languages.
> If you're doing things like that, one solution is to overwrite
> Application.sessionCookiePath() e.g. by putting the following in the
> __init__.py file of your default context:
>
> import new
>
> def contextInitialize(app, path):
> app.sessionCookiePath = new.instancemethod(
> lambda self, trans: '/', app, app.__class__)
>
> I think the best solution will be to add a "SessionCookiePath" setting
> to Application.config. The default sessionCookiePath() method will then
> evaluate that "SessionCookiePath" setting and use it, or if it is set to
> None, then use the servletPath.
>
Thanks for the suggestion of overriding sessionCookiePath dynamically
like that. I will test it out and use that for the near term solution. I
think the new config setting would be fine, but I wonder if someone
might want to ever choose that value at runtime, rather than force a
constant value.
One tangential thought - with all the new config settings lately,
perhaps it should be easier to subclass the Application object. Or is
that a can of worms that should stay closed? :)
Regards - Ben

Ben Parker schrieb:
> Christoph Zwerschke wrote:
>> Ok, now I understand the problem better. Your cookies will probably
>> work, but only as long as you stay in the realm of one and the same
>> language, right?
> yes, but we want the session to follow them when they switch languages.
Ok. That makes sense.
> Thanks for the suggestion of overriding sessionCookiePath dynamically
> like that. I will test it out and use that for the near term solution. I
> think the new config setting would be fine, but I wonder if someone
> might want to ever choose that value at runtime, rather than force a
> constant value.
Somebody wanted to isolate sessions in different contexts from each
other. By overriding this method you can do such things.
> One tangential thought - with all the new config settings lately,
> perhaps it should be easier to subclass the Application object. Or is
> that a can of worms that should stay closed? :)
I think the Application.config file is not so bad, and everything in it
is well documented. SessionCookiePath wasn't in there so far because it
used to be just '/'. This was changed to the servlet path for security
reasons, but in some cases like in yours, you want it to be '/', so I
think adding a config setting is the best solution. Much easier than
requiring users to subclass Application. I'll be offline for vacation
but made a note to add that setting after the vacation. I think I'll
also publish a 0.9.4 release then since a few bugs have been fixed in
the trunk already.
-- Chris

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details