Get a cookie in Laravel 5 middleware - laravel

I'm trying to retrieve a cookie from a middleware in Laravel 5.3 but it seems like $request->cookie('language') is empty. I'm guessing that it is only set after the middleware runs.
I read somewhere that I should use \Cookie::queued('language'), but it's still empty.
Is my only option using the $_COOKIE variable?

When do you set this cookie?
Remember that cookies are stored in the browser, so the user needs to get the response in order for you to be able to retrieve the cookie later.
You should be able to get the cookie after the cookie is being set by a response that's successfully sent to the user. Remember also that if you use dd(), that doesn't let the cookie get created, because it skips all cookie headers from being sent to the user.
Another problem you might face for trying to get cookies from middleware is that it might not get decrypted automatically, so you'll have to do it yourself.
Example:
\Crypt::decrypt(Cookie::get('language'))

If someone encounters this problem in 2019 with Laravel 5.8:
You will need to use \Crypt::decryptString(Cookie::get('language')) or \Crypt::decrypt(Cookie::get('language'), false).
Otherwise it will try to unserialize the string and then strange things happen.

Related

Stateless API with JWT cookie invalidation

I have been playing for a couple of days with a stateless Laravel API with JWT based authentication, where I store the token in a cookie.
All is well, except for the cookie (in)validation...
I set my cookie like so
Cookie::queue(Cookies::NAME, $token, (int) env('COOKIE_VALIDITY'), Cookies::PATH, env('COOKIE_DOMAIN'), env('COOKIE_SECURE'), Cookies::HTTPONLY, Cookies::RAW, Cookies::SAMESITE);
$redirectUrl = $request->query('redirectTo') ?? route('home');
return redirect($redirectUrl);
This works, it does set the cookie.
However, my cookie Expires/Max-Age seems to be one hour behind, always.
2019-10-12T08:51:35.737Z (when it is actually 9:51)
The cookies gets sent correctly on all subsequent requests though.
The biggest problem however, is cookie invalidation.
My logout action looks like this
return redirect('/login')->withCookies([Cookie::forget(Cookies::NAME)]);
The action gets called to, but the cookie remains unchanged.
I also tried with the cookie()->forget() helper, this has the same result.
Any clues to what I am doing wrong here?
Ps: I do see that laravel by default adds a session cookie as well, I suppose this is normal, due to the fact that I reach the site as an anonymous user and therefor receive a session for that?
Im asking because the challange for me is to have a full stateless API that only uses server side rendered login page and then redirects back to some kind of SPA.
All help is much appreciated.
To whom it may concern, I have found the problem.
Apparently, specifying the cookie name is not sufficient.
return redirect('/login')->withCookies([Cookie::forget(Cookies::NAME, Cookies::PATH, env('COOKIE_DOMAIN'))]);
Works perfectly.

Get cookie within an Ajax API post request - Laravel 5.6

After running an API call, in my controller, I'm trying to get the cookie value like this:
Cookie::get('gtdk')
It returns a empty value, although the cookie was already set in the browser.
Do I need to pass the cookie value as a parameter in the ajax call?
EDIT
It is also happening in a WEB route call - the cookie is not there when trying to read it in the Controller
Ok, so laravel encrypts the cookie names.
As the cookie was set using Javascript in the frontend, I could not read it by using Laravel methods.
Therefore, I've used it using PHP standard:
$_COOKIE['gtdk']
Another option is adding an exception for that cookie name in the the middleware.

Sentry Cookie not attaching

I am working on Laravel 4 application and using Sentry for authentication. I need to add Keep Me Logged In functionality into my application. I have googled around and found that passing second variable to Sentry::login($user, $remember) sets up a cookie. I have done that and can verify that it is working from the browser (Chrome). But somehow whenever I try Sentry::check() after a day it returns null for cookies. Even when the cookie is present in the browser. Can anyone point out what am I doing wrong? Same happens when I attach my custom cookie to the response.
This scenario happens on my production server. Whereas it works fine on my local server.
PS: Lifetime of the cookie is set to forever (5 Years)
After working around for sometime on the issue I was finally able to resolve the issue by creating and attaching custom cookie to the response after login. And then wrote a middleware to check for that cookie. If present then login user and continue.

