Webware for Python

> After some tweaks in the webware context config, all is working 
> quite fine. (migration was easy :) .. but the session doesn't work
> any more. And even worst I try to do some debuging, and find that
> trans.request()._environ['HTTP_COOKIE'], contains some cookies but
> not the SID one, beside this cookie is present on the browser side. 
> 
> Hum, just wordering if I missed something ?? 

Probably, since this is working well for me. ;-)
Some things that you can check:

* Did you create a new working dir with MakeAppWorkDir and merged
   your project there or did you take the old one?
* If you create an empty (default) working dir, does it work?
* Have you set
   UseAutomaticPathSessions = False
   UseCookieSessions = True
* Are you using mod_rewrite?

-- Chris

For un unknow reason I haven't receive the answer from Chris .. 
So this is a cut/paste from the mail archive. 



>> After some tweaks in the webware context config, all is working 
>> quite fine. (migration was easy :) .. but the session doesn't work
>> any more. And even worst I try to do some debuging, and find that
>> trans.request()._environ['HTTP_COOKIE'], contains some cookies but
>> not the SID one, beside this cookie is present on the browser side. 
>> 
>> Hum, just wordering if I missed something ?? 

> Probably, since this is working well for me. ;-)
> Some things that you can check:

> * Did you create a new working dir with MakeAppWorkDir and merged
   your project there or did you take the old one?

I used MakeAppWorkDir, and merged with my project. 


> * If you create an empty (default) working dir, does it work?

It should work (as my app is running), I only have some issues 
with Session (all other is working fine) 


> * Have you set
>    UseAutomaticPathSessions = False
     UseCookieSessions = True

Here is my conf: 

# The session ID can be prefixed with "hostname" or any other string:
SessionPrefix = None # no prefix to session ID
IgnoreInvalidSession = True
UseAutomaticPathSessions = False
UseCookieSessions = True


> * Are you using mod_rewrite?

mod_rewrite + mod_wekit2 

I used a URLDispatcher too.. but I don't think the issue is here .. 


==============================================================================
<VirtualHost *:80>
ServerName larsen-b.com

DocumentRoot /var/www/larsen-b.com/www/

<Location /wk>
 WKServer localhost 8087
 SetHandler webkit-handler
</Location>


RewriteEngine on
RewriteRule ^(.*)/archives/(.*).html$ $1/Article?id=$2 [QSA]

RewriteRule ^/static/(.*) /var/www/larsen-b.com/www/static/$1 [L]
RewriteRule ^/(.*) /wk/blog/$1 [L,PT]
</VirtualHost>
============================================================================


Thanks for any help

Jkx wrote:
>> * If you create an empty (default) working dir, does it work?
> 
> It should work (as my app is running), I only have some issues 
> with Session (all other is working fine) 

I mean, do sessions (e.g. the CountVisits example) work when you create 
an empty working dir?

> Here is my conf: 
> SessionPrefix = None # no prefix to session ID
> IgnoreInvalidSession = True
> UseAutomaticPathSessions = False
> UseCookieSessions = True

That's all default and ok.

>> * Are you using mod_rewrite?
> 
> mod_rewrite + mod_wekit2 
> I used a URLDispatcher too.. but I don't think the issue is here .. 

Well, mod_rewrite can be the problem. The reason could be that Webware 
sets your cookie path to /wk/blog/ but your webbrowser does not know 
about /wk/blog so it ignores the cookie. You can check the cookie path 
with Firefox for instance.

I'll try with a similar config when I find some time.

-- Chris

On Mon, 14 May 2007 19:02:16 +0200
Christoph Zwerschke <cito@...> wrote:

> Jkx wrote:
> >> * If you create an empty (default) working dir, does it work?
> > 
> > It should work (as my app is running), I only have some issues 
> > with Session (all other is working fine) 
> 
> I mean, do sessions (e.g. the CountVisits example) work when you create 
> an empty working dir?

I haven't checked this, but if I don't use apache (by configuring local 
http), everything is Ok . 


