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.
Related
I have a basic Spring (v5.3.23) web app running in an Apache Tomcat container (v9), and using eclipse as IDE. It uses Spring security for processing logins.
Everything runs almost correctly, but sometimes, after a successful login, the browser shows a white page, while there is no exception logged server-side or any other message. The problem appears both in development environment and production environment, so I don't think it's eclipse-related.
I have managed to pin down the problem to the following sequence :
Start tomcat container
Open login page in browser
After login, the secured home page is displayed correctly
Re-start tomcat (the problem occurs both when changes are made to the web app or not)
Refresh the browser, which redirects to login
Login again
The blank page is shown, no exception logged, no log messages in console
In this sequence, the problem occurs most of the time. If between steps 5 and 6 I refresh the page one more, meaning the login page is reloaded, the white page problem does not occur anymore, and the proper page is displayed.
A strong possibility is that it's something related to either the CSRF token in the login form or the JSESSION cookie of the container, but short of debugging through Spring code, I can't figure it out.
LATER EDIT
I narrowed down the issue to the CSRF token; if I change the value in the login form, I always get the blank page.
I have noticed the _csrf token has one value in the login form, then a different, but single value across all form that are used while the user is connected. Seems like the _csrf token is linked to the user session somehow.
The same happens when the login page is refreshed: different tokens in login & other app forms, but somehow,, sometimes, the initial token does not match what the server expects.
I've developing an update to an existing Laravel System (currently running Laravel 6 and PHP7.4), that runs on both EC2 and Laravel Vapor Setups, and have run into some very strange issues that only present themselves on Vapor Setups. These issues relate to Cookie Generation Failing and POST Routes being ignored when handling Routes.
Issue #1: Cookies No Longer Being Set
The first issue presents itself immediately upon loading the system up for the first time, no cookies are being saved, even though our .env is configured to do so:
SESSION_DRIVER=cookie
Without Cookies being generated, forms can't be processed and users cannot be marked as authenticated.
The system itself has had no changes made to it in areas that would touch core logic around Cookies, but none are now being generated. If we revert the codebase to the previous release without these changes, the system runs perfectly on the Laravel Vapor Setup, but runs without issue using both version of the code on the EC2 Setup.
Potentially Related: Redirecting users seems to be being done with JavaScript on the problematic Vapor Setup, whilst EC2 and Local Development Environments are managing to do so using headers. This indicates there's an issue somewhere in the code that's being used, but the areas that manage that code, as mentioned a few times, haven't been touched during development.
Issue #2: POST Routes Being Ignored
This might be a run on from the first issue above.
POST Routes are being completely ignored from our web.php file. I've tried submitting forms, I've tried using Insomnia to make requests to them, and have even tried setting up a route that would catch requests to any route that was using the POST method, and in each case they were being completely ignored by the system.
Submitting our login forms leads to a strange error being output:
Call to a member function can() on null (View: /var/task/resources/views/core/main/parts/headermenu.blade.php) (View: /var/task/resources/views/core/main/parts/headermenu.blade.php) (View: /var/task/resources/views/core/main/parts/headermenu.blade.php) (View: /var/task/resources/views/core/main/parts/headermenu.blade.php)
This error is strange because it should only be displayed after a user is authenticated, but submitting any details to the system gets this output, even blank details. I'm not sure how the user ends up on an authenticated page, as the POST route that handled authentication is being ignored, so no authentication logic is ever being run. I can, at least, confirm that the system is able to connect to the database to run verification logic, but the route that does so is never accessed because of this issue.
Honestly, I'm coming up blank on solutions to both of these issues, but they're blocking progress with this feature. Any and all guidance on where to look, or how to resolve the above would be most greatly appreciated.
My web-application developed on Vaadin - Servlet using Tomcat server.
When user clicks logout link, session timeout error is coming and then after some time it is automatically redirecting to login page.
Previously the redirection was so fast that user was unable to see this timeout error.
But now after some version update in Vaadin, user is able to see this error.
Suggest a way to resolve this issue.
I am thinking of finding a way to stop the browser from showing the error message for session-timeout , when the session is timed out using logout button.
How to achieve it. Or is there a better solution you can suggest?
Thanks in advance.
Before invalidating the session disabling the Push Mode.
Page.getCurrent().setLocation(location);
UI.getCurrent().getPushConfiguration().setPushMode(PushMode.DISABLED);
session.getSession().invalidate();
This will work fine.
The problem comes because support for Push is not fully implemented by all servers. So on some servers this problem may not arise.
With above logic you can also set Transport.LONG_POLLING which works fine for all servers.
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.
I have tow applications deployed on 2 different tomcat servers.
first application completely consists of .js and .css code prepared using backbone.js and application 2 consists of a Spring MVC,Rest application which handles the rest calls made by the backbone application
I am facing a problem in this scenario, which is at the time of login when a request is send to app-2 , response is send consisting of all the login session related details in a Json object. After the response is recieved, all the received details is stored in backbone model object and a view called Welcome is rendered accordingly.
But what if i do a page refresh on welcome page, will the details in the model persist. If yes then no issue but if no then what should be done ???
No, the JavaScript models will not persist after a page refresh. Generally, the way I've seen it resolved is having two authentication calls in app-2: One to log in, and another to check if logged in. This way, when the page loads, you can quickly make a request to check if the user has already logged in. If so, then forward to the app. If not, let the user log in.