Support the ongoing development of Laravel.io →
Security Session Database
Last updated 3 months ago.
0

To answer your first question :

You have three ways to destroy sessions

Session::flush(); // removes all session data
Session::forget('yourKeyGoesHere') // Removes a specific variable
Auth::logout() // logs out the user 

More reading here :

http://laravel.com/docs/session and http://laravel.com/docs/security#authenticating-users

the built in Authentication features of laravel are really powerful.

Last updated 3 months ago.
0

Now to answer your second question :

you need to make a table first in your database like so :

php artisan session:table

composer dump-autoload

php artisan migrate

Then going to your

/app/config/session.php file you change the driver to

'driver' => 'database',

your table name should also match the table name you created in the migration above^^^^^

'table' => 'sessions',

More reading to be done here:

http://laravel.com/docs/session

Good luck any questions let us know :)

Last updated 3 months ago.
0

Many thanks @RixhersAjazi,

The I can now work with sessions table, its perfect. I have tested all three ways to destroy sessions especially for logged in users, somehow they are working, and because I use Auth methods, the Auth::logout() is more preferable.

However, sessions are destroyed exept one problem, when a user clicks browser "Back" button, they can see all pages previously visited, but when they click any link that makes an application refresh, is when they are given the login page.

I guess I have some other problem different from session destroy.

Last updated 3 months ago.
0

Probably worth mentioning, when a user is logged in, a login token is generated and stored in the sessions, Laravel uses this token to know what user etc. When you use Auth::logout() you are only removing that token. So if you set any additional user variables in sessions they wont be removed.

So to be clear, the best way to log a user out I would say is:

Auth::logout();
Session::flush();

Also @laravelmaso I am assuming you are using an auth filter to check the user is logged in? Might be a caching problem...

Last updated 3 months ago.
0

Your browser cache is the cause for that one. I'm currently on my phone so when I get to my work bench I can give you some php header information for a quick and dirty fix. However, I have never experienced this with laravel. Make sure your Auth filter is correct. You shouldn't be able to see the the protected even if cache is there(I think) 95% sure of this.

Also as cgoosey1 stated you should log your users out like so:

Auth::logout()
Session::flush()
//then redirect to a certain route that holds your main page 
Last updated 3 months ago.
0

Again just to reiterate you should not have to include the following below:

header('Last-Modified: ' . gmdate("D, d M Y H:i:s") . ' GMT');
header('Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0');
header('Pragma: no-cache');
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");

it is a dirty work around in my opinion. I have never had the experience you are describing with a protected route.

Could you show your filter and route to us please?

Last updated 3 months ago.
0

Thanks both of you guys, I have tried both solutions but still having same problem. My routes are filtered like so; I have not included those headers.

Route::group(array('before' => 'auth'), function() { Route::get('logout', array('as'=>'logout','uses' => '[email protected]')); Route::get('/','[email protected]');
Route::get('users','[email protected]');
. . }

Last updated 3 months ago.
0

Ah, yes, the wonderful world of caching.

Before going any further, I would recommend reading this article on caching:

http://www.mnot.net/cache_docs/

It covers much more ground than your specific problem with the browser, but it is all essential information that every web developer should know. The executive summary is that unless you are using SSL, browsers tend to cache as much as they can and it is really hard to stop them.

I have had some luck avoiding the problem on a site that doesn't use SSL by setting certain parameters in the response. The Laravel way to do this is:

    $response = Response::make( $view, 200 );
    $response->header( 'cache-control', 'no-store,no-cache,must-revalidate' );
    $response->header( 'pragma', 'no-cache' );
    $response->header( 'expires', '0' );
    return $response;

There are numerous answers on Stack Overflow about which combinations of headers work reliably on which browsers. YMMV.

Last updated 3 months ago.
0

Sign in to participate in this thread!

LoadForge

Your banner here too?

Moderators

We'd like to thank these amazing companies for supporting us

Your logo here?

The Laravel portal for problem solving, knowledge sharing and community building.

© 2022 Laravel.io - All rights reserved.