> 
> > Here is my conf: 
> > SessionPrefix = None # no prefix to session ID
> > IgnoreInvalidSession = True
> > UseAutomaticPathSessions = False
> > UseCookieSessions = True
> 
> That's all default and ok.
> 
> >> * Are you using mod_rewrite?
> > 
> > mod_rewrite + mod_wekit2 
> > I used a URLDispatcher too.. but I don't think the issue is here .. 
> 
> Well, mod_rewrite can be the problem. The reason could be that Webware 
> sets your cookie path to /wk/blog/ but your webbrowser does not know 
> about /wk/blog so it ignores the cookie. You can check the cookie path 
> with Firefox for instance.

Hum, I missed to say that firefox see the SID cookie, the issue is that 
my code doesn't have it, so create a new session cookie at each request. 

In awake(), I checked for  trans.request()._environ['HTTP_COOKIE'] this
give me some cookie but not the SID one .. 


Bye .

Jerome Kerdreux schrieb:
> Hum, I missed to say that firefox see the SID cookie, the issue is that 
> my code doesn't have it, so create a new session cookie at each request. 
> 
> In awake(), I checked for  trans.request()._environ['HTTP_COOKIE'] this
> give me some cookie but not the SID one .. 

Yes, Firefox sees the SID cookie, but when the cookie has set the wrong 
path, Firefox does not send it back to your Webware application. You can 
view the cookie path in Firefox and compare with the URL path of your 
application. Do they fit together?

-- Chris

On Mon, 14 May 2007 22:54:58 +0200
Christoph Zwerschke <cito@...> wrote:

> Jerome Kerdreux schrieb:
> > Hum, I missed to say that firefox see the SID cookie, the issue is that 
> > my code doesn't have it, so create a new session cookie at each request. 
> > 
> > In awake(), I checked for  trans.request()._environ['HTTP_COOKIE'] this
> > give me some cookie but not the SID one .. 
> 
> Yes, Firefox sees the SID cookie, but when the cookie has set the wrong 
> path, Firefox does not send it back to your Webware application. You can 
> view the cookie path in Firefox and compare with the URL path of your 
> application. Do they fit together?


Hum .. I guess you found something. The url is http://www.larsen-b.com/Articles/X.html 
but the cookie path is "/wk/"  ... Do you have a idea to fix this ? 

Thank a lot.

Jerome Kerdreux wrote:
> Hum .. I guess you found something. The url is http://www.larsen-b.com/Articles/X.html 
> but the cookie path is "/wk/"  ... Do you have a idea to fix this ? 

I cannot see how this happens with the rewrite rules you posted, but you 
wrote that you are using another URLDispatcher. So I assume,

http://www.larsen-b.com/Articles/X.html

is somehow redirected to something like

http://www.larsen-b.com/wk/blog/Articles?id=X

But because the redirected URI is completly different, Webware cannot 
determine the correct cookie path and sets it to '/wk' instead of '/'.

Can you check the following? In WebKit/Request.py there are the 
following lines (two times):

if i >= 0:
     self._servletPath = self._uri[:i]

Can you change both of these cases to:

self._servletPath = i >= 0 and self._uri[:i] or '/'

Let me know if this solves the problem.

-- Chris

Ho I miss to answer, this email !

/me slaps me !!! 

In fact, I hand patched this stuff like Christoph ask, but I run into 
other issues.. mainly cause I already asked the URLParser before: 

http://www.larsen-b.com/Article/91.html 

I managed to fix the issue, but don't ask me exactly how. After this,
I run into other issues on this website (mainly docutils API changes)
so, I decided to quick fix that and keep it running in the current 
stage. 

I need to find another blog system in fact. This one, works fine, but
as I don't maintain it, I run into this kind of stuff at each apt-get 
update :) 

Thanks a lot webware fellows for the support :)

