Session storage and lifetime

[Doc]

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 !

 

 

[kixe]

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.

 

[Doc]

Crystal clear @kixe, thanks !

[alexm]

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

[LostKobrakai]

sessionAllow is a recent addition. Are you sure those instances run on a version needed for the setting to work?

[alexm]

@LostKobrakai

I'm using PW version 3.0.103.

[Susticle]

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 May 23, 2018 by Susticle

[alexm]

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?

[Robin S]

@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.

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

[Susticle]

I was wrong in my previous post, sorry.

The cookie I saw was not set by Processwire. So the code found in this post works for me.

[alexm]

@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.

[alexm]

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.

[LostKobrakai]

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.

[alexm]

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.

[tires]

On 6/5/2018 at 9:05 PM, LostKobrakai said:

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.

Is the frontend cookie really useful for security?
I recently spoke with a German "Datenschutzbeauftragten" (data protection officer) and he criticized this session cookie as not being GDPR-compliant.
 

It would actually be great if you could simply disable the frontend cookie in config.php using a $config-> variable!

Edited Friday at 03:37 PM by tires

[Tiberium]

42 minutes ago, tires said:

Is the frontend cookie really useful for security?
I recently spoke with a German "Datenschutzbeauftragten" (data protection officer) and he criticized this session cookie as not being GDPR-compliant.
 

It would actually be great if you could simply disable the frontend cookie in config.php using a $config-> variable!

Maybe I'm very direct here, also, german. But what they say is nonsense. A session cookie doesn't save any personal data, only the session token. And they are legitimize reason to use it -- it is not "tracking" in the sense that gets processed after the use-case itself. 

It is one of the least things you can also use without consent before, meaning with only that, you can still serve the "Habe ich verstanden" Cookie-Banner from "the old days", with the link to your "Datenschutzerklärung" and a description that it is used and why.

What you can't do is, to use the session ccokie and don't have a Cookie-Banner at all. The user has to be notified that it is used. 

So LostKobrakai is here total correct. And it is a security feature, for forms and anything you want to be sure not be "hi-jacket". If you only have a static site without even a contact form and nothing a user can "send" something to you, then I would make maybe the work to deactivate it, so I can leave the Cookie-Banner out. But that are very rare occasions, because most customers want something, where a Cookie-Banner is needed anyway. Then it makes no difference.

The code as Robin S. shows are fine for that special cases. I don't know if the $config variable would be really necessary, but it wouldn't hurt ^^. But please not because it is GDPR conses necessary.