Why Laravel5.4 $request->cookie('key') is empty when PHP global var $_COOKIE has cookies

I am trying to read the cookies in Laravel5.4. So I get the cookies after successful validation with third party Authorization server. I am not making the cookies in laravel5.4, but I am reading the cookie value send to me from view/frontend. I can see the values of cookies in Chrome debugger environment as well as from PHP global variable $_COOKIE. They are all set correctly.
However, when I tried to read the same cookie using $request->cookie('key') from controller method... it shows nothing. I also tried Cookie facade to read the value and still nothing. This controller is handling a redirect route which is called by the third party oauth server and this server when it redirects to my URL, it also sets the cookies.
Am I not setting this redirect url route correctly in web.php file in Laravel5.4? This is how it is defined in web.php as below:
Route::get('login/okta/callback',
'Auth\LoginController#handleProviderCallback');
The request object is empty when I dumped the content but $_COOKIE has the data.
Laravel's cookie class encrypts and decrypts the values of its cookies (see the App\Http\Middleware\EncryptCookies middleware). When you have it look at a cookie it didn't set, it's going to try (and fail) to decrypt it.
If you've got a cookie set from outside Laravel, use $_COOKIE to work with it, or add the name of the cookie to the $except array in app/Http/Middleware/EncryptCookies.php so it isn't messed with.

Securing an ajax request

i have a website that uses session cookies for security. it works fine and all, but any ajax requests right now are not secure. example being lets say a user is on a page. they can only get to this page if they are logged in with a session - so far so good. but now the ajax request they ask for is
ajaxpages/somepage.php?somevar=something&anothervar=something
if any other user decides to just go to that link themselves (without a session) they still get the same ajax output that was meant for logged in people.
so obviously im going to have to pass session data across when i send an ajax request. anyone have any tips for the best way of doing this? ive never done this before and would rather use trusted methods than make up my own.
The ajax requests work just like any other request to your website and should return the same session cookies as the non-ajax request. This is pointed out in this question. If you aren't getting the session cookie, perhaps something else is wrong.
Having an ajax output isn't necessarily a vulnerability. It entirely depends on what data is being transmitted. I am not sure what platform you are using, but most web application development platforms have a session variable that can maintain state between requests.
What you should have in place is way of marking the user as being logged in from the server side. I php this would look like:
if(login($user,$password)){
$_SESSION['logged_in']=true;
}
Then you can check in a header file if they are allowed to access the page:
if(!$_SESSION['logged_in']){
header("location: http://127.0.0.1/");
die();
}
(If a variable isn't set it is also false.)
There are a few things you need to keep in mind. This is a vulnerability:
if(!$_COOKIE['logged_in']){
header("location: http://127.0.0.1/");
die();
}
The user can control $_COOKIE, so they can tell you that they are logged in.
Another vulnerability:
if(!$_COOKIE['logged_in']){
header("location: http://127.0.0.1/");
}
header() doesn't kill the script. In fact it still runs, so it will still output but it won't be displayed in a browser, you can still use netcat/telnet/wireshark to see the data.
Use the same security check on the pages that handle the ajax request.
Since that is a PHP page, I don't see why you couldn't perform authentication on the PHP side. If authentication is successful, send back the data. Otherwise, send back an error message. AJAX aren't that different from any other request.
Just let ajax carry the session cookie, there is no problem with that, but you must check if the user is logged or not at the end, and you might want to add some CSRF token for your request, just in case ...
And try to validate the referrer, so you can check if the request was sent from your website, and your website only, it's not a good practice to let user open your request url for ajax in their browser ....
And if you have query in your script, to get some data from your database or else ... don't forget to sanitize the input, and escaping the output, based on what kind of data that you need, once more just in case ...

Resources