Always a session cookie? #726

Closed
Musiksammler opened this Issue Mar 27, 2013 · 19 comments

Projects

None yet
@Musiksammler

Hello!

I'm working on a relaunch of my site with laravel4 as the basis. Everything is okay but one thing bothers me. Even if I'm not doing anything on the site except for surfing around there is always the laravel session cookie set.

As I'm planning to use varnish in front of my application this session cookie will break all caching in varnish. I could erase it in the request in varnish before sending it to the backend but then I won't have a session cookie when I really need it. For example when a user logs in.

So, is it somehow possible that this session cookie is not set unless it's really needed? Or would it break certain functionality if this cookie is not there?

Greetings
Carsten

@taylorotwell
Member

If you don't need session cookies, use the array session driver.

@Musiksammler

No, that wouldn't work. I need sessions (and so the cookie) but only at a certain point. For example if a user logs in. For normal guest visitors I don't need a session or the cookie.

I don't think that I can change the session driver during runtime?

@roberto-butti

I have the same situation. I'm loooking if there is a way to "start_session" when i really need.

@bmtKIA6
bmtKIA6 commented Sep 26, 2013

+1

Some HTTP caching servers completely ignore pages with "Set-Cookie" headers.

@aykutfarsak
Contributor

+1

There must be a option about that: "start session only if it needs"

@jtolj
jtolj commented Dec 15, 2013

You can do what Taylor suggests as a route filter. Just apply it to the routes or route groups where you don't want a session cookie created.

Example:

Route::filter('nocookie', function(){
    Config::set('session.driver', 'array');
});
@lucasRolff

@jtolj This won't work, since if you already have the cookie, it seems like setting a different session driver, doesn't really fix the problem for reverse proxies. I know it executes the filter (I added some very basic logging to the filter).

So there needs to be found another solution for this, for laravel to properly work with varnish or any other reverse proxy.

@jtolj
jtolj commented Mar 19, 2014

@lucasRolff This solution is working fine for me using nginx as a caching proxy. There is no Set-Cookie header in server responses for routes that use that filter.

I'm not that familiar with Varnish, but it looks like by default it does not cache if the client sends a cookie header.

I don't think that can be resolved by Laravel - once a cookie is set on a domain for a user, the client will always send it back. It does look like you can configure Varnish to ignore cookies for certain urls/conditions: https://www.varnish-cache.org/docs/3.0/tutorial/cookies.html

@serphacker

This doesn't works with cookie session driver because cookie session create two cookies : laravel_session and random_name (which probably contains the session data).

If I set session.driver => array in my filter it will only remove the laravel_session cookie, not the random one, hence, the caching doesn't works.

Moreover, setting session.driver => array will just prevent to send the laravel_session cookie, but the session will be created on the server (filesystem, database, ... depending of your original session).

So it sounds more like a hack, we need a way to be able to disable sessions by default and activate them only if the client reach a certain route (/authentication) or if the client sends a session cookie with a valid session.

This will make easier integration of laravel with http caching.

@serphacker

I found a way to disable the session before their initialization, I added the following ServiceProvider :

<?php namespace Rejector;

use Illuminate\Support\ServiceProvider;

class SessionRejectorServiceProvider extends ServiceProvider {


    public function register()
    {
        $this->app->bind('session.reject',function(){

            return function($req){

                if( preg_match('|^public/[0-9]+.html|',$req->path()) ){
                    // will override session.driver to array BEFORE session initialization and before any filter
                    return true; 
                }

                return false;
            };
        });        
    }


}
?>

This way the "random" cookie containing the session data won't be added (and the others sessions files won't be created neither if you use file/database/memecache drivers)

@mhayes14
Contributor

It would be fantastic if we could have a real solution to this built into L5. :-)

@taylorotwell
Member

The best solution is to override the Session\Writer middleware with your own.

@Xethron
Contributor
Xethron commented Nov 2, 2014

Also have this problem.

We have cellphone apps that aren't cookie aware, and end up with roughly 18000 unused sessions, making garbage collection a tedious and long task.

Yes, I know, there are many solutions to solve this, but for a small website which normally only has about 100 active sessions, it seems like an overkill to install reddis just because 99.5% of all sessions are unused.

@jcbedier
jcbedier commented Nov 4, 2014

Hello,

Is there any news about this issue ?

This is against all hight traffic websites.

Regards,

@brycelarge

Yes, please can we have a fix for this in a new release of Laravel. Sessions should only be created once needed.

@Xethron
Contributor
Xethron commented Nov 18, 2014

Any news on this? We've gone up to over 50,000 sessions, with roughly 100-500 being "real" logged in sessions.

@mreschke
Contributor

Trying to force the session to array at run-time for non-logged in user doesn't work either, Config::set('session.driver', 'array)...still creates a new session file with every click, would be nice to override at runtime

@taylorotwell
Member

It's also easy to accomplish this in L5 by overriding the middleware.

On Friday, November 21, 2014, Matthew Reschke notifications@github.com
wrote:

This is the solution
http://stackoverflow.com/questions/26473106/prevent-sessions-for-routes-in-laravel-custom-on-demand-session-handling


Reply to this email directly or view it on GitHub
#726 (comment).

@GrahamCampbell GrahamCampbell locked and limited conversation to collaborators Nov 22, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.