get CGI::Session working

armint has asked for the wisdom of the Perl Monks concerning the following question:

Hi, I'd like to start learning and working with CGI::Session. My (local) installation of the module went fine, but as soon as I want to create a session, I get a '500 Internal Server Error'. Here is a simple test code:

#!/usr/bin/perl

use lib "/www/docs/homes/theissen/scr/perlmods/perllib/";
use CGI;
use CGI::Session;

$q = new CGI;
$session = new CGI::Session(undef,undef,{Directory=>"/www/docs/homes/t
+heissen/scr/session/tmp"});

#$sid = $session->id();

print   $q->header(),
        $q->start_html('Hi'),
        $q->h1('hi'),
        qq[session id: $sid\n],
        $q->end_html;
[download]

When I uncomment the line for session creation ('$session = new...'), the script works (of course, not doing anything with the session, and $sid not being initialized), i.e. the module itself is found. The directory in which the test script is in is cgi enabled (I run ordinary cgi scripts there). On installing cgi::session, I thought I better install it within the cgi enabled area, too.

When I run the script as such from the command line, I don't get any errors. I do get a session id ($sid, of course after uncommenting this line). So I'm pretty lost in figuring what is going wrong. Looks like the problem is not my cgi::session installation, but some server settings?

Any wisdom welcome

cheers

armin

Comment on get CGI::Session working Download Code

Replies are listed 'Best First'.
Re: get CGI::Session working by naikonta (Curate) on Jun 26, 2007 at 15:03 UTC
Check the permission of the directory, make sure the web server process is able to write files in that dir. The Apache is usually running as user `apache` and group `apache`. If the `.../session/tmp` looks like: `drwxr-xr-x 23 armint users 1024 Jun 15 13:42 tmp` [download] then you have a problem. The permission scheme (`drwxr-xr-x` or `775`) and user/group ownership (armint/users) disallows user/group `apache` to write on that dir. If you have privileges to change the ownership, then change it so the owner of that directory is `apache` (but this doesn't prevent your session files from reading by other means). If you don't, and you don't have (or unable to get) someone with required privileges to do so, the alternative is by changing the permission to `777` (gasp!!! highly discouraged). Or, just use the common/shared temporary directory (usually `/tmp` on Linux system), but this means your session files are readable by other users on the system (the same applies with 777-permission). Open source softwares? Share and enjoy. Make profit from them if you can. Yet, share and enjoy!	[reply] [d/l] [select]
Re: get CGI::Session working by CountZero (Bishop) on Jun 26, 2007 at 15:29 UTC
What do you mean by "On installing cgi::session, I thought I better install it within the cgi enabled area, too."? Modules should go where modules live, in `site` or `site-lib` or such, not in the cgi-bin of your webserver. Remove it from there and re-install it in its normal place. That might cure the problem. If not check --as already said by others-- the permissions of your cgi-script and session-file/directory. CountZero "A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James	[reply] [d/l] [select]
Re: get CGI::Session working by polettix (Vicar) on Jun 26, 2007 at 15:08 UTC
Is `/www/docs/homes/theissen/scr/session/tmp` [download] writeable by the user running the web server? What do the web server logs say? Flavio perl -ple'$_=reverse' <<<ti.xittelop@oivalf Don't fool yourself.	[reply] [d/l]
Re: get CGI::Session working by Herkum (Parson) on Jun 26, 2007 at 14:58 UTC
If you got a 500 Internal Error, there should be an error in the web server error log. Check there to see what specifically happened. My off-hand guess is that the web server does not have the permissions to run the script as an executable.	[reply]
Re: get CGI::Session working by armint (Initiate) on Jun 27, 2007 at 13:00 UTC
Hi, thanks for your comments. In fact, the tmp file directory would have been a factor - I moved that to a directory where I know it works since I use it in connection with other (working) cgi scripts (where clients upload files). The permissions are fine, too. Since I have no superuser privileges, I had to install CGI::Session locally. So it shouldn't matter where locally... I did had a look at the server error log, and there it says: `Premature end of script headers: test.cgi Can't locate object method "generate_id" via package "CGI::Session::ID +::" at /www/docs/homes/theissen/scr/perlmods/perllib//CGI/Session.pm +line 75.` [download] So, it doesn't know of the definition of generate_id, which is in Session/ID/incr.pm and static.pm? How can that be? Any way to force Session.pm to look there? I tried 'use lib...' in every .pm file, but with no success. Thanks for all the hints	[reply] [d/l]
Re^2: get CGI::Session working by Herkum (Parson) on Jun 27, 2007 at 19:25 UTC
When you 'use lib', it is just appending that directory to the path where it will look for Perl modules. I don't know if this makes a difference but can you remove that trailing / from the directory path? Also, I wonder if the script is having a problem trying to create the file and is giving you an error. CGI::Session is a great tool but it can be a pain to get working sometimes.	[reply]
Re: get CGI::Session working by armint (Initiate) on Jul 10, 2007 at 15:42 UTC
Hi, I left this issue to rest, and picked it up today, finally got it working! First, I re-installed the package, thinking that something might have gone wrong there. But the real - simple - fix was to change the 'use lib' line to `use lib "/served/httpd/docs.../perllib/lib";` [download] so the path seen from the server (/served...) and the 'lib' subdir. I remember I tried both a week ago but in my general confusion not both together... thanks again for all your replies. I joined this list because of that problem, but browsing around I definetely will stay because there are interesting problems in discussion... armin	[reply] [d/l]