how do you handle a time out request in a GWT app ?
Here is a snipped of my web.xml file :
<session-config>
<session-timeout>30</session-timeout>
</session-config>
My GWT project is based on MVP Activities and Places.
Whenever the user waits more than 30mn, i want to display a popup and redirect the user to the login page. Here is what i do for
all RPC services :
public void onFailure(Throwable caught) {
...
if (caught instanceof InvocationException) {
{
Window.alert("Time out de session. Veuillez vous reconnecter. 2");
Window.open(GWT.getHostPageBaseURL() + "identification.html", "_self", null);
return;
}
...}
It works but several things are annoying :
1) the caught exception should be RequestTimeoutException. But it's not caught, which is why i use InvocationException instead.
How come it's not caught ?
2) how can i handle this exception in a more generic way ? It's a bit stupid to have to catch that exception in all RPC services ...
I read about some AsyncCallbackAdapter class ...
3) Right now i handle RPC services only but of course time out exception occurs everywhere : links, buttons, page refresh ...
I'm using MVP Places and Activities.
Is there a way to catch that exception when the user tries to go to a place ?
Thanks for helping
RequestTimeoutException is thrown when server is not responding.
You should create you own checked exception, something like SessionTimeoutException and handle it in you client code. GWT knows how to handle (serialize) checked exceptions and pass them to your client code: http://code.google.com/webtoolkit/doc/latest/tutorial/RPC.html#exceptions
To handle this in application-wide way, you can hook into RPC mechanism, by creating you own generator for remote services: How to redirect to login page after session expire in GWT RPC call
The easiest way (without changing all existing code) would be to set a Timer to periodically check (every few minutes) the server session. When session times out show a modal DialogBox (preventing user input on other widgets) notifying user he/she needs to login again.
Related
In some request, I need to change this alert to be somewhere on the screen, so how I can disable the default behavior when failing the request the alert show up by abp.message.error and I need to disable it and use another way.
You can send all exception details to the client easily. There's a setting for this purpose.
...
using Abp.Web.Configuration;
...
public override void PreInitialize()
{
Configuration.Modules.AbpWebCommon().SendAllExceptionsToClients = true;
}
...
References:
Related Aspnet Boilerplate document
Throwing user friendly exception forum post
Related GitHub commit
Yet another related GitHub issue
Besides, you can disable exception handling for an application service or for an application service method. Just use [DontWrapResult] attribute for that.
public interface ITestAppService : IApplicationService
{
[DontWrapResult]
DoItOutput DoIt(DoItInput input);
}
See the related Aspnet Boilerplate docs
In our application which makes
use of JSF/PrimeFaces, Spring and Hibernate once a user logs in, we set a flag in the DB until the user logs out from the application or the session expires. The problem is, we need to clear this flag in the DB even when he simply closes the browser without proper logout. To acheieve this, I have already tried jquery $window.unload and $window.bind functions which actually invokes some JS function which is associated with <p:remoteCommand> which in turn invokes a managed bean method to clear the DB. However, I later came to know this is not reliable and while testing also we saw the event was not firing consistently. How can I achieve the DB cleanup anyway?
Listening on browser close is not reliable. You can use beforeunload event for that, but this is not supported on every webbrowser the world is aware of and even disableable/spoofable/hackable by the enduser. Then we're not talking about the race condition during firing the ajax request: would the ajax request arrive in its entirety right before the browser is closed? More than often this is not the case and the browser close wins over the ajax request.
Just listen server side on session expiration instead.
#WebListener
public class MyHttpSessionListener implements HttpSessionListener {
#Override
public void sessionCreated(HttpSessionEvent event) {
// NOOP.
}
#Override
public void sessionDestroyed(HttpSessionEvent event) {
HttpSession session = event.getSession();
// Do your job here.
// ...
}
}
Note that this is also invoked when you explicitly invoke ExternalContext#invalidateSession() (or HttpSession#invalidate()) during programmatic logout.
Is there any way to set a custom error page in IIS 7 without creating a web.config?
Unfortunately researching this particular topic has been very difficult because there are SO many articles on how to do it with a web.config. What I'm looking for is either buried beneath the 8 million results I don't want or it's not possible.
Yes, there is. It involves either subscribing to the Application_Error event in Global.asax or by writing a custom ErrorHandlerAttribute.
Darin already gave the correct answer, but I want to go into a little more depth.
In any ASP.NET application, given it is Web Forms, MVC, or raw ASP.NET, you can always use Application_Error Global.asax. If your ASP.NET application does not have a Global.asax, all you need to do is right-click your project in Solution Explorer, Add New Item, and choose Global Application Class. You should only have this option available if you don't already have one.
In your Global.asax, if you don't already see it, you can add Application_Error as shown below:
protected void Application_Error(object sender, EventArgs e) {
}
This will be called automatically by ASP.NET whenever there is an error. But as stated here, this is not perfect. Specifically:
An error handler that is defined in the Global.asax file will only
catch errors that occur during processing of requests by the ASP.NET
runtime. For example, it will catch the error if a user requests an
.aspx file that does not occur in your application. However, it does
not catch the error if a user requests a nonexistent .htm file. For
non-ASP.NET errors, you can create a custom handler in Internet
Information Services (IIS). The custom handler will also not be called
for server-level errors.
In Application_Error you can process the uncaught exception with Server.GetLastError(). This will provide you the Exception that was thrown, or null. I am not sure why this handler would be called if an exception didn't occur, but I believe that it is possible.
To redirect the user, use Response.Redirect(). Whatever you pass for the url is going to be sent directly to the browser without any further processing, so you can't use application-relative paths. To do that I would use this method in combination with VirtualPathUtility.ToAbsolute(). For example:
Response.Redirect( VirtualPathUtility.ToAbsolute( "~/Error.aspx" ) );
This redirect will be a 302 (temporary redirect) rather than a 301 (permanent), which is what you want in the case of handling errors. It's worth noting that this overload of Response.Redirect is the same as calling the overload Response.Redirect(url, endResponse: true). This method works by throwing an exception, which is not ideal in terms of performance. Instead, call Response.Redirect(url, false) immediately followed by Response.Complete​Request().
If you're using ASP.NET MVC, [HandleError] is also an option. Place this attribute on your Controller or on an Action within a controller. When this attribute is present, MVC will display the Error view, found in the ~/Views/Shared folder.
But you can make this even easier for yourself. You can automatically add this attribute to call Controllers in your project by creating a FilterConfig class in your project. Example:
public class FilterConfig {
public static void RegisterGlobalFilters(GlobalFilterCollection filters) {
filters.Add(new HandleErrorAttribute());
}
}
And then add FilterConfig.RegisterGlobalFilters( GlobalFilters.Filters ); to your Application_Start() in Global.asax.
You can read more about the HandleErrorAttribute at https://msdn.microsoft.com/en-us/library/system.web.mvc.handleerrorattribute(v=vs.118).aspx.
But as stated above, both of these methods will never cover absolutely all errors that can occur during the processing of your application. It's not possible to provide the best user experience for all possible errors without using Web.config or configuring IIS manually.
Let's say I have some ajax based component, whose handler in server throws for some reason an exception (e.g. programming error, can't access database). And basically server responds with internal server error or some such. How can I catch this situation in browser and display for examplen an error message somewhere.
When user clicks this link, the server will show an error page and the browser should detect based on http status code that something went wrong and somehow to react to it.
new AjaxLink<Link>("link") {
public void onClick(AjaxRequestTarget target) {
throw new RuntimeException();
}
}
See org.apache.wicket.settings.IExceptionSettings#getAjaxErrorHandlingStrategy.
There is an example of this at http://www.wicket-library.com/wicket-examples/ajax/links (failure and exception links).
Normally, Wicket Ajax classes like AjaxFallbackLink for example, have a method
updateAjaxAttributes(AjaxRequestAttributes attributes)
where you can register error handlers, that execute javascript within the browser.
Override this method, create an AjaxCallListener and call
AjaxCallListener listener = new AjaxCallListener();
listener.onFailure(ADD_JAVASCRIPT_TO_EXECUTE_HERE);
attributes.getAjaxCallListeners().add(listener);
see the documentation of
org.apache.wicket.ajax.attributes.AjaxCallListener.getFailureHandler(Component component)
Even though NavigationService.CanGoBack returns True, NavigationService.GoBack() throws me these exceptions :
A first chance exception of type 'System.ArgumentException' occurred in System.Windows.dll
A first chance exception of type 'System.Reflection.TargetInvocationException' occurred in
This happens systematically on two case, while the third works fine :
Crashes if I call NavigationService.GoBack() in OnNavigatedTo()
Crashes If I call NavigationService.GoBack() as a result of WebException thrown in my HTTPWebRequest when Internet is not available [1]
Works fine if Internet is available and I call NavigationService.GoBack() when my HTTPWebRequest got results, parsed them, and displayed them.
My theory is that I can't call GoBack() too soon after navigating from a page to another... My question : How can I programatically go back up the navigation stack when an HTTPWebRequest fails to load ?
Edit : I've decided to do it another way, but I think my problems might be due to navigation animations and the Windows Phone C# Toolkit (I use Feb 2011 edition)
[1] Details of my code on case 2 :
I have a simple HTTPWebRequest. My callback does this, and my app crashes when in Airplane Mode. The line NavigationService.GoBack() is responsible, even though NavigationService.CanGoBack returns true.
try
{
response = request.EndGetResponse(result);
}
catch (WebException)
{
Dispatcher.BeginInvoke(() =>
{
NavigationService.GoBack();
});
}
I tried using Deployment.Current.Dispatcher.BeginInvoke() also.
You could try using WebClient client = new WebClient();, then use client.DownloadStringAsync(new Uri("request_url")); to make your request and subscribe to the client.DownloadStringCompleted event to receive your data when the request is completed. After parsing the data, in the event handler you can then call NavigationService.GoBack(); or go to whichever page you want.
Also, if you try to do something in the OnNavigatedTo event and run into trouble you could try using the OnNavigatingFrom instead (on the previous page ofc), cancel the navigation e.Cancel = true;, do your thing as in make the request and stuff, then get the application frame and navigate to e.Uri (basically continuing the navigation you previously cancelled).
Altho this second might represent a solution as well, I think the first one is better as it does all the work async thus not blocking your UI thread. This is what I generally use in my apps. Hope it helps.