Re^2: CGI::Session Question

Thanks.

Unfortunately cookies aren't an option for this project. There is concern that some of our users won't have them turned on. So the project parameters require us to use a session file on the server.

The CAD files are of 3D models (large assemblies) and one of the goals of this project is to serve them to our users as quickly as possible. If they are encrypted, they cannot be served as quickly. We currently provide similar access to similar files via a VPN tunnel and it is slow. After weighing all of our options, this is what we've decided to do and this too is a project parameter.

But my question pertains to the use of CGI::Session. If CGI::Session is called via a SSL connection, and the session object is instantiated via that connection, can you later change the connection (i.e. utilizing a non-secure HTTP header) without breaking the session object? Do you have to maintain the HTTPS connection for the object to remain valid?

Comment on Re^2: CGI::Session Question

Replies are listed 'Best First'.
Re^3: CGI::Session Question by wfsp (Abbot) on Mar 23, 2011 at 15:54 UTC
You mention that ...the SID follows the user thru the site. And also that you're not using cookies (there are reasons not to as you mention). How do you pass the SID to and get it back from the browser? In the URL, a hidden form field? In what way is ...the session object... no longer recognized. Can you see the session file or the db record created (whichever you're using)? I don't use CGI::Session without cookies myself and I don't have a SSL site to hand to play with. Could you post a small snippet that demonstrates the problem you're seeing? It could be that if you're not using cookies you may not need to use CGI::Session.	[reply]
Re^4: CGI::Session Question by Perobl (Beadle) on Mar 23, 2011 at 17:12 UTC
Yes, I was speaking generically when I mentioned that the SID follows the user thru the site. Allow me to elaborate ... though you've guessed right. I'm using CGI::Session to create a session file on the server. I "pass" the SID via the query string (usually, but not always, in a hidden context). I'm also utilizing TT2 (Template Toolkit ... a great template tool btw) so passing the SID to my various templates in a hash is easy. More specifically though, my code fails immediately after I instantiate the session object upon successful user authentication. As soon as this is done I redirect the user to a non-secure HTTP connection to the same domain. So I start by having the user login here: https://mydomain.com/cgi-bin/index.cgi And then I redirect to here ... `print "Location: http://www.mydomain.com/cgi-bin/index.cgi?sid=$sid\n\ +n";` [download] Now, when I created my SSL cert, I neglected to use www in the domain. I'm not sure if this is an issue. I plan to create another cert that includes the www so that both variations can be used to connect securely to the site. Otherwise, the only difference is the HTTP vs. HTTPS connection type. Now, downstream of what I've shared here is where I run into problems. Once the authentication process is complete, the user goes on his/her merry way utilizing various functionality in the site. These additional pieces of functionality are governed by other CGI's. When any of these CGI's is invoked, I run a simple subroutine check to make sure the user's SID is valid: my $sid = $cgi -> param('sid') \|\| undef; # retrieve session id from qu +ery string my $session = new CGI::Session("driver:File", $sid, {Directory => +'/home/mysite/public_html/tmp'}); my $session_email = $session -> param('session_email'); # retrieve + encrypted email (username) from session object my $session_uid = $session -> param('session_uid'); # retrieve uid + (user's id) from session object # if session file doesn't have email or uid info, kill cgi! if (($session_email eq '') \|\| ($session_uid eq '')) { print "Location: http://www.mysite.com/cgi-bin/authentication_ +error.cgi\n\n"; exit; } [download] This last line of code is where things are getting hung up. The session file still exists on the server (I've checked) and the SID is still attached to the user (via the query string) but the CGI can't see $session_email or $session_uid so it terminates the user. This is ONLY happens when I change to HTTPS ... though the www is also "currently" missing from the domain ... as explained above. Hope this helps to clarify my problem, thanks for your help. I've done some "speed trials" this morning (running the CAD data through a secure connection). It is something we "might" be able to live with though we were hoping to go the other route.	[reply] [d/l] [select]