Jump to content

Recommended Posts

I want to increase the timeout of a session on my website.

I've added this code to my .htaccess file (I don't have access to php.ini):

php_value session.gc_maxlifetime 2592000

php_value session.cookie_lifetime 2592000

 

This appears in the local value when I do phpinfo(), but it doesn't lengthen the session timeout.

 

I don't particularly want to switch to cookies, and those codes must do something, so it's likely that I'm using them wrong.

 

I have two domains. One domain that my shared hosting account is attached to, and another one that works off of a folder in my primary domain.

The htaccess is in the primary domain, and the website I'm working on is a subdomain of my secondary domain.

 

domain1.com <- htaccess is here

domain2.org = domain1.com/domain2/

mysite.domain2.org = domain1.com/domain2/mysite/

 

Does this affect how the php_value codes in the htaccess work?

 

I can give more information if necessary.

not an expert on .htaccess, however I will take more of a PHP approach..

not knowing what the restrictions set on your domains are, its hard to say if this will work.. but have you tried using ini_set to change the values of the php.ini file.. or perhaps made a custom php.ini in your root directory?

Thanks for the help. :)

 

ini_set() never really worked for me before, in regards to showing error messages, but I'll try it again.

 

I'll try the custom php.ini file now. Do I have to copy the values that are already set if I want to keep them, or would they be in the custom file already?

but it doesn't lengthen the session timeout.

 

^^^ How do you know it doesn't extend the length of the session?

 

my shared hosting account

 

^^^ Have you set the session.save_path to point to a 'private' folder that is within your account's folder tree so that your session data files will only be affected by your session settings? If you are using the default shared tmp folder, the shortest session.gc_maxlifetime value of all the accounts running on that server will 'win'.

 

Overall, why do you want to extend the session? By design it should last for the duration of ONE Browser SESSION (that's why it is called what it is.)

but it doesn't lengthen the session timeout.

 

^^^ How do you know it doesn't extend the length of the session?

 

my shared hosting account

 

^^^ Have you set the session.save_path to point to a 'private' folder that is within your account's folder tree so that your session data files will only be affected by your session settings? If you are using the default shared tmp folder, the shortest session.gc_maxlifetime value of all the accounts running on that server will 'win'.

 

Overall, why do you want to extend the session? By design it should last for the duration of ONE Browser SESSION (that's why it is called what it is.)

 

Thanks for the help.  :)

 

I know it doesn't extend the length of the session because I tried it with two of my user accounts. They both logged out at the usual time. If it worked, they would still be logged in now, even though I haven't accessed the user part of the site in hours.

 

Thanks for the advice about session.save_path.

I've set it to a folder in the same directory as tmp and public_html and now I just need to wait to see whether it works.

I had to set the folder permissions to 777 to get the sessions working. Is this safe, or could my website be hacked because of this?

Also, how do I make folders private? Could anyone access it if it's not in public_html?

 

About the sessions – my website has a writing application, and if someone gets logged out before they finish typing, they would lose their progress. :/

A month seemed to be a decent time to set the sessions for, and if a user didn't want to be logged in for a month, they could just log out whenever they're finished with the site.

 

I also have a security question about sessions:

My sessions hold the user's ID and are called PHPSESSID. They seem to be encrypted, though.

Is it possible that a hacker could install a virus or hack into someone's account using this? User IDs are only numbers, but does a way exist of decrypting the session to put something harmful in there? (I don't want to know it, just whether it exists)

 

Being so close to site release is making me paranoid about security.  :-\

I also have a security question about sessions:

My sessions hold the user's ID and are called PHPSESSID. They seem to be encrypted, though.

Is it possible that a hacker could install a virus or hack into someone's account using this? User IDs are only numbers, but does a way exist of decrypting the session to put something harmful in there? (I don't want to know it, just whether it exists)

 

Being so close to site release is making me paranoid about security.  :-\

 

The sessions are just like cookies but on the server instead of the client, holding the user id shouldn't be a issue, they are not encrypted, the only security problem you need to worry about is session hi-jacking,

 

When a session is created, a cookie is create on the clients browser, this links then together, So lets say i login and a session id of 1234 is created, and in turn a cookie is created in my browser (also 1234)

Now all is good :)

 

except lets say someone else logs in an gets a session id of 5678.. but then changes their cookie's value to 1234..

Now they will access your session and the system will think your logged in!.. this is called session hi-jacking..

 

So how do we protect against this!

well the problem is that we only compare 1 value (being the session id)

So lets make this harder, now we could also store the clients IP,

however this might be a pain for members who IP keep changing.

 

So lets use the the browsers details "HTTP_USER_AGENT" along with a random token and also get the system to change the session id for this user per login check,

 

this is just a quick draft

function create_logon($id) {
  $_SESSION['user_id'] = $id;
  $token = md5(uniqid(rand(), true));
  $_SESSION['HTTP_USER_AGENT'] = md5($_SERVER['HTTP_USER_AGENT']);
  $_SESSION['login_token'] = $token; //one for server
  setcookie('login_token', $token); //and one for the client
}

function check_logon(){
  if(isset($_SESSION['HTTP_USER_AGENT']) && isset($_SESSION['login_token']) && isset($_COOKIE['login_token'])) {
    if ($_SESSION['HTTP_USER_AGENT'] == md5($_SERVER['HTTP_USER_AGENT']) && $_SESSION['login_token'] == $_COOKIE['login_token'] ) {
      session_regenerate_id(true); //generate new ID and remove the old one
      return true;
    }
  }
  return false;
}

 

So now if the user get the session id, the will also need a cookie with the same token and also need the same browser details!,

and of course if the user is active these will change every logon check!..

 

hope that helps

It won't let me modify my post, so I hope it's okay if I make a new one.

 

Now, my account doesn't seem to log in. The user_id session is set, but it doesn't recognise that the check_logon() function is true.

Do I need to change anything else in htaccess? This is what I have so far:

(I tried / for session.cookie_path, but that didn't work)

 

Directive Local Value Master Value

session.cookie_domain no value no value

session.cookie_lifetime 2592000 0

session.cookie_path /home/[name]/session /

session.gc_maxlifetime 2592000 1440

session.save_path /home/[name]/session /tmp

 

Sorry for all these questions, I've never worked with this before (security that isn't filters, htaccess and cookies).

Does your login have all the same steps as the create_logon function?

 

if their is a problem is probably a header sent before the cookie,

try this one (that doesn't check the cookies

 

function check_logon(){
  if( isset($_SESSION['HTTP_USER_AGENT']) ) {
    if ($_SESSION['HTTP_USER_AGENT'] == md5($_SERVER['HTTP_USER_AGENT']) ) {
      session_regenerate_id(true); //generate new ID and remove the old one
      return true;
    }
  }
  return false;
}

 

of course your still need this line in your login function

$_SESSION['HTTP_USER_AGENT'] = md5($_SERVER['HTTP_USER_AGENT']);

 

EDIT:

don't worry about asking questions.. (its kinda the reason for this forum ;))

 

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.