I just uploaded a project from my local machine via FTP and it seems that the live server is working differently after trying to log in.
On the live server it's not authenticating. It gets to the __construct on AuthController.php but goes right back without errors (again, on local it works fine).
I tried adding this in Authcontroller.php:
public function postLogin(Request $request){
die();
}
And it didn't even reach it on server (it did on local).
I tried playing with the routes and instead of this:
Route::controllers([
'auth' => 'Auth\AuthController',
'password' => 'Auth\PasswordController',
]);
I did this:
Route::post('auth/login','Auth\AuthController#postLogin');
Route::get('auth/login','Auth\AuthController#getLogin');
Didn't help on the server (local still worked fine).
I tried clearing my browser's cache, artisan cache, artisan config cache and basically anything I could find.
I tried re-uploading files from local to the server and nothing seems to work.
The most important thing here (I think) is that when I created the postLogin function it didn't even go in. That should be a huge tip if I actually knew what that meant.
The log didn't give me any errors.
Thank you #Bagus Tesa for asking to see the login file!!!
In the action of the form I added a parameter I was using for something but for some reason that's what was screwing everything up.
The important thing is that it works now...
Thanks so much!
Related
When testing my application and trying to create a new user then on form submission I am getting error 419.
If I use a helper to log in using Auth::loginUsingId(x) for an existing user then dd(auth()->user()) is successful but when I redirect to another page the user is no longer logged in. eg running the following code, you end up getting redirected to /login:
Route::get('/logInAs/{id}', function ($id) {
Auth::loginUsingId((int) $id);
dd(\auth()->user());
return redirect()->route('dashboard');
});
I would share more code but I'm not sure what would be useful at this point?
I've probably spent about seven hours trying to fix this so far. It's driving me up the wall!
The app works fine on other environments, such as staging. I've even gone so far as to re-download it from github as a fresh install (in case I was messing about in vendor directory and changed something), but that hasn't fixed it.
I get the same issue on Chrome, using different signed in users on Chrome, using incognito mode on Chrome, using Firefox, and using valet share and accessing my local version on another device, like a phone, so I don't think it is to do with browser caching.
When other devs working on the project run it locally on their machines I haven't had reports of this issue, so it seems to just me my local environment.
I've variously tried changing CACHE_DRIVER and SESSION_DRIVER in .env to no joy, but I'm beginning to lose the will to live so don't really know if I'm doing the right thing there - please help if you can!!
Edit to add more detail:
Middleware on the dashboard route:
Route::middleware(['auth:sanctum', 'verified'])->group(function(){
Route::get('/dashboard', DashboardController::class)->name('dashboard');
});
If I remove the middleware then I just get an error that user is null on dashboard.blade.php, ie the user is still not staying logged in.
A custom middleware:
class VerifyUserIsMerchant
{
public function handle(Request $request, Closure $next)
{
if ($request->user()->isMerchant()) {
return $next($request);
}
throw new AccessDeniedHttpException('You must be a merchant to access this page');
}
}
If I dd($request->user()) in this middleware it returns null.
The issue got fixed with the help of Laracasts. The full answer is here.
In short, I needed to remove the http:// protocol from SESSION_DOMAIN in .env and set it to match APP_URL.
This was the correct answer for this issue. It was deleted by a moderator. Moderator, before you delete this answer as well please can you explain why?
It provides the full answer to the issue raised in the question. I did not find this answer to this issue anywhere else (hence why it took me several days of debug to fix).
If I can know why it was deleted, I can then understand how to avoid making answers in the future that also would be deleted. Thank you.
I have Laravel set up. I am running multiple domains to it. Before yesterday I had one top level domain and a few sub domains. I added another TLD yesterday and everything started working weird. Specifically, when trying to log into the admin section it redirects to the home page. I have one admin but server domains coming to the site. My route group it:
Route::group(['prefix' => 'admin', 'middleware' => 'auth'], function() {
Sometimes is actually brings me into the admin but as soon as I click on a link I get logged out and redirected to the home page. I keep seeing 401 errors in the console as well.
What would cause this?
edit
Route::group(['prefix' => 'admin', 'middleware' => 'auth'], function() {
Route::get('/', 'AdminController#index');
Route::get('/pages', 'AdminController#pages');
Route::get('page/create', 'AdminController#createPagePage');
Route::post('createPage', 'AdminController#createPage');
Route::get('/page/edit/{page_id}', 'AdminController#editPagePage');
Route::post('editPage', 'AdminController#editPage');
});
$redirectTo = '/';
If you are using Linux, try to check the session file permissions and change them so the app can write session keys on that file and if it doesn't work, try to change the session driver to database.
how to change the session driver?
Go to your .env file and change SESSION_DRIVER=file to SESSION_DRIVER=database.
create a session migration: php artisan session:table.
composer dump-autoload.
Finally migrate (php artisan migrate).
Have you setting the SESSION_DOMAIN right?
One thing you may notice is that session isn’t saved when the user is logged-in in one store and goes to another. To fix that issue, we’ll need to add a SESSION_DOMAIN variable to our .env file, for example:
SESSION_DOMAIN=’.example.com’
That’s all, now user session will be shared across all shops/subdomains in our app.
https://medium.com/#maxkostinevich/how-to-build-multi-domain-laravel-application-e6d87d5e507b
If you are confident with the domain setup correctly. Please verify these few things.
1. Your config/session.php is correctly setup to support multiple domains.
'driver' => env('SESSION_DRIVER', 'file'), // check /storage folder writtable recursivelly.
'domain' => env('SESSION_DOMAIN', null), // verify if single domain is not given in .env or in settings.
'same_site' => null // it should not be strict if you have ajax request across these domain. I mean from javascript you may try to request to other domain.
etc...
2. Confirm, if your routes are not group under domain specific. something like:
Route::group(['domain' => 'xxx'], function($params)
{
// your routes..
});
3. If there is any hardcoded domain verification/conditions or redirection added in code.
4. Any values in .env poiting to single domain.
5. Also don't forgot to clear the cache/compiled view/routes and delete the temp files once. like generated files inside /app/bootstrap & /storage
// Clear Application Cache
php artisan cache:clear
// Clear route cache
php artisan route:cache
// Clear config cache
php artisan config:cache
// Clear compiled view files
php artisan view:clear
6. Any thirdparty package might contains the domain settings. Make sure to verify the files in your /config folder.
7. Check the url rewrite settings in .htaccess
8. Do confirm if there is any proxy settings are there or any software installed on server - very rare case.
In case still having issue, please restart the apache/nginx service once because sometimes the config changes not effected after change that might need server restart.
Hopefully it helps.
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 have a problem regarding sessions in Laravel. I try to redirect the page and at the same time sending some session variables using the with() method:
return Redirect::To('/')->with('foo','bar');
But when the page comes up, the only session variables set are _token and locale, 'foo' and 'bar' do not appear. Running {!! var_dump(Session::all()); !!} gives:
array(2) { ["_token"]=> string(40) "l5NawtJdHJtanTErsya440UvPQIgqNExiryJIkIO" ["locale"]=> string(2) "se" }
The session stored in storage/framework/sessions strangely has other variables set, such as url and PHPDEBUGBAR_STACK_DATA that don't show up when redirecting.
Now, here's the real twist: It works perfectly when run on a different computer.
We tested with the same repository, same code, a fresh installation of laravel, same web browser, same OS (Mac) and same program for running the server locally (MAMP). On another computer it works fine, and on a third computer, but not on mine.
The application is in debug mode and I have tried clearing all caches in Laravel and in the browser nothing changed.
Does anyone have a clue on how this can be resolved?
with() method use to pass data to a view. If you want to add something to session use session()->flash->('foo', 'bar');(automatically erase after next request) or session()->put('foo', 'bar');
Apparently in config/session.php the variable domain was set to the production domain. So when using localhost on my computer, the cookie laravel_session couldn't be read or written.
It worked by using:
'domain' => null,
I'm using Laravel on MAMP PRO (PHP 5.4). Both are vanilla install and I got Laravel working okay.
Next, Installed Sentry.
Inside of a login function on controller:
$user = Sentry::authenticate($credentials, false); // this works. I can see the $user
But then upon an immediate redirect I use a filter:
Route::filter('auth.admin', function()
{
var_dump(Sentry::check()); // ** this gives me a bool(false);
die();
if ( ! Sentry::check())
{
return Redirect::route('admin.login');
}
});
So, I'm assuming that maybe there is a cookie that is not being set?
Solved...
For anyone else with this issue, this is a summary of the most common solutions on the Internet as well as how I solved my issue. I'm on MAMP/OSX, but this apparently made zero difference as I literally put up a vagrant/virtualbox and still had the same issue.
** Set 'domain' => 'yourdomain.com' in your config/session.php. EVEN IF YOU ARE ON A SUB DOMAIN like a.b.c.yourdomain.com, use ONLY the root domain (yourdomain.com) in your 'domain' variable as I just wrote it. ** This was my issue.
Make sure your session storage folder has write permissions.
Make sure you have a >0 lifetime in your session.php
Make sure you don't have whitespaces after any closing PHP which could cause the application not to shut down properly.
Try Switching between database sessions and file sessions.
As a last resort, try upgrade to 4.2, if possible. 4.1 had a known issue (as referenced in google).
Your issue is may no be with Laravel OR Sentry. It's probably a file or configuration issue as illustrated above. I pulled my hair out tracking this from Sentry to Laravel to Cookies to Session to Blah... Only to realize that it was finally a cookie issue which was caused by me not setting my ROOT domain (I was using the full