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 :
the built in Authentication features of laravel are really powerful.
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:
Good luck any questions let us know :)
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.
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:
Also @laravelmaso I am assuming you are using an auth filter to check the user is logged in? Might be a caching problem...
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
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?
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]'));
. . }
Ah, yes, the wonderful world of caching.
Before going any further, I would recommend reading this article on caching:
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.
Sign in to participate in this thread!
We'd like to thank these amazing companies for supporting us