Jkx a écrit :
> Hi all,
>
> I've been off webware for a while now, but yesterday I need to
> update my website, and I run into some issues with an old webware 
> install (which work smothly since 2 years).
>
> I switched to mod2_webkit, and last stable webware release 0.9.3 + 
> apache 2.2 (my previous setup was mod_webkit + apache 2 + ww 0.7). 
>
> After some tweaks in the webware context config, all is working 
> quite fine. (migration was easy :) .. but the session doesn't work
> any more. And even worst I try to do some debuging, and find that
> trans.request()._environ['HTTP_COOKIE'], contains some cookies but
> not the SID one, beside this cookie is present on the browser side. 
>
> Hum, just wordering if I missed something ?? 
>
> Thanks for any help  ;)
>
>   

I also upgraded my webware application, when changing my hosted server.
I reinstalled everything from scratch.
I went from a centos4 to a fedora core 6.
from 0.9.2 to 0.9.4
The mod2-webkit was the one from 0.9.0, and now it is 0.9.4
I'm also using mod_rewrite to rewrite from the web root to /wk

I now have several problems.
The first one was the session no more working. To resolve it, I had to
stop webware, erase all sessions, and restart my web browser to clear
the cookies. My users also complained about that...
Now it seems to work.

The most annoying problem I have is that the AppServer is now freezing
after several hours.
A simple restart doesn't work, I have to do a kill -9 to kill the
process, then restart.
I don't know how to debug this as it is in production.

I will revert to the previous server, then try to reproduce the problem.
I hope the session incompatibility will not show up again...

> I will revert to the previous server, then try to reproduce the problem.
> I hope the session incompatibility will not show up again...

Yes, you should check the new version on the old server and the old 
version on the new server to see whether it is an issue of the server or 
or Webware. I have 0.9.4 in production running on two servers for some 
time now, and haven't met any problems.

Concerning the sessions, this may have to do with the more secure 
default cookie path for Webware. It will be probably using '/wk' now, 
while you had been using '/'. If you still experience problems with the 
cookies, you can set a fixed cookie path in 0.9.4, setting 
'SessionCookiePath'. But the default setting should work fine normally.

If your servers have different Python versions, check that the server 
has write access to create new .pyc files or recompile these.

Please note that I will be offline for 3 weeks and cannot help with 
Webware during that time...

-- Chris

Christoph Zwerschke a écrit :
> Concerning the sessions, this may have to do with the more secure 
> default cookie path for Webware. It will be probably using '/wk' now, 
> while you had been using '/'. If you still experience problems with the 
> cookies, you can set a fixed cookie path in 0.9.4, setting 
> 'SessionCookiePath'. But the default setting should work fine normally.
>   
I made some investigation on the session problem, there seems to be a
bug with 0.9.4 and mod rewrite.

As I said earlier, I use mod_rewrite just to map / to /wk/ and nothing else.
This means that I have /wk/Servlets paths public.

