SOLVED: How to create sessions via FastCGI?

[Ray.Zachary]

Hey guys,

I thought CGI::Session could work fine with CGI::Fast for creating & manipulating Sessions.

For this is the first time I use FastCGI, I wrote a test script first:

#!/usr/bin/perl
#/var/www/htdocs/index.fcgi
use CGI::Fast qw(:standard);
use CGI;
use CGI::Session;
while ($q = new CGI::Fast) {
    my $session = CGI::Session->new ("driver:file", $q, {Directory => 
+'/tmp'})
        or die "Session Initializing Failed.\n$!";
    $session->expire('60');
    $session->param('s1', 'XXX-S1-XXX');
    $session->param('s2', 'XXX-S2-XXX');
    $session->param('s3', 'XXX-S3-XXX');
    print $session->header (
        -type     => 'text/html',
        -charset => 'utf-8',
        -title     => 'test page');
    my $var = $q->param('var');
    print "var = $var.";
    print end_html;
}

This looks fine when I run this script with `perl /var/www/htdocs/index.fcgi` under command line, it created a session file under "/tmp".

But when I access this page via web browser, it won't create a session file(at least there's no new session file in /tmp), but the page output was fine(include the value of $var).

Do you have any idea with this?


Thank you Almut, for helping me again, you are so cool. And thanks to everyone here. This problem has solved by add a statement "$session->flush();" to the last line of loop.
As cpan said:

flush()
Synchronizes data in memory with the copy serialized by the driver. Call flush() if you need to access the session from outside the current session object. You should call flush() sometime before your program exits.
As a last resort, CGI::Session will automatically call flush for you just before the program terminates or session object goes out of scope. Automatic flushing has proven to be unreliable, and in some cases is now required in places that worked with CGI::Session 3.x.
Always explicitly calling flush() on the session before the program exits is recommended. For extra safety, call it immediately after every important session update.

I was confused, I thought flush() was just like delete(), because that word made me to think of "flushing a toilet".
haha

[almut]

Try flushing the session.  As the FastCGI processes are running persistently, the flushing of the data - which otherwise happens automatically when a process exits - has to be done explicitly when you have multiple FastCGI instances serving requests (at least, that's my experience with CGI::Session in persistent contexts).

[bluescreen]

What webserver are you using? Has the webserver's process owner permission to write in the /tmp ? Is the webserver running in chroot mode?

Those are the things I'd ask myself in order to diagnose this. one further thing you can do is instead of using CGI::Session, try to create a new file with the open command in the same location and see if you can, if you cannot you can read $@ to see what the problem was. This is usually a problem with permissions

[Ray.Zachary]

The web server is Apache 2.2, without chroot.
I've checked the permission of /tmp, permission is 777, and I've made my CGI scripts wrote some session files in there before.
So I thought it passably not caused by permission.

[afoken]

/tmp should have mode 01777, not 0777.

Alexander

[Anonymous Monk]

or die "Session Initializing Failed.\n$!";

No

or die "Session Initializing Failed!", CGI::Session->errstr(), " ";

[vtwin4christ]

I wanted to add a comment here as this article helped point me in the right direction.

Issues we were seeing:
1) Sometimes the session ID in the code was not that of the cookie we saw on the client side.
2) We isolated this down to having more than one instance of FastCGI running as failure rates increased the more instances one had going.
3) Even with a single instance, we still had failure.
4) Restarting apache also trashed our session for end clients.


After much review... I found success in doing the following:
1) DONT create your session within the FastCGI loop.
2) DO create your session inside an area that is called by your fast CGI app. In our case it was something like "ProcessRequest".


By us change the where we created sessions... We were able to:
1) Constantly read a cookie. Even after an apache restart.
2) Handle multiple instances of FastCGI 1-???.
3) Timeouts from FastCGI also no longer had negative impacts on our sessions.


Good luck... Glad I could share our resolution. And thanks for the original post as this is what helped me find our issues.