Jump to content

Session storage and lifetime


Doc
 Share

Recommended Posts

Hi guys,

I'm trying to setup my first login form. Once connected the user will able to access the other part of the website.

I've read many topics about session from which I've learned a lot but I still can't figure if sessions are files based, database based or cookie based ?

I've read somewhere Ryan said he will add a database option, is it live ?

Perhaps a cookie is only set if a user is logged in ?

In the doc http://processwire.com/blog/posts/multi-instance-pw3/#more-session-control, it says :

"Session variables are currently stored with PHP's session functions with files in /site/assets/sessions/."

In that same doc, someone asks in the comments section how to get rid of sessions, he don't use them and don't want any cookies (perhaps regarding EU cookie law...).

(I've also read many threads where people had too much files in their sessions directories, apparently ubuntu related or Php garbage collector setting).

So does PW sessions set a cookie or not ?

Does someone here know what's the default lifetime of a PW session ?

Thanks !

 

 

Link to comment
Share on other sites

Default session lifetime is 86400 seconds. You can change this to any value you want.

// config.php
$config->sessionExpireSeconds = 86400;

Allow/ disallow sessions (and the wire cookie) under conditions. Remind that you need this to have access to the backend admin.

// config.php
$config->sessionAllow = true;

If you want to disable cookies only for the frontend

/**
 * config.php
 * if we would use cookies only for the admin area
 *
 */
$config->sessionAllow = function($session) {
    // if URL is an admin URL, allow session
    if(strpos($_SERVER['REQUEST_URI'], $session->config->urls->admin) === 0) return true;
    // if there is a session cookie, a session is likely already in use so keep it going
    if($session->hasCookie()) return true;    
    // otherwise disallow session
    return false;
};


If you want to use cookies respecting EU Cookie law I recommend Cans Module MarkupCookieConsent in combination with this settings.

/**
 * config.php
 * if we would use cookies only for the admin area
 *
 */
$config->sessionAllow = function($session) {
    // if URL is an admin URL, allow session
    if(strpos($_SERVER['REQUEST_URI'], $session->config->urls->admin) === 0) return true;
    // if there is a session cookie, a session is likely already in use so keep it going
    if($session->hasCookie()) return true;    
    // user accepted cookies due to EU law (Module MarkupCookieConsent)
    if(!empty($_COOKIE['eu-cookie'])) return true;
    // otherwise disallow session
    return false;
};

Use the core module SessionHandlerDB to store session vars in the database.

Learn more about session setting options and sessions by reading the comments in the files /wire/config.php or /wire/core/Session.php of your processwire installation.

 

  • Like 10
Link to comment
Share on other sites

  • 1 year later...

Hi guys,

On some instances of ProcessWire I'm finding that the cookies only for admin area or even 

$config->sessionAllow

Is not disabling the wire cookie on the front end. Does anyone know why this would be? I've tried switching to DB sessions too.

 

Thanks

Link to comment
Share on other sites

On 5/18/2018 at 12:33 PM, alexmercenary said:

On some instances of ProcessWire I'm finding that the cookies only for admin area or even 


$config->sessionAllow

Is not disabling the wire cookie on the front end. Does anyone know why this would be? I've tried switching to DB sessions too.

 

I can confirm this for version 3.0.98. It does something. If set to false, I cannot use the backend.

But at the frontend the cookies are still set.

I was wrong. It works nicely. The cookie I saw was not set by Processwire. Sorry.

Edited by Susticle
Link to comment
Share on other sites

Hmm well I'm slightly baffled... If I set it to false it does indeed disable login however a wire cookie and wire_challenge cookie are still set on the backend and on the frontend there is still a wire cookie being set?

Link to comment
Share on other sites

@alexmercenary, when I test it using the function proposed in the blog post that introduced $config->sessionAllow...

$config->sessionAllow = function($session) {

    // if there is a session cookie, chances are user is logged in
    if($session->hasCookie()) {
        return true;
    }

    // if requested URL is an admin URL, allow session
    if(strpos($_SERVER['REQUEST_URI'], '/processwire/') === 0) {
        return true;
    }

    // otherwise disallow session
    return false;
};

...then it works as advertised. That is, when I am not logged into the back-end there is no cookie set.

2018-05-23_203016.png.e740d698cfb92e8b4ba22b5b7b728ed3.png

Are you deleting any old cookies before you check for the cookie when not logged in?

Link to comment
Share on other sites

@Robin S @Susticle Apologies for my slow response.

It's very peculiar. I've just used a cookie checker as you did and it says that it isn't setting them however when I check in web inspector for this particular site and another, it still shows the cookies if I delete them and refresh, as if it has set a new one.

checked in Chrome and Firefox in private windows too.

Very bizarre.

Link to comment
Share on other sites

Ok, I found out what was going on and it's me being silly, nonetheless, hopefully this will help someone.

I use FormBuilder for some forms and by default CSRF is enabled for obvious reasons, but this relies on sessions to validate the form submissions and this adds info to the wire/s cookie.

If you need to disable cookies then make sure to check this on the form settings and then I would suggest enabling this if people accept the cookie policy.

Link to comment
Share on other sites

7 hours ago, alexmercenary said:

I would suggest enabling this if people accept the cookie policy.

Just so people don't prematurely jump to disabling useful security features: Having cookies enabled to allow for session storage or csrf protection can be justified as "legitimate interest" (Art. 6 GDPR), which means you no longer need explicit consent. You'll probably still need to document that justification in the privacy policy, though.

  • Like 2
Link to comment
Share on other sites

11 hours ago, LostKobrakai said:

Just so people don't prematurely jump to disabling useful security features

Yeah, totally agree, I don't think people should jump straight to this, it was more a suggestion for a circumstance where a client would like all cookies unset initially, allowing people to enable them.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By theoretic
      Hi guys and ladies! And thanks for Processwire!
      It appears i've got an interesting issue concerning the template-settings-based PW redirects dealing with access control. Any PW template has some access control options i.e. "Login redirect URL or page ID to render". If this option is used for a page having a template with this option filled, a redirect will occur if user is not logged in and/or has insufficient access rights.
      I like to hook PW events. In one of my current projects i decided to write an addHookBefore('Session::redirect', ...) which should store the page we are being redirected from. With "regular" redirects like $session->redirect('/somewhere/') this hook works like a charm. But it was strange to see that it doesn't work with the template-settings-based redirect.
      I'm too dumb to dive deep inside PW and to examine the whole PW session mechanism. But it could be rather logical if ANY redirect ( no matter template-settings-based or using $session->redirect() ) could be hooked in the same manner.
      Okay okay i can forget about template-settings-based redirect and write my own. Just a couple of lines of code, and it works. But it's less elegant than hooking the template-settings-based redirects.
      So am i missing something? It this behavior a bug, or is it intended by PW team? Thanks in advance for any comment!
    • By fliwire
      Hi, after redirect to payment page processwire session lost because of samesite cookies changed default to "lax".

      https://web.dev/samesite-cookies-explained/

      tried to hook session::init but not works ?
      $wire->addHookBefore("Session::init", function (HookEvent $event) { ini_set('session.cookie_samesite', 'None'); session_set_cookie_params(['samesite' => 'None']); });

      set by htaccess works
       
      <ifmodule mod_headers.c> Header always edit Set-Cookie ^(.*)$ $1;SameSite=None;Secure </ifmodule>  
    • By derelektrischemoench
      Hi guys,
      I'm facing a somewhat strange issue here which I can't quite wrap my head around. 
      I have a PW site in development which runs on three machines simultaneously, one staging server which is accessible as a preview instance for my customer, my PC and my laptop. 
      I have three completely identical settings on each of the three machines (same apache version, same php version, same codebase, same database); however on my PC I am unable to log into the backend. I get no error message or anything, when I try to login; i just get redirected to the login  page. I have already enabled database driven sessions (I enabled them on my laptop, then I dumped the database and copied it to my pc); I have cleared the cache directory; I cleared the sessions in the database; I cleared my browser caches, I tried different browsers, all to no avail; I am unable to login when using my pc, the instances all have the same .htaccess.
      Is there something I'm missing here or does anyone have a clue as to what my issue here might be? I'm using processwire 3.0.123
      Thanks for any input, greetings
      derelektrischemoench
       
      //edit: I've noticed something interesting; despite the directories of my web folders being the same layout; when I open the admin page i get a 404 on the processwire/ resource in the networks panel of chrome; on my laptop I get a  200.... I guess this is where my problem is; but why?
       
       
    • By derelektrischemoench
      Hi guys,
      I'm facing a somewhat strange issue here which I can't quite wrap my head around. 
      I have a PW site in development which runs on three machines simultaneously, one staging server which is accessible as a preview instance for my customer, my PC and my laptop. 
      I have three completely identical settings on each of the three machines (same apache version, same php version, same codebase, same database); however on my PC I am unable to log into the backend. I get no error message or anything, when I try to login; i just get redirected to the login  page. I have already enabled database driven sessions (I enabled them on my laptop, then I dumped the database and copied it to my pc); I have cleared the cache directory; I cleared the sessions in the database; I cleared my browser caches, I tried different browsers, all to no avail; I am unable to login when using my pc, the instances all have the same .htaccess.
      Is there something I'm missing here or does anyone have a clue as to what my issue here might be? I'm using processwire 3.0.123
      Thanks for any input, greetings
      derelektrischemoench
       
       
    • By Peter Knight
      How do you guys handle large session tables when sessions are being recorded to the database?
      I notice one of my sites has a session table of over 14MB 
      Am I missing a way in the Admin or a module to auto-remove any sessions older than X days?
      Thanks
       
×
×
  • Create New...