I usually use a cookie path of just '/'. This makes the cookie visible to the entire site. If you have some need to restrict cookie usage to just a particular path, you can try '/' temporarily, just to debug.
Note that sessions can be stored in files or databases, etc. There's a lot of variation available in the configuration. If you are storing the sessions in files, then permission issues can cause problems. The web server usually runs as something like 'nobody', so that user must be able to write the files, have permission to the directory being written to, etc. Lots of people put session files somewhere like /tmp/sessions, but on in a shared host environment, every other site on the same host can potentially see your session data (or accidentally clobber it).
I like using the database method better, but it can be expensive in terms of DB queries (every page view results in multiple hits: a read to check the current login/logout status, then a write to update the time until expiration, etc.). In production usage you want to go with the 'Storable' data store, but for debugging use the default (DataDumper) because the contents of the session object will just be simple ASCII text.
Another 'gotcha' I've encountered occurrs when you try to redirect to a secure page (https) for login, then redirect back to http afterwards. If the https domain is different, then the cookie is written on that domain, and thus not visible elsewhere.
Here's an example:
If your home page is here:
http://www.example.com/home
and you have a login link that takes you here:
https://www.secure.com/login
and then you redirect back to the home page after login (and let's assume you have different content for logged-in versus logged out users, and you depend on the session to determine which is which).
So you can have a successful login, but the cookie containing the session id which points to this state is only visible on the .secure.com domain, not the .example.com domain. So you still get the logged-out version of the home page.
The easy fix is to either do whatever necessary to have a secure url in the same domain:
https://www.example.com
Or else, make your login link point a script that does the following: create/fetch current session id and store it in a cookie. Then redirect to the login page (script you previously pointed login link to) with the session id attached as a url parameter (or, better, don't use a link, make it like a form, and send the id as a hidden parameter). This way the secure host can retrieve/modify the session data without using the cookie. Or, you can create another cookie, on the secure host, containing the same session id, but you need some way of passing that id from one host to the other, else it won't see it (and since you're using CAP:Session, it will actually create a new session automatically, which isn't what you want).
In reply to Re: session file umask
by scorpio17
in thread session file umask
by ksublondie
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |