I have an ASP.NET MVC 3 application. The site involves people writing lengthy responses using a textarea in a web form. Occasionally, users are complaining that they are getting redirected to the log in form after they post their data. I am not sure exactly why they are getting logged out because the users do not typically provide enough information on their errors. I believe it is due either to a session time out or the application has been restarted for some reason. This is on a shared web hosting site and it does not have its own app pool.
In any case, regardless of the reason, I would like to capture that post data and save it to a db or text file. How can I get the post data and save it while the controller redirects the user to the login screen.
I know the long term plan would be to identify why the timeout is occurring. But for now I want to be able to grab the post data and recover it at a later time.
First, in order to avoid timeouts, I would recommend using client-side heartbeat solution (like http://plugins.jquery.com/project/Heartbeat)
Second, assuming that you are using forms authentication, in order to save posted data, when Forms Authorization Module is redirecting your users, you will need to intercept redirects in EndRequest HttpApplication event handler in Global.asax or your own module.
The way to intercept those requests is not that straightforward, since on "EndRequest" pipeline step you will see 302 HTTP status code (redirect instruction), not 401 (Unauthorized error). So you may check if request is not authenticated (HttpContext.User.Identity.IsAuthenticated) and request is redirected - in this case you may save what you see in the request.
Otherwise you would need to disable forms authentication and use some solution, which is closer to ASP.NET MVC.
one solution can be to put a javasscript timer which keeps on hitting the server after specified interval to keep session alive until u figure out the cause of session time out (only i its the session timeout problem)
If you want to stop the session from timing out, you can add a hidden iframe on the page. For example, create a new page called KeepSessionAlive and do this:
<meta http-equiv="refresh" content="600">
where content = seconds.
I don't know about MVC 3, but the way you can get and store the post values is to catch them before redirecting the user to the Login page.
Related
I am here to find some expert tips about handling session in an MVC application.
Basically, what should be done to avoid null session crashes that log errors in event log in a request? (Normal and Ajax) In a normal request, i tend to redirect the user to a specific page telling him the session went out but is that ok? Also, how would you handle a null session in an ajax call knowing you cant simply redirect the user (without having to manually develop something on the client side to handle it)?
The problem is that it generate errors in the event log each time that happen. With enough charge, this lead to a lots of errors.
Why we need to use #Html.AntiForgeryToken()?
I searched but I didn't get satisfactory answer.
This is a security feature to help protect your application against cross-site request forgery.
Example:
Let's assume you have a register functionality in your web app. You have an AccountController (example.com/account/register) where you expect people to submit their info. Normally before someone posts the registration information needs to visit the actual (example.com/account/register) than submit the form.
Let say I am a bad guy and I want to flood your server with junk info all I need to do is just keep posting directly to (example.com/account/register) without visiting your site. So in order to stop me you implement AntiForgeryToken so you can make it sure I visited the page before I submitted the registration information.
Another example is http://www.binaryintellect.net/articles/20e546b4-3ae9-416b-878e-5b12434fe7a6.aspx.
This is to prevent Cross-site request forgery in your MVC application. This is part of the OWASP Top 10 and it is vital in terms of web security. Using the #Html.AntiforgeryToken() method will generate a token per every request so then no one can forge a form post.
What is the use of #Html.AntiForgeryToken()?
Live - Scenario :
Suppose, you are logged into your bank account and are going to transfer some money to your friend. A hacker knows that you are logged in and also knows the URL of the money transfer submission. Suddenly, you get an email and check it. You see an image and by mistake, you click on that. Then, after a minute or so, you get another message that some amount has been deducted from your account. Actually, that image had been sent by the hacker and behind that image a URL has been submitted on your click.
So that we use AntiForgeryToken() in application prevent from hackers.
Antiforgery() is for stopping robotic fill up of any forms. Which will stop adding data without getting into the form
AntiForgeryToken is a security token generated by the .Net Core web application, which is used to validate a post request to guard against Cross-Site Request.
AntiforgeryToken used for validating the post request. So if we access an MVC or RazorPages view which contains the form element with an attribute 'method="post"' then the view gets rendered with an automatic generated AntiforgertyToken value, which gets injected into the form as hidden input field.
My question is about the MVC Antiforgery system (described here).
Consider a simple app which posts todos to /Todo/Create. The corresponding action method has the ValidateAntiForgeryToken attribute. Consider the following client workflow:
User A logs on and goes to the page to create a todo, but doesn't do it yet.
User B (physically on the same computer) opens a new tab in the same browser, logs out of User A's account, logs in as User B. The browser then gets User B's validation cookie.
Some time later, User A switches back to their original tab and hits 'create' on the todo they were making.
In this scenario, the Antiforgery verification will not pass because the form token was meant for User A, while the validation cookie is for User B.
I'm sure there are valid security reasons for this behavior (e.g. a script on another site that manages to login as malicious user so that the 'todo' data is posted to their account instead), but it doesn't stop the above scenario happening for my legitimate users sometimes.
My questions are:
Is there a 'best practices' way to handle this scenario? Is it usually just a case of showing a custom error, telling them to reload the page and/or login again etc?
Is there any way to know when the out-of-the-box MVC Antiforgery system runs into this error? It seems to only ever throw the same kind of Exception (HttpAntiForgeryException). Would I need to revert to using/modifying their source?
I see two ways of handling it:
Use Javascript callback to the server before hitting a button to detect if the user is still logged in. If not - display him a message. It should be relatively easy to do this. But it requires one additional call, and little bit more time to execute your request.
One solution to avoid callbacks could be using html 5 localStorage (and you can support that on other browsers using modernizr, for example). It is shared between tabs. But I'm not sure if this approach is good. Additional research required.
Catch HttpAntiForgeryException on the server, check if the user is logged in. If the user is not logged in, display him a message.
Usually approach (1) is used. On banking websites they detect with JavaScript when you logged out in other browser tab.
I am currently building a rails app, using the devise gem for authentication.
Currently in the app there is only client-side timeout functionality implemented, which I don't feel is a good final solution. Because it doesn't cover the case when a user puts their computer to sleep just for 1 example.
So I wanted to implement the timeout module in devise, however there are several issues I am facing. The issues are because with server-side timeout the user needs to navigate to a different page before they are redirected to the sign in page. And there are a lot of interactions in my app when a user will open a modal in the UI, which will trigger an AJAX call (which will fail if they have been timed out on the server-side).
Here are 2 approaches I have thought of, but I don't see them as good solutions so maybe someone can build on one of these approaches or help point me in a different direction:
1.) In my AJAX requests, add a handler inside the 'error' callback that will tell the user to refresh the page or go to the login page if the error callback returns a 401 Unauthorized response.
Cons: There are a lot of these ajax requests in the app, so there would be a lot of repetitive code and I see this as being difficult to maintain.
2.) Add a click handler to the body and every time it is triggered, send a request to the backend to validate if the user is still logged in. If they aren't redirect the user to the login page.
Cons: Performance issues
Any advice would be appreciated. Thanks.
You can add this from server site.
:expire_after: 120.minute
in your initializers/session_store.rb, Below example.
Tastebook::Application.config.session_store :cookie_store,
key: '_tastebook_app_session',
expire_after: 120.minute
I spoke with another developer who helped me come up with a solution to this issue.
With the client-side timeout, I had a countdown timer starting at 15 minutes, which obviously only works if the user's computer is not asleep.
So instead of a countdown timer, I create a new date object, setting the time to 15 minutes in the future (UTC). And then I set an interval which compares the current datetime (UTC) with the future date object and if it has been reach or surpassed it renders a message with a link to the sign in page. When this message is rendered is also makes a call to the backend to kill the user session to cover the case where the user tries to refresh their browser, which would then result in them being sent back to the login page.
I'm looking for a good clean solution to detecting whether a user has been logged out of an ASP.NET MVC application from Silverlight when performing a web request.
The problem is that the website has a Silverlight component that the user could potentially spend a large part of his time in, thus letting him get logged out of the website. Some of the actions in the Silverlight component triggers a web request to the server (using WebClient), generally getting a JSON result. But if the user has been logged out, the result I get is the HTML for the login page of the system (As the request is redirected).
I could check if the response is a valid JSON result, but if I need to introduce other response types later this will fail. I can also begin parsing the response stream to see if it contains elements from the login page but this seems very inelegant and fragile. Perhaps configure MVC somehow to respond to requests from a specific source by returning a know error response.
EDIT
Using Fiddler I found out that I could look for the 302 response code of the HTTP request. However, it turns out that you can't derive from the WebClient class in Silverlight, so I couldn't easily get to the status code. I considered using the WebRequest class instead but it seems a bit too low level for what I want to do. My current solution is to parse the first line of the response stream.
If you are using forms authentication with cookies, you could try to check to see if the cookie is present.
The following link shows how to access cookies in SL:
http://msdn.microsoft.com/en-us/library/dd920298(VS.95).aspx