A user has 2 ways of getting to this MVC3 website.
Through a log in screen.
Redirect from a different website.
I'm currently just showing a session time out page if the session timed out. However, the business now wants to redirect the user back to where he came from on session timeout.
How would I know where the user came from?
By the time I'm out of session, I don't even know who the user was. Although, that wouldn't make a difference, since the same user could come from either place.
Tricky. You could use a similar technique to what happens when you request a page that requires authentication. In that case, you are redirected to the login action, but the original request is added to the query string with http://localhost/Account/Login?returnUrl={your original request here} so that you are taken to your original requested page once you are authenticated.
In your case, you would have to save to the current session the incoming HTTP_REFERER on the login page, then add that as a '?returnUrl=' for every link to the logout page. Then you'll have to add code to the Logout controller method to handle the redirect.
Note that this technique won't work with deep linking to restricted auth pages (as described in the first paragraph), since that would require two redirects. The referrer would not be valid at that point.
Related
Currently, I’m developing a web app with server-side rendering using the Gin framework and I’m having a problem with login intercepting. When an HTTP GET request hits an endpoint, middleware is used to check the browser cookie and redirect the traffic to the login page. This works fine and after successful login, the user is always redirected to the dashboard page. My question is how I should redirect the user back to the originally requested URI instead of the dashboard page?
Also, a bit more complex scenario is on HTTP POST. It looks like the HTTP POST method doesn’t work quite well with a redirect. Also, how would I resume the request with the same post request after the user successfully login?
Thanks for the help!
For the HTTP GET scenario, this one is easy, you need to remember the original URL somewhere. The are a few ways you could go about this:
Store the URL in session information(if any is available, you do need sessions for non-authenticated users)
Store it in a query string, for example, redirect to example.com/login?original=https%3A%2F%2Fexample.com%2Fanother-page. Your login page can look for the query parameter and include it in the login form or make sure that the action of the login form matches the given URI. On a successful login attempt you can get the original URL form the query param and set it as the Location.
Store the original URL in a cookie, upon successful login you can just check the cookie value and use that.
As for the HTTP POST scenario. If you just want to redirect the same POST request to a different URL you can use a 307 Temporary redirect. A 307 will preserve the request body and method and not turn it into a GET request like a 303 See Other or 302 Found.
Resuming the original POST after showing the login screen and after a successful login is a little more complex. When you redirect to the login page you interrupt the flow of the user, maybe it is better to let the user re-post their request after logging in, instead of doing it for them.
Having said that, it is technically possible. We require two steps, first is storing all the data to recreate the request. Then after login completion we can render a form with this saved data and use javascript to submit the form. By adding:
<script>document.getElementById("myForm").submit();</script>
After your form, the browser will submit the form after loading the javascript, thus recreating the original POST.
The storage part can be done via the server side session or a cookie.
In implementation of Login, I want to make sure if a user is already logged in one tab of the browser and opens the same web site in another tab, he gets redirected to homepage rather than the log in page. It's an ideal scenario as it happens in all the web site. I am achieving the same by storing logged in unique user token in local storage. Is it the best way to achieve it? Kindly guide! is it safe? If not how to go about it?
Just consider everything on the client as tainted or possibly manipulated.
So basically you should always check on the server side if the client has a valid session and only then deliver the homepage to it.
I would use a cookie set by the server side - just a random id bound to the actual client session on the server.
So the client could mess with that, but would have a hard time to guess another (also random) session id.
The cookie should be cleared by the server if the user logs out.
Then I would check on every call if he has a valid session id and if not directly send him to the login page by a redirect. Additionally you could then send him from the login page to the homepage whenever he is already logged in.
I can redirect a user to home page upon session logout.. this was very simple. However, if an user had logged into the app and had the page open, even on session time out, he is able to perform all the functions(this is bad).
The redirect does not happen until the page is refreshed, or submitted to the server... there are some update functions that could be done by the user even if he is not currently logged in... I have done a lot of research but unable to fix this solution. I also found this thread but it seems to have no proper answer:
Spring Security 3.1 - Automatically redirect to login page when session-timeout occurs
For example, most of the banking sites log you out after a time out.. they do not wait until you come back and then submit a request before you are redirected to home page.
HTTP is stateless. To achieve some form of state the server can maintain a session for each user by giving them a session id on their first request. The user would have to resend that session id on each future request to identify that the other requests happen within the same session.
Because the session is maintained by the server, there is no way to notify the client that the session has timed out.
Instead, if the user makes a new request when the session is timed out, their session ID is no longer good and therefore you can take a particular action like redirect them to login page.
Assuming nothing works out. You may want to consider below mentioned approches:
Approach 1:
Create a cookie on browser and have encrypted timestamp in it that will contain last visited/request timestamp from browser, for each request first get get this cookie value and compare with the pre-defined session out time, if session-out time reached then redirect user to error page else serve the request. On logout delete the cookie.
Why encrypted value for timestamp: if somehow user gets to know about cookie used for session timeout then (s)he can change this value in browser and keep on sending this request.
Approach 2:
You can also achieve this by making an entry in your database for every logged-in user and updating timestamp in this database for each request. For each incoming request get this timestamp from database and compare it with pre-defined value for timeout and handle accordingly. On logout delete the entry.
In both the approaches explicitly perform response.redirect("errorPageUrl");
I'm working on AJAX login form. On submit it sends login data to back-end. If there is a problem with login, appropriate response is returned. When login data valid, back-end creates a session for user and sends back a URL where user should be redirected. I want to return URL, because it changes depending on multiple user settings (language, personal/business, etc.).
Am I overlooking any security issues with this approach? Is it possible for attacker to redirect user to malicious website when browser trusts URL returned from AJAX call?
No, that's a pretty standard method for handling login via an asynchronous handler (assuming that you're doing this over HTTPS, if not, all bets are off).
And yes, it is possible for an attacker to redirect a user, if you allow the attacker to set where the redirect goes.
So that means that you should validate any user-inputted (and hence potentially attacker set) URLs that you're going to redirect to make sure they are safe. Basically make sure the URL is on your domain, and make sure that it's a valid URL. You can go deeper (check for XSS style attacks, etc), but you usually shouldn't have to as long as you're practicing good security practices in the rest of the application.
But then again, that's just basic application security Filter-In, Escape-Out. So filter the inputted URL, and you should be fine...
I am using Asp.net MVC 3 in my project. I have a simple login page which takes username and password and after successful login, take me to the required page.
The problem is when I press back button from my browser and then press forward button again and again, it takes me again to the page without getting username and password from the user.
I don't know, may be it is the problem with sessions state. Because I didn't make any sessions and I don't how to make it.
Please anyone out there help me a bit to mitigate this problem.
Your session id is stored in a cookie, on successful authentication, the cookie gets stored on your machine, when you move forward in history, it doesn't get removed.
If you explicitly clear the cookie on each visit to the login page using:
Session.Abandon()
this will kill the authenticated session and create a new anonymous one, which shouldn't have access to the restricted page