I haven't seen this kind of strange situation. When Auth login does not work, I delete all cookies on Chrome, and I log in successfully. Laravel auth makes me crazy. Sometimes log-in works well, sometimes it doesn't.
It's not "Chrome Cookies", it's Laravel Cookies that can cause problem. There can be multiple reasons and you need to debug your code to find the root cause but most common is a faulty AuthRedirectMiddleware.This middleware is supposed to redirect users to a /dashboard or /home page by default if they are already logged in based on either the session or the cookies.
So once you login and didn't logout properly and try to re login, you may get unexpected behavior.
To properly debug your code, review everything in the routes, controllers and Auth related middlewares. Try disabling as much code as possible to get the minimum working code which gives you error and that way you can catch the bug causing it.
Let me know in the comments if require further help.
Related
I have a problem with my Laravel 9.x App (modifying from Laravel Breeze by switching from Tailwind to Bootstrap 5). Everything works fine in local, nothing serious happen. But when I deploy it on DO Server, the problem begin. The problem is, I got 419 Page Expired after doing a POST request (Login/Register/Logout) at a certain time. However, sometimes it works fine, I can register & login, but when I'm try to logout it returns 419 Page Expired. I've checked every single form to put #csrf and I still got 419 Page Expired. Then I'm trying to comment out the \App\Http\Middleware\VerifyCsrfToken::class on my live server, and every POST request works fine BUT, it didn't generate login session for me. Any ideas to fix this issue?
Then I'm trying to comment out the \App\Http\Middleware\VerifyCsrfToken::class on my live server, and every POST request works fine BUT, it didn't generate login session for me.
This sounds like you site isn't using HTTPS and the browser is discarding the cookies in between the requests. This can also happen if you are using HTTPS but posting to HTTP (or vise-versa).
This behavior is expected if the cookie is set with the Secure flag. I've also seen some browsers do this anyway even if the Secure flag is not set.
In Laravel, this feature is not enabled by default. It is enabled via the .ENV variable called SESSION_SECURE_COOKIE being set to true. You can see this yourself by checking the config/session.php file.
This is a good feature to have enabled.
If you have setup any CORS (Cross-Origin Resource Sharing) policies then you may want to make sure they are not blocking parts of the request as it can have a similar effect. Something like https://www.example.com is not considered the same as https://example.com if a wildcard was not used when defining the CORS policy. These policies are a bit in-depth, so if none of this sounds familiar then you probably don't have one at all. If unsure, an easy way to check is to look at the developer console in your browser. They typically complain in red text about something being blocked by CORS if it is happening.
First - coming back to this project - never saw this issue before so asking if anybody else has - when I set the project down it was working perfectly. Additionally - several other projects on the same server using the same setup are working flawlessly.
So problem is this.
I login, the login is valid (I'm using DirectoryTree/Laravel to authenticate against LDAP, and have logs showing authentication was successful. All other projects are also using DirectoryTree/Laravel - and since the login is processing I cant see this being the root cause).
I'm immediately redirected back to the / (correct behavior) - but the login form returns instead of loading the vue components when auth:check = true.
I can hard refresh the page - and suddenly I'm logged in. (Must clear cache hard refresh at the browser) same action whether on Firefox, Chrome, Edge. The log in is processed - but its like the session isnt being updated.
I'm using the normal login form with the ui:auth setup.
Anybody ever seen this?
Turns out the issue was a web service worker I had forgotten I had on the HTTPS site. Best guess is its not recognizing that the site is online and is reloading information from the cache as it is a PWA application meant to be used on the internal network of the company. Once I removed the service worker - all was good. Never saw this action from it before so will investigate that further, but I have at least found the main error.
Closing this question and shout out to #Wesley Smith for getting my brain working.
I have 3 working apps that I am moving from one production server to another. All 3 of the apps use Auth. All 3 work fine on the original server. On the new server, one of these apps works as it should (it happens to be CakePHP 1.3) i.e. after logging in the user's session data (like user name and role) is available in my PagesController after the redirect.
On the other 2 apps (one is 1.3 and the other is 2.3), after the login redirect, the session data seems to be gone. I have confirmed this by debugging $this->Auth->user() in the PagesController. I have also confirmed that the session data IS there after the call to $this->Auth->login() in the UsersController but is gone after the redirect.
Because these are apps that I have been using for years, I am confident that the problem is some configuration issue on the new server - something like a directory permission. I have reviewed all permissions and can't find a problem. I have compared the permissions on the one app that works to the ones that don't and I'm stumped.
Any suggestions?
Try with ob_start() or session_start() in the top of the AppController before starting the class.
Thanks..!
I have also posted this question and workarounds on the CakePHP Google group and added more detail. Please go to:
https://groups.google.com/forum/#!topic/cake-php/ORfK1b9AYTU
The problem is that sessions are not starting after the redirect. The work-around is to call CakeSession::start() in AppController in beforeFilter() , although this should not be necessary.
Ken
Help! I don't know why, but recently I can no longer log into my Symfony2 website. When I try to login, I simply get redirected back to the login page with no error, and no indication of what is wrong. I've cleared my apc cache, my prod and dev caches, and I've been able to reproduce the error in both dev and prod. I've set g+wrx and u+rwx recursively.
How do I debug a login page when no exception is being thrown? The error occurs in multiple browsers on multiple machines.
It turns out I had a de-sync between the form_login check_path in my security.yml and the root of my FOSUserBundle routing information. Because the two didn't sync up, clicks on the login page would simply result in a page redirect rather than passing it to the login classes.
I'm having an apparently IE-only problem with FuelPHP's SimpleAuth login. It works fine on localhost, but on the staging version of the site I'm working on, Auth::check() always fails after login.
If I dump the contents of Auth::check() on validation of the login form, I get true, suggesting that the user has been successfully logged in. However, after I redirect the user to the next page (using Response::redirect), Auth::check() evaluates as false again. I don't think the problem is directly related to the redirect because even if I don't redirect the user, the login still fails.
For some reason this problem only seems to occur in IE (both 8 and 9). In Opera, Firefox, etc, the user login and logout works fine. As I said before, it also works in IE on my local development version. I can only think that it must be some cookie or session-handling problem, but I'm at a loss to figure out what the problem is. I'd be very grateful if anyone can shed any light on this!
I'm using FuelPHP version 1.1
I have been stacking on the same problem all day long, finally, I solved it.
In my case, the problem was on Safari / Mac, the session was killed every time after I logged in. In fact, it was because I use ajax calls( with relative path on the server ) to login my user, and apparently the ajax call send an user agent different with http calls, and the mismatching cause Fuel to kill the session.
The solution that I use is to disable the match_ua value in the session configuration.
For making things more secured, I enabled match_ip instead. I don't know if it was the good solution.
I still don't know why the user agent will be different. If someone can make me more clear on this problem, thanks a lot.