guys,
I'm having this issue to create my firsts tests on my project. I already try almost everything, search in forums, but I can't resolve this problem. Every page that I try to access using get in my test is always returning 404.
public function testExample()
{
$user = factory(User::class)->make();
$this->actingAs($user)->get('/book-original');
$this->assertResponseOk();
}
There was 1 failure:
1) FileTest::testExample Expected status code 200, got 404.
I'm using a separeted .env.testing file, but try to setup my .env file same as the testing, in case the Laravel is ignoring the testing and reading the main one, but the result is the same.
I try to use the $baseUrl and .env's APP_URL with http://localhost and my IP and try to use the return value from php artisan serve command, in my case, http://localhost:8000, but in both cases the error persists.
Important: I used php artisan config:cache every time I changed the configs.
I'm already lost. Has someone a hint to help here?
Thanks so much.
Related
I'm working full time on an application for 2 years. I encounter this bug regularily, let's say every couple months, but never manage to fix it in a reliable way because it just disappears and I never get to find the "why".
So, here it is again, and I have no clue why and how to fix it. This time, I'm writing something so I'll have a page to favorite for the next time.
Here is the bug:
If I make any change to a policy method, for instance in app/Policies/UserPolicy, the change is not taken into account when using #can in a blade or $user->can in a php file. I can introduce a die in the policy, a Log::debug('something') or even a return false at the very start of the function, but nope, still returning true.
Here is a code sample:
File : app/Policies/UserPolicy
public function deleteUser(User $user, User $target)
{
return false;
if ($user->id === $target->id) {
return false;
}
// [...]
}
Here is the code testing, it returns true, whatever I do in the policy code:
$me = Auth::user();
dd($me->can('deleteUser', $me));
Originally this example should return false, but it's returning true and I don't know why. Modifying the code does not change a thing, it's like there is a cache that nothing can clear. I've tried all the cache clearing commands I know:
php artisan cache:clear
php artisan config:clear
php artisan view:clear
php artisan clear-compiled
composer dump-autoload
Even restarted apache, and so on... I checked php.ini, I don't have OPCache enabled (line commented, but I tried with OPcache.enabled=0 too, no changes).
Maybe the reason is elsewhere but I don't know where to look. As I said, this bug usually disappear by itself without leaving me the time to find the cause.
Other way to reproduce the bug
In a blade, if I write:
#can('deleteUser', $user)
CAN
#endcan
It always display CAN. If I rename the function in the policy file to deleteUserr for instance, nothing changes (still returns true). However, if I change the blade code to #can('deleteUserr', $user) then I don't have the "CAN" displayed, as this function is not found and the result for unfound rule is alwways false.
Environment
WSL (Ubuntu 18.04, apache 2.4.29, php 7.2.19), Laravel 6.0.3
Thanks for any help !
EDIT / SOLVED : found the culprit !
It is a bad interaction with the composer package spatie/laravel-permission.
I have a spatie permission that is name "deleteUser" and is granted. The package has probably overloaded the "->can" method and now checks first in its permissions mechanism before going on the policy route. So my UserPolicy#deleteUser is simply ignored.
Here is the reason I found:
It is a bad interaction with the composer package spatie/laravel-permission.
I have a spatie permission that is name "deleteUser" and is granted. The package has probably overloaded the "->can" method and now checks first in its permissions mechanism before going on the policy route.
As the permission "deleteUser" is granted, the UserPolicy#deleteUser is simply ignored.
I Want to run my application in localhost with php artisan serve but I get this Error unserialize(): Error at offset 0 of 40 bytes where is my problem?
You have to set a news Key Generate because
php artisan key:generate
After that test again to run the Laravel Application
php artisan serve
I got the same error, when I upgrade a Laravel 5.5 app to 5.6. The error comes form the EncryptCookies-Middleware.
Delete the cookies in your browser and/or clear your session-files in your Laravel app.
I've faced same problem. I frequently faced this problem in Homestead-vagrant environment.
To solve this issue in Laravel 5.4,5.5,5.6 or more -
php artisan config:clear
php artisan view:clear
php artisan key:generate
I got the same error a couple of days ago when I pushed a production update to my Laravel project from Envoyer.
Immediate fix:
I tried to rollback to the previous commit but the issue persisted which means the issue was originating from the client side, cookies probably. I tried removing cookies and the issue was gone.
Later, I spent a lot of time looking for this issue but got nothing until I faced this issue again today with another deployment and i found this article on Laravel news about the security fix 5.6.30 update. I was able to identify that this issue occurs if i try to deploy previous (< 5.6.30) version of the laravel v5.6.26 for a project which was already using > v5.6.30 and cookies were already created ( not serliazed) which when <5.6.30 version of the framework tries to unserlize results in error because they're not properly serealized.
Installing laravel/framework (v5.6.26)
Loading from cache
From the upgrade guide:
Configuring Cookie Serialization Since this vulnerability is not able
to be exploited without access to your application's encryption key,
we have chosen to provide a way to re-enable encrypted cookie
serialization while you make your application compatible with these
changes. To enable / disable cookie serialization, you may change the
static serialize property of the App\Http\Middleware\EncryptCookies
middleware:
I was able to fix this issue permanently by clearing cache of composer so forcing it to load latest version of the framework instead of falling back to cache.
Hope this helps.
Bests,
Just Inspect the element in Browser, and go to application tab and select cookie and delete that all cookie. That's It.
In App\Exceptions\Handler under render function use this snippet, it will reset browser cookie.
if (str_contains($exception->getMessage(), 'unserialize')) {
$cookie1 = \Cookie::forget('laravel_session');
$cookie2 = \Cookie::forget('XSRF-TOKEN');
return redirect()->to('/')
->withCookie($cookie1)
->withCookie($cookie2);
}
In my case I did removed my composer.lock and did a composer install and voila...
$ cd project_root
$ rm composer.lock
$ composer install
I also encountered this issue when I happened to update my composer.
If you put
protected static $serialize = true;
inside App\Http\Middleware\EncryptCookies, the old cookie will break your system. So to prevent this, either you have to clear the cookie, or just don't unserialize the decrypted cookie.
I made a workaround for this:
Inside vendor/laravel/framework/src/Illuminate/Encryption/Encrypter.php
Above this line of decrypt() function:
return $unserialize ? unserialize($decrypted) : $decrypted;
add:
try {
return $unserialize ? unserialize($decrypted) : $decrypted;
} catch (\Exception $e){
return $decrypted;
}
This might be ugly, but you can temporarily put it there until you think the old cookies has gone.
In my case, I was trying to decrypt a hash with an wrong function.
I was creating encrypt using encryptString()
$hash = Crypt::encryptString('secret');
but I tried to decrypt using decrypt()
$value = Crypt::decrypt($hash);
the correct way is
$value = Crypt::decryptString($hash);
So when you encrypt using Crypt::encrypt() you must decrypt it using Crypt::decrypt(), and for Crypt::encryptString() use Crypt::decryptString()
The first thing you should do is clear the configuration cache file
php artisan config:clear
Then create a new key for the application
php artisan key:generate
Finally, restart the server.. I hope it will fix your problem.
In my case happened during local development.
The steps that caused the problem was:
I upgraded the laravel up to 5.8 on a seperate branch.
I switched into an another branch having laravel 5.2 (in my case I had to review a PR)
I also was logged in in my app and hence there was a session cookie as well. In that case I just cleared the browser's cookies and got fresh ones.
In firefox can be done via visiting then select about:preferences#privacy and select the appropriate option. as the following images show (in Greek)
Privacy setting and an indication where the user to click
An anothwer aproach to diagnose the issue it to open a private firefox window or use chrome's cognito mode.
yeah, for localhost you can just delete cookies, but for production put this in your error handler so users would not see whoops :
if (strpos($exception->getMessage(), 'unserialize(): Error at offset 0 of 40 bytes') === 0) {
unset($_COOKIE['laravel_session']);
unset($_COOKIE['XSRF-TOKEN']);
setcookie('laravel_session', null, -1, '/');
setcookie('XSRF-TOKEN', null, -1, '/');
abort(200, '', ['Location' => route('frontend.home')]);
}
PS. tested for laravel 5.6.
you will just run in terminal
composer global update
I'm building a web app in my local system (Ubuntu-14.04 64Bit) using laravel 5.3. I used Socialite to signin from social networks. I configured G+, Facebook, GitHug. I'm using Chromium as my default browser. Finally the problem is i'm getting
InvalidStateException in AbstractProvider.php line 200
frequently. i tried
php artisan cache:clear
php artisan config:clear
composer dump-autoload
these are helping to solve the issue temporarily, again the problem raising.
please help me in this issue..
I have the same issue and I've read a lot about this, that depend if the URL where you are at the moment of the login request has www. at the beginning or not.
Into config\services.php, if you have the redirect set as http://sitename.tld/callback/facebook the oauth works if you send the login request from sitename.tld, while if you try from www.sitename.tld you get the exception.
I haven't yet understood how to have it working with and without www at the beginning.
If the AbstractProvider.php line 200 fires the exception when the state of the user is not present means that the User cannot be created.
First check your code when you get the details from the provider(facebook, github) if you create a user and you return it.
If you have managed and logged in your app and you deleted the user from the user table remember to delete also the data from the socialite account table.
I was getting that exception because 'state' wasn't saved in session. But I was using asPopup method - Socialite::driver('facebook')->asPopup()->redirect(); so I saved session then - $request->session()->save();. So I solved this issue.
or try
session()->put('state', $request->input('state'));
$user = Socialite::driver('facebook')->user();
it works
I have same issue and solved in 3 steps;
add request on the top
use Illuminate\Http\Request;
Pass request object to function
public function handleProviderCallback(Request $request)
{
try {
$user = Socialite::driver('facebook')->user();
} catch (Exception $e) {
throw new Exception;
}
}
Clear cache.
php artisan cache:clear
I had the same error but my solution was a little different. I am posting here just in case someone else keeps hitting this post like I did for a possible answer.
I develop on Ubuntu 18.04 desktop since it is a server with a GUI. Socialite works great locally but as soon as I pushed/pulled the changes through git to the server, it quit.
I was running traces by recording what was sent to and from google. I "dd($_GET)" to get a raw dump before Socialite had a chance to get the info so I knew what was stored and ready for use. All info was there but Socialite didn't seem to "see" it. That is when I reasoned it was my apache2 header configuration interfering with the cookies/session data.
I had set header security in my apache2 configs. One of the settings was
Header always edit Set-Cookie ^(.*) "$1;HttpOnly;Secure;SameSite=Strict"
This setting was interfering with the cookie information that socialite needed. I removed that setting from my apache2 header config(by commenting out) and restarted Apache. Finally I removed all sessions in storage/framework/session/* and cleared them from my browser just to be sure. That worked for me.
After I got it working, one by one enabled and tested each of the following settings to have the framework secure what header info it can:
SESSION_SECURE_COOKIE=true
in my .env file
'http_only' => true, and
'same_site' => 'lax'(setting to "strict" did not seem to work)
in my config/session.php file.
Now it is back to testing security and tweaking things back if need be.
I am using Laravel 5.0 and been developing on this project for months without any problems. I just added a new route with a new method in the controller. But whatever I do, all these new entries in the routes.php file show me a blank page.
In my routes.php:
Route::get('dashboard/product_categories/testing', 'ProductCategoriesController#testing');
In the ProductCategoriesController.php:
public function testing() {
die('Hello world!');
}
This happens to all new entries in the routes.php. No matter what controller its pointed to.
I do not use route:cache so am clueless where this problem stems from
Please note: This is an unchanged project. The httpd server is running as it should and the storage folders have read/write permissions
If you have a resource controller for the dashboard try to add the new routes before the resource.
I totally forgot about this question, but I found the solution: php artisan route:clear
For me, none of the answers helped.
My problem was with two routes matching each other.
A sample of my web.php file is below:
Route::get('user/{user}', 'UserController#show');
Route::get('user/restore, 'UserController#restore');
It took me a while to realise what was happening here.
Despite the fact that $user was typecast in my controller to an instance of User; I just assumed that the string restore would not match that route.
In the end, I realised that the string restore was being passed as a parameter to the route above and was, therefore, failing to match a User model.
To solve this I had to change the route to the following:
Route::get('user/{user}', 'UserController#show')->where('user', '\d+');
Route::get('user/restore, 'UserController#restore');
Now only numbers are matched to that route and the restore route works as expected.
The other solution would be to change the order but I didn't want to do that.
Try clearing the cache:
php artisan cache:clear
Try deleting this before public function methods :
#return \Illuminate\Http\Response
Is there any possibility to turn on and turn off Laravel 5 maintenance without php artisan up and down commands when my website is being hosted ?
What I've done:
Route::get('site/shutdown', function(){
return Artisan::call('down');
});
Route::get('site/live', function(){
return Artisan::call('up');
});
The first route is working fine. But when I call site/live the site still is shuted down. What can cause this problem ?
If your project is already down, you cannot call another function.
What happens after you run php artisan down is that it creates a file named down inside storage/framework. After running php artisan up the file is removed.
You can create the file manually inside storage/framework. It will down your project. When you want to take your project live again, just remove the file.
I think the right answer is missing here..
You could add your route to app/http/middleware/CheckForMaintenanceMode.php
protected $except = [
//here
];
So It never would be off.
when you run artisan down. site is not available so when try to call up, your IP can't access site.
you must call down with your IP exception.
php artisan down --allow=127.0.0.1 --allow=192.168.0.0/16
or add ::1 to local.
to make that in route without command
try to save this command in specific one and call it.
Laravel 8 introduced secret in maintenance mode, in which you can bypass the maintenance mode by providing a secret, then your Artisan::call would work.
You could add your routes to the $except var in CheckForMaintenanceMode middleware to bypass the check. Then your site/live route would work just fine.
In order to make your site live again using an url, you can create a live.php file which you put in laravel's public folder and then visit http://your.domain/live.php .
In the live.php file you need something like this: (check your projects directory structure if you don't use the default public folder!)
<?php
unlink(dirname(__FILE__) . "/../storage/framework/down");
header("Location: your.domain");
die;
just put
Artisan::call('up');
without route function.