Sometimes my clients feedback me there exists token mismatch error.
I increased timeout. But sometimes it happens. Can we regenerate token instead of showing whoops message ? Because it is not good for users.
You could wrap your code in a try-catch block, and catch the Illuminate\Session\TokenMismatchException, and redirect your user back or wherever you need.
Guys here say that it may be due to difference in timezone setup.
Related
Good evening,
I'm using Laravel with VueJS and I have a little problem with disconnection.
Example: I open 2 tabs, log out on one, go back to the other, and I can still do what I want, like create a user.
But I can't change route (that's normal, I use a befor each in the router).
How can I do that, to prevent any action being in the same route?
Thank you in advance, don't hesitate to ask me more info if you need more info
Server-side
You need to check for the non-expiration of the session:
if(Auth::check()) {
// Code which should only run if the user has a valid session
} else {
// Code for handling the non-existence of session
}
Client-side
Your client-side should always know if a request has succeeded and handle eventual failures. This is valid for a session which expired for some reason, but other issues as well, like request timeout, or even some errors.
Make sure the logout happened
Something like this
Auth::logout();
should be executed when you log out.
I have an application built on Rails 2. If the user opens two instances of the same application(dev, uat or any two), it logs out while the person is active. Also this behavior is inconsistent. sometimes it happens within 2 minutes of login and sometimes it happens once in half an hour.
Also a very interesting thing to notice is If I disable the validation for CSRF token, the user never gets logged out unless the session times out or the user logs out voluntarily.
--Update--
After digging more into the issue I found out that the CSRF is not the cause of this issue. The session id is getting deleted from the cookie. What could be the possible cause of the issue
So As I already told in my question that the CSRF validation is not the cause of the log out issue. So I digged deeper and saw that randomly the session_id cookie was getting deleted and that is when I try to use the application further it was obviously getting logged out.
So the fix for this was to make sure that the session_id cookie should not be allowed to be deleted. In order to do so I marked the cookie as secure. Although I was still not able to find out the root cause of this cookie deletion.
I was using the SqlSessionStore to store session info. Following is the Fix that I put:
ActionController::Dispatcher.middleware.swap(:"ActiveRecord::SessionStore",
SqlSessionStore, {:secure => true})
Why does recaptcha v3 throw an error ?
... when I check the humanity of a visitor a second time on the same page?
Token is clearly NOT a duplicate.
... so what is a duplicate?
First token:
03AEMEkEl76Kn0nMhKlgY8dMOAD2g3zGIHoGOqz95jEFKl8A24gADw-2gBipDYcU7G_TWSqpuWyNa62CIk-tYdreevde0p1lJg_3wwZlmD9giDSdPb_He-mTsIqv0tMuEroJLLArCI4vfbZjcCZ6BYokYEhYbCU-Qqdx9YbqgRG1JJDxE8LRagR0cPY8mfQZ5bZ7KGK8Dfqe8avqOy18RvIcYk-H6s9Bhq28s5YRIkHid163c-yqpeY8U5j9U70aveSuEcLz-UMlgsQ8MaYhHIIv7cJpag2RJFAgGxOZnWONEk2Z9-IK_Ea_4
recaptcha v3 Response:
{
"score":0.1,
"hostname":"localhost",
"success":true,
"challenge_ts":"2018-07-17T21:24:03Z",
"action":"AW___________LGOZCKiH_oQBEJnwwYcD"
}
Second token on same page with same label:
03AEMEkEk-CVItfMmzYErG97inmxzf7mIeWuAgEXmwncu8AvMGP0ofXnwCMFNdBpa7CY8MCkVZ_skiF1HwmGhKBgayFm-fM3VM_QfM5LRNDbxLLyCF8lGclmBBlihmkeT1PsvW9LrVfp2VdikuHxeqvviGnI2NKQHbclvaDnuu5rwy3HS_EiPrn7eJb3z892f8oIOMkVg6tTsCNPCTnH5QuvAIw2DlI3EiRFDSqIjXp4vJdzJIGn10K6Noi1JIPOCzJ8OUshn_yFROWvNNpYNFn3E7tSHk3j0LU9-KDy1RiSoEf2I1VcVEKTE
recaptcha v3 Response:
{"error-codes":["timeout-or-duplicate"],"success":false}
Yes, This is the error code we get in two case.
1) When we send same token for two requests
2) The token gets expired in every 3 minutes. So if the user do not submit the form in 3 minutes then the token gets expired and we get this error message.
The token might have timed out. It happened to me also. On page rendering, a token was generated but I performed an action after a long time. Then it gave me this error. But if the token is generated on action performing then it works fine.
I had a similar problem, but I realized it was not a good understanding.
This error message happens when:
1. The token was already verified, so it becomes "duplicate".
The token was executed 3 minutes or more before it was verified, so it becomes "timeout".
Regarding the second scenario, the idea is to verify the action when the action is executed. Meaning, if you want to verify a submit operation, then you may need to generate the token to verify when submitting, not right after the grecaptcha Object is ready.
Online documentation has an example where the execute methods is invoked right after the grecaptcha is ready, but that's the case when you want to verify that execution right away. In the case of formularies, the execute method should be placed in the same routine of the form submission, makes sense? Probably I am mistaken, but I have been able to verify click actions, form submit actions, close popups actions, you name them. 😉
The monstor captcha token generation at the time of page load is definitely is not a good idea as it expires after 2 mins. If still you bound to do so, you have to renew the token after some time intervals using 'setinterval' in JavaScript.
So to generate the token on button submit 'execute' will do your work better. You can call ajax or java script to call the execute method. Please refer google reCAPTCHA v3 documentation for more information.
This is often seen in Laravel. When a form is submitted, sometimes the application redirects to a page saying:
The page has expired due to inactivity.
Please refresh and try again.
I know that this is a security mechanism in Laravel against CSRF. How can it be prevented from displaying since this may not be appropriate when application is deployed in production server.
It's the 419.blade.php template that is being resolved.
If you want to change the message, you can make this file in views/errors/419.blade.php
If you want to capture the exception and perform your own actions against it, you can use the App\Exceptions\Handler.php and specifically capture $e instanceof TokenMismatchException.
Then within that conditional you can choose what action to take.
Starting from the point where an user has given permissions to the app, and the access token is stored in session. Following Google's web server app example, I'm just checking whether an access token exist.
However, the token might expire, or the user might remove it manually on his account page. How do I check that the token is still valid, before executing a request?
Or maybe that approach is wrong, and the correct design includes that I should handle the error after executing the action, and if it's an authorization error then show the user a way to authorize it once again?
The latter is the recommended approach. By assuming failure and dealing with it routinely, your app is much more robust. The only downside is that an access attempt takes a bit longer because of the need to fetch a new Access Token and retry. If that's a problem (it shouldn't be normally), then you can always note the expiration time of the new Access Token and set up a background process to renew it with say 5 minutes to spare.