Re: [cgiapp] Sessions leaking with FastCGI
On 26/07/2011 01:34, Victor Bruno wrote: Found this in the change logs for CGI that mentions the fix: Version 3.44, Jul 30, 2009 ... 3. Fixed issue in mod_perl fastCGI environment of cookies returned from CGI-cookie() leaking from one session to another. In the docs for the current version (3.55) it also says this: [THINGS THAT MAY BREAK YOUR CODE] url() was fixed to return PATH_INFO when it is explicitly requested with either the path=1 or path_info=1 flag. If your code is running under mod_rewrite (or compatible) and you are calling self_url() or you are calling url() and passing path_info=1, These methods will actually be returning PATH_INFO now, as you have explicitly requested, or has self_url() has requested on your behalf. The PATH_INFO has been omitted in such URLs since the issue was introduced in the 3.12 release in December, 2005. This bug is so old your application may have come to depend on it or workaround it. Check for application before upgrading to this release. Examples of affected method calls: $q-url(-absolute = 1, -query = 1, -path_info = 1 ) $q-url(-path=1) $q-url(-full=1,-path=1) $q-url(-rewrite=1,-path=1) $q-self_url(); I interpret that as path_info is now working correctly when called, whereas between version 3.12 and 3.54 it didn't. I may need to upgrade to 3.55 to fix the leaking sessions issue as I use fastcgi for my app, but I don't want to break it as it uses self_url and path_info quite a lot. But on my devel, test and prod servers I have CGI versions 3.37, 3.42 and 3.43 and have always seen the expected path_info eg /foo/bar?name=fred Anyone know what was supposed to be broken pre-3.55 and why I appear to have been able to use pre-3.55 versions OK? -- Richard Jones --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 110728-0, 28/07/2011 Tested on: 28/07/2011 16:34:05 avast! - copyright (c) 1988-2011 AVAST Software. http://www.avast.com # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Sessions leaking with FastCGI
Turned out to be an old CGI version! After banging my head for weeks and months, turns out the fix was: cpan -i CGI Thought I'd update the thread for anyone else who encounters it. This has been a vanilla CGI app for years, and the very intermittent, occasional, leaking sessions started after a move to fastcgi 6 months ago. Found this in the change logs for CGI that mentions the fix: Version 3.44, Jul 30, 2009 ... 3. Fixed issue in mod_perl fastCGI environment of cookies returned from CGI-cookie() leaking from one session to another. I was using 3.42 $ perl -MCGI -e print \$CGI::VERSION; 3.15 On Sun, Jun 26, 2011 at 11:53 AM, Victor Bruno vicdam...@gmail.com wrote: I was going off of the CAP-Session documentation: ... The recommended place to call session_config is in the cgiapp_init stage of CGI::Application. If this method is called after the session object has already been accessed, then it will die with an error message. ... My app appears to work with session_config under cgiapp_prerun. I will give that a try. Thanks! -Original Message- From: cgiapp-boun...@lists.erlbaum.net [mailto:cgiapp-boun...@lists.erlbaum.net] On Behalf Of d...@skiddlydee.com Sent: Sunday, June 19, 2011 2:01 AM To: CGI Application Subject: Re: [cgiapp] Sessions leaking with FastCGI Victor Bruno vicdam...@gmail.com writes: I am going to try moving my session_config call to prerun from init, since init does not get called on every page request with FastCGI. I'd guess that's your bug and solution right there. And you'd have that same problem in any persistent environment. - dave # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## #### # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Sessions leaking with FastCGI
Victor Bruno vicdam...@gmail.com writes: I am going to try moving my session_config call to prerun from init, since init does not get called on every page request with FastCGI. I'd guess that's your bug and solution right there. And you'd have that same problem in any persistent environment. - dave # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Sessions leaking with FastCGI
On 06/17/2011 12:42 AM, Mark F wrote: I've got a feeling you'll see the same problem with another persistent environment. If fastcgi were mixing up sessions, I think there'd be more talk about it. :) I agree. It sounds like it's a bug in your code that a persistent environment exposed. It most likely would have happened no matter which persistent environment you chose (FastCGI, mod_perl, Starman, etc). Look for global variables or package variables. You should avoid those for anything that changes per-request (or really changes at all). -- Michael Peters Plus Three, LP # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
[cgiapp] Sessions leaking with FastCGI
I have a webapp in cgiapp (Titanium) that I I recently made persistent with
fastcgi. I am hearing sporadic user reports of sessions leaking to the
wrong clients. A user will login and get presented with the homepage of a
different user who is currently logged in and has a live session. I have
been taking stabs at what could be causing it and deploying possible fixes,
only to get another report of it happening again. This problem only cropped
up when I moved to fastcgi. Users are all coming from different IP's so I am
not sure how the CAP:Session could get them mixed up.
I am having a hard time tracking this down. I am using CA:Dispatch,
CAP:Session.
My dispatch script looks like this, so I should be getting a fresh CGI query
object on every call with the my $cgi = CGI::Fast - new(), right?
use lib 'lib';
use strict;
use CGI::Application::Dispatch;
use CGI::Fast;
use FCGI::ProcManager;
my($proc_manager) = FCGI::ProcManager - new({n_processes = 10});
$proc_manager - pm_manage();
while (my $cgi = CGI::Fast - new() )
{
$proc_manager - pm_pre_dispatch();
CGI::Application::Dispatch-dispatch(
args_to_new = {QUERY = $cgi, PARAMS = { cfg_file = 'myApp.cfg'} },
table = ['logout'= {
prefix = '', app = 'myApp', rm = 'logout' },
':inst/:app/:rm/:id1?/:id2?/:id3?/:id4?'= { prefix
= 'myApp::Controller' },
],
);
$proc_manager - pm_post_dispatch();
}
Also, I am wondering about my call to session_config. I still have that in
cgiapp_init - does that need to move to prerun in a persistent environment?
I did add a $self-session-flush() to my postrun. Are there other things
that needs to be done differently under fastcgi with CAP Session or Dispatch
or CGI::Fast?
Victor
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] Sessions leaking with FastCGI
Hi Victor
Looks like no-one replied via the list.
I'll take a guess, but I don't use FastCGI.
More below.
On Thu, 2011-06-16 at 18:50 -0500, Victor Bruno wrote:
I have a webapp in cgiapp (Titanium) that I I recently made persistent with
fastcgi. I am hearing sporadic user reports of sessions leaking to the
wrong clients. A user will login and get presented with the homepage of a
different user who is currently logged in and has a live session. I have
been taking stabs at what could be causing it and deploying possible fixes,
only to get another report of it happening again. This problem only cropped
up when I moved to fastcgi. Users are all coming from different IP's so I am
not sure how the CAP:Session could get them mixed up.
Possibilities:
o The bug was there all along, but moving to FastCGI exposed it
o The bug is in FastCGI
o The bug is in your new code which handles FastCGI
I am having a hard time tracking this down. I am using CA:Dispatch,
CAP:Session.
I don't believe this bug is in those modules.
My dispatch script looks like this, so I should be getting a fresh CGI query
object on every call with the my $cgi = CGI::Fast - new(), right?
I assume so, yes.
use lib 'lib';
use strict;
use CGI::Application::Dispatch;
use CGI::Fast;
use FCGI::ProcManager;
my($proc_manager) = FCGI::ProcManager - new({n_processes = 10});
$proc_manager - pm_manage();
while (my $cgi = CGI::Fast - new() )
{
$proc_manager - pm_pre_dispatch();
CGI::Application::Dispatch-dispatch(
args_to_new = {QUERY = $cgi, PARAMS = { cfg_file = 'myApp.cfg'} },
table = ['logout'= {
prefix = '', app = 'myApp', rm = 'logout' },
':inst/:app/:rm/:id1?/:id2?/:id3?/:id4?'= { prefix
= 'myApp::Controller' },
],
);
$proc_manager - pm_post_dispatch();
}
Also, I am wondering about my call to session_config. I still have that in
cgiapp_init - does that need to move to prerun in a persistent environment?
I did add a $self-session-flush() to my postrun. Are there other things
that needs to be done differently under fastcgi with CAP Session or Dispatch
or CGI::Fast?
I don't think moving it would make any difference. I always
cgiapp_prerun myself.
--
Ron Savage
http://savage.net.au/
Ph: 0421 920 622
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] Sessions leaking with FastCGI
Thanks, Ron.
I am going to try moving my session_config call to prerun from init, since
init does not get called on every page request with FastCGI.
I am also beginning to wonder if mod_perl isn't a more proven alternative.
I was just looking at an old message from Cees Hek in the cgiapp archive
that discusses the different options for using mod_perl.
Hi Victor
Looks like no-one replied via the list.
I'll take a guess, but I don't use FastCGI.
More below.
On Thu, 2011-06-16 at 18:50 -0500, Victor Bruno wrote:
I have a webapp in cgiapp (Titanium) that I I recently made persistent
with
fastcgi. I am hearing sporadic user reports of sessions leaking to
the
wrong clients. A user will login and get presented with the homepage of
a
different user who is currently logged in and has a live session. I
have
been taking stabs at what could be causing it and deploying possible
fixes,
only to get another report of it happening again. This problem only
cropped
up when I moved to fastcgi. Users are all coming from different IP's so
I am
not sure how the CAP:Session could get them mixed up.
Possibilities:
o The bug was there all along, but moving to FastCGI exposed it
o The bug is in FastCGI
o The bug is in your new code which handles FastCGI
I am having a hard time tracking this down. I am using CA:Dispatch,
CAP:Session.
I don't believe this bug is in those modules.
My dispatch script looks like this, so I should be getting a fresh CGI
query
object on every call with the my $cgi = CGI::Fast - new(), right?
I assume so, yes.
use lib 'lib';
use strict;
use CGI::Application::Dispatch;
use CGI::Fast;
use FCGI::ProcManager;
my($proc_manager) = FCGI::ProcManager - new({n_processes = 10});
$proc_manager - pm_manage();
while (my $cgi = CGI::Fast - new() )
{
$proc_manager - pm_pre_dispatch();
CGI::Application::Dispatch-dispatch(
args_to_new = {QUERY = $cgi, PARAMS = { cfg_file = 'myApp.cfg'}
},
table = ['logout'
= {
prefix = '', app = 'myApp', rm = 'logout' },
':inst/:app/:rm/:id1?/:id2?/:id3?/:id4?'= {
prefix
= 'myApp::Controller' },
],
);
$proc_manager - pm_post_dispatch();
}
Also, I am wondering about my call to session_config. I still have that
in
cgiapp_init - does that need to move to prerun in a persistent
environment?
I did add a $self-session-flush() to my postrun. Are there other
things
that needs to be done differently under fastcgi with CAP Session or
Dispatch
or CGI::Fast?
I don't think moving it would make any difference. I always
cgiapp_prerun myself.
--
Ron Savage
http://savage.net.au/
Ph: 0421 920 622
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] Sessions leaking with FastCGI
On Thu, Jun 16, 2011 at 9:29 PM, Victor Bruno vicdam...@gmail.com wrote: I am also beginning to wonder if mod_perl isn't a more proven alternative. I was just looking at an old message from Cees Hek in the cgiapp archive that discusses the different options for using mod_perl. I've got a feeling you'll see the same problem with another persistent environment. If fastcgi were mixing up sessions, I think there'd be more talk about it. :) It would be a good test if you could transition quickly to Plack or mod_perl just to see if the problem continues. # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