Now looking at firefox cookie list, when I go to my server root url, I
get a SID cookie with the path set to //
When I go to another /wk/* url I get another cookie with the path set to
/wk/
This make 2 separate webware sessions!

everytime I come back to /, the webware session is reset...

With my other 0.9.2 webware, I get only one cookie set to /

Using 'SessionCookiePath' to '/' seem to fix the problem...

I think the default cookie path should not depend on the path before
going through mod_rewrite but the destination path : /wk/

I still can't reproduce the AppServer freeze.
But I corrected a memory leak in my code.

Will try to go again in production...

Sorry for the late answer, I was offline was some weeks.

sophana wrote:
> Now looking at firefox cookie list, when I go to my server root url, I
> get a SID cookie with the path set to //

This is a bug. It should only be '/'. I have already fixed it in the 
trunk. Can you try again with the HTTPRequest module from SVN?
http://svn.w4py.org/Webware/trunk/WebKit/HTTPRequest.py

> When I go to another /wk/* url I get another cookie

But this would be redirected to /wk/wk/* and not work anyway?

> I think the default cookie path should not depend on the path before
> going through mod_rewrite but the destination path : /wk/

The problem is that the cookie path is evaluated by the browser, so you 
need to set it to the path *before* rewriting takes place.

Can you let me know whether the latest HTTPRequest module solves the 
problem? If not, can you send me your Apache config so I can reproduce 
the problem?

-- Christoph

Christoph Zwerschke a écrit :
> Sorry for the late answer, I was offline was some weeks.
>
> sophana wrote:
>   
>> Now looking at firefox cookie list, when I go to my server root url, I
>> get a SID cookie with the path set to //
>>     
>
> This is a bug. It should only be '/'. I have already fixed it in the 
> trunk. Can you try again with the HTTPRequest module from SVN?
> http://svn.w4py.org/Webware/trunk/WebKit/HTTPRequest.py
>
>   
I reverted to 0.9.2 because of the cookie clear bug which I couldn't
find a workaround.
I'll try when I get some time on the devel server.
>> When I go to another /wk/* url I get another cookie
>>     
>
> But this would be redirected to /wk/wk/* and not work anyway?
>
>   
No, in my case I only redirect / (^/$) with [PT] rewriting (Pass Through)
Other urls are not redirected.
>> I think the default cookie path should not depend on the path before
>> going through mod_rewrite but the destination path : /wk/
>>     
>
> The problem is that the cookie path is evaluated by the browser, so you 
> need to set it to the path *before* rewriting takes place.
>
> Can you let me know whether the latest HTTPRequest module solves the 
> problem? If not, can you send me your Apache config so I can reproduce 
> the problem?
>
>   
As I said I reverted.

Here is the rewrite rule (apache 2):

    RewriteEngine on
    RewriteRule ^/$ /wk/Main [PT]
 
Thanks for your support.

Sophana wrote:
> I reverted to 0.9.2 because of the cookie clear bug which I couldn't
> find a workaround.

If you provide a test case for that bug, I'll try to fix it in the next 
version.

>> But this would be redirected to /wk/wk/* and not work anyway?
> No, in my case I only redirect / (^/$) with [PT] rewriting (Pass Through)
> Other urls are not redirected.

> Here is the rewrite rule (apache 2):
> 
>     RewriteEngine on
>     RewriteRule ^/$ /wk/Main [PT]

Ok. I thought you used something like

RewriteRule ^/(.*) /wk/$1 [L,PT]

In your case, since you have to servlet paths, you need to use the least 
common path, i.e. set CookiePath explicitly to '/'.

Maybe we should make '/' the default CookiePath again instead of None 
(automatic determination)? This is less secure, but at least it will 
always work (Microsoft policy ;-) This issue has already caused too much 
confusion in the past.

-- Christoph

Christoph Zwerschke a écrit :
> Sophana wrote:
>   
>> I reverted to 0.9.2 because of the cookie clear bug which I couldn't
>> find a workaround.
>>     
>
> If you provide a test case for that bug, I'll try to fix it in the next 
> version.
>
>   
>>> But this would be redirected to /wk/wk/* and not work anyway?
>>>       
>> No, in my case I only redirect / (^/$) with [PT] rewriting (Pass Through)
>> Other urls are not redirected.
>>     
>
>   
>> Here is the rewrite rule (apache 2):
>>
>>     RewriteEngine on
>>     RewriteRule ^/$ /wk/Main [PT]
>>     
>
> Ok. I thought you used something like
>
> RewriteRule ^/(.*) /wk/$1 [L,PT]
>
> In your case, since you have to servlet paths, you need to use the least 
> common path, i.e. set CookiePath explicitly to '/'.
>
> Maybe we should make '/' the default CookiePath again instead of None 
> (automatic determination)? This is less secure, but at least it will 
> always work (Microsoft policy ;-) This issue has already caused too much 
> confusion in the past.
>
>   
Could you tell us more about this security problem?

Sophana wrote:
> Christoph Zwerschke a écrit :
>> Maybe we should make '/' the default CookiePath again instead of None 
>> (automatic determination)? This is less secure, but at least it will 
>> always work (Microsoft policy ;-) This issue has already caused too much 
>> confusion in the past.
>>   
> Could you tell us more about this security problem?

The problem with the session cookie path is explained in this document:
http://www.net-security.org/dl/articles/cookie_path.pdf

-- Christoph