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.
App was developed in Web API. We are using AntiForgery Token validation for all the POST calls in xyz.com. Registered xyz.com users get email alerts for the contents they are signed up for. Users click item from email to view the content details. On click of item first click event is being saved in SilverPop and silverpop redirects to actual content in xyz.com. Details page is being loaded with out any issues after authenticating the user based on few query string parameters. Issue is when user make a post call(to saving for later, book mark etc) App is throwing Antiforgery token mismatch error. Sorry for bad English and long question. Strange part of this issue is We are unable to replicate this error and its not occurring consistently. We have two server and 1 load balance hosted in AWS not using sticky session enabled. Using Forms cookie authentication. finally, this issue kept occurring though we run with 1 server. Thanks for reading and appreciate if any one could help.
*User must be Authenticated to validate CSRF token ? This xyz.com makes few api get and post calls.
In my application I use web services to get required information. To actually use this services you have to login first, you get your token - encrypted password, afterwards this token is attached to SOAP requests to identify current user. The thing is, when you do not use service for 15 minutes, your token changes and when you are trying to obtain another bunch of information from the server it denies old token. As a result app do not get required information and throws a heap of errors.
How to send user (load Login.axm) to Login page when token has been changed?
Thank you, Shay Shmeltzer for your answer.
How I solved this problem:
1) First I read how does sessions work in my particular case. I used stateless session which means -
A new session is opened for an initial request and the session remains
open for subsequent requests. Relogin occurs automatically
(transparent to the user) if the session is closed. UsernameToken and
PasswordText must be included as SOAP headers in the initial request
to open a stateless session.
Stateless session management is the best method to use for high-load
Web service applications. Using Stateless mode, the application
provides the username and password only once, that is for the initial
request. A session is opened on the server and is dedicated for this
user.
In the response Siebel Business Applications return the SessionToken,
which is an encrypted string containing the information about
username, password, and timestamp. For subsequent requests the
application must use the SessionToken to reuse the session.
For security reasons SessionTokens are regenerated for each response.
The application must provide the last received SessionToken for the
next request.
The SessionToken-Siebel session map is maintained in the Siebel Web
Server Extension (SWSE); based on the SessionToken value SWSE sends
the request to the correct Siebel session (task).
Although the session is persistent, authentication happens for each
request (SWSE decrypts the UserName and Password from the
SessionToken).
the main problem was :
NOTE: Reconnecting or automatic logging in again will only happen if
the token has not timed out. If it times out, then the user must
manually log in again. Token timeout must be greater than or equal to
session timeout. For more information on session token timeout, see
Session and Session Token Timeout-Related Parameters.
in my case standard session token live time was 15 minutes.
That is why I included counter in my code and checked it before each request. If counter time > 15 minutes, I sent log in request to the server to get new session token. The reason, I did not change current page to log in page straight away after the counter exceeds 15 minutes is: place in code, where I check counter is already initiated by the bindings to get required value to render it, so if your token has expired you will get a heap of errors. That is why firstly I renew the session sending log in request, get active session token and put it into the last request which is requested by binding. After app renders page without any errors, it shows pop up message "Session has expired" and goes to log in page.
You can programmatically set the soap header being sent to your SOAP service from ADF Mobile - http://docs.oracle.com/cd/E37975_01/doc.111240/e24475/amxwebservices.htm#CHDIBIIE
I have a question regarding authorization in MVC3.
I'm currently looking at dening certain user access to the application.
I can du this in 2 ways. in the web.config (for global settings) or on the individual controllers (or actions).
But I see a different behaivour in these 2 approches.
when a user is denied access using web.config settings, they get a 401.2 error page stating "Access is denied.".
If they are denied access using a controller setting they still get a 401 response, but a blank page.
If I were on a regular JSP application I would simple write a servlet filter that if it detects an expired session redirects you to a page that explains your session has expired.
In GWT are only doing calls in the background so a http response redirect would not reload the page. Other than having all GWT rpc calls inside a base object that returns the session status does anybody have a suggested way to detect an expired session? Perhaps a timer that calls an RPC method every 5 minutes?
Normal way is to throw an error on GWT-RPC call saying that the session is expired. Then you need to handle that exception on the client side (f.e. display login page to the user or something else).