I need to be notified any time a largeish asp.net mvc web application makes an ajax call to the server. We're using both jquery, and the built-in Ajax.* methods to do the remote calls, and I would like a global way of knowing when we make a call without having to manually inject some sort of "IsMakingCall" method to every request.
The root problem we're trying to solve is session timeout. If the user leaves a page up and goes to lunch (for example), they get errors when they get back because the ajax call is returning the login page instead of the expected json or partial html result.
My idea was to have a js timer which would be reset any time we make an ajax call. That way, if the timer runs out (ie. their session has now timed out) I can just auto-log them out. This is how sites like bank of america and mint.com work.
Thanks!
I handle the problem you describe in a different fashion, client-side. I have a jQuery plugin on my master page that will prompt the user to renew their session via a dialog just before it is set to expire. If the user doesn't respond (or clicks logout), it calls the logout action on the application. If the user "renews" their session, it makes an AJAX call back to the server, resetting the sliding window server-side.
You can find code on my blog, http://farm-fresh-code.blogspot.com. Right now it doesn't take account of AJAX actions that may renew the session, but you could instrument it so that jQuery AJAX, via a global ajaxStart would reset the timer. It uses ajaxStart to reset the timer when a jQuery AJAX request is made. I don't use MS AJAX much so I'm not sure if there's a global hook you can use. It doesn't appear so from inspecting the code, but you could manually add one via AjaxOptions to each request. You might investigate adding a handler to the Sys.Net.WebRequestManager, too.
Basically, the problem here is the default behavior returns back a login page. The result of that is a 200 OK, which to jQuery is a successful call. Correct this handling for ajax calls from MVC and you should be good.
I think the most straight-forward way to handle this is to change the way the Authorize works for ajax scenarios. You can tell if a request is Ajax at that point, and return a similar status code that ASP.NET doesn't invoke the login redirect for(403). Then jQuery will interpret as a failure and fall into that code on the client script.
You can then easily have a shared function in a common js file to handle a friendly way to tell the user they have expired their session.
Something like this might do it
public class AjaxAuthorize : AuthorizeAttribute
{
protected override void HandleUnauthorizedRequest(AuthorizationContext filterContext)
{
if (filterContext.RequestContext.HttpContext.Request.IsAjaxRequest())
{
filterContext.Result = new ContentResult();
filterContext.HttpContext.Response.StatusCode = 403; // 401 would make ASP.NET return the login page and a 200 OK status
}
else
base.HandleUnauthorizedRequest(filterContext);
}
}
I guess you should create default handler functions for success or begin in the jQuery Ajax framework, depending on when you want the notification to be sent...
Related
In my Web Application I have jqGrid and other struts2 jquery plugins , now what i want is to have have a global error handler function that will redirect to my index page if error occurs any idea how can I implement this functionality.
You can use Interceptor to manage your exception on application level. Also see this document for exception-handling in struts.
You can also use global-results to fulfill your needs
If you handle exceptions by redirecting to index page it will only behave in desired manner when request are generated by browser directly rather than Javascript asking browser to generate request using Ajax. e.g. by clicking on anchor tag or directly accessing application through URL. In these conditions only you will get redirect to index page.
Ajax is used to send data to, and retrieve data from, a server asynchronously (in the background) without interfering with the display and behavior of the existing page on client side. Javascript responsible for calling Ajax has to handle response from server. So you have to manually trigger redirect. Have a look at this related Question.
I'm recently facing the problem with last request url after login. Normally, everything works properly. But if I proceed following procedure I have troubles:
Open an App in one tab and log in
In this tab I go somewhere where AJAX request to the server are proceeded regularly
Open a new tab with the app (I'm still logged-in)
In this tab I log out
In the mean time the AJAX request from the 1st tab is proceeded automatically
with HTTP 401 (cause I've logged-out)
When I try to log in again in the 2nd tab than I receive the JSON of the AJAX request from the 1st tab because it was the last request.
I would suspect that Spring Security would neglect AJAX request for "last request url". Is it possible to set this somewhere? Or is there any good workaround to this?
Thanks,
Mateo
I don't think there is a general way to distinguish ajax requests from "regular" requests initiated by the user navigating a browser. If you can distinguish them in your application (e.g. by mapping ajax requests to specific urls that can be matched against some patterns), you could easily implement what you are looking for. (EDIT: An easier way to identify ajax requests is suggested by Sérgio in his below comment.)
The component that is responsible to perform redirection after a successful login is SavedRequestAwareAuthenticationSuccessHandler, therefore one possibile way to customize the framework's default behavior is to provide your own AuthenticationSuccessHandler, and inject it into the UsernamePasswordAuthenticationFilter. It should be possible to autowire the RequestCache in your class, and decide if you want to replay the last cached request or just ignore it in case it's known to be an ajax request.
Hope you can help. In my ASP.net MVC3 app, all my controllers descend from a customized controller I have created.
Upon FormsAuthentication time out, my app correctly redirects users to the login page if they attempt to access any page (standard functionality).
However, for Ajax.ActionLink and Ajax.BeginForm calls, they just return nothing, which confuses users if the browser is left open for more than 20 minutes and then they try to access an Ajax link.
Is there any code I can put in to my base controller that will work generically so that when it detects an inbound Ajax call and we have timed-out, it will redirect users to my login page as expected?
I don't mind if it doesn't return to the original page afterwards - happy for it to just go to the Home Index page.
Thanks in advance for any help you can provide.
Simon.
You may take a look at the following blog post which illustrates a nice way to prevent the FormsAuthentication module from redirecting to the logon page in case of an AJAX request and simply send a 401 status code to the client so that it can act accordingly.
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.
I'm refactoring some MVC code that originally used POST'ed form data. The form's fields are serialized using jquery's serialize() method and sent to an MVC controller Save Action that checks things out and redirects as appropriate (if errors in form values, redirect to the Edit Action, if fine then save and redirect to the Display Action). All actions are invoked via AJAX and return Partial Views. Everything works grand. Note: The site uses AD-based authorization, so users are prompted for their windows credentials upon first loading the site, but are never prompted again.
However, I'm now looking to interact with the server via JSON objects instead of form fields. Granted, I serialize the JSON object on the client and, with the aid of an imported MVC2 Futures/MVC3 class JsonValueProviderFactory, am able to correctly model bind the sent JSON object to a C# class in the Controller's parameters.
I maintain the same logic, but things start to blow up when I try to return a RedirectToAction ActionResult when the Controller accepts JSON objects. I lose authentication, the user is prompted for their credentials again, and I find myself in a infinite loop on the originally requested Action (save). Every time the user is prompted for credentials and simply runs through the Save Action again. The end result for the user is an unending alerts prompting for login credentials. Neither of the actions specified in the RedirectToAction calls are ever hit.
Can the fact that the original request uses a JSON contentType be interfering with the behavior of RedirectToAction? That's the only thing I can think of as it works fine when I don't use JSON to post and it works fine when I return PartialViews instead of using RedirectToAction. The infinite repeat of the Controller Action and continual loss of authorization credentials seems to suggest that RedirectToAction is not the way to go in this situation.
I can post code on request. I am also successfully handling stuff like copying the ModelState over to TempData and other RedirectToAction tricks. Again, it DOES work when using a non-JSON solution. Any insight is greatly appreciated!!
EDIT WITH FOLLOW-UP INFO:
Turns out, I get an "Unauthorized" error even when I completely disable NTLM authentication/authorization for the site. IIS server doesn't look for any authorization, web site doesn't look for any authorization, yet the error when trying to Redirect with JSON contentType request still occurs and complains of being "Unauthorized". This is WEIRD.
To update everyone, I haven't found a solution nor do I know for-sure what the situation is. However, I'm willing to bet it has to do with the fact that RedirectToAction issues http GET requests and the action I'm redirecting to only accepts POSTs. Even if I remove the restriction, it's still sending JSON data and it still needs to be done by POST.
In short, RedirectToAction with JSON data appears to be fundamentally undoable. You need to POST JSON data but RedirectToAction emits GET requests. That's my going theory, at least. =)