I have a user complaining about frequent timeouts in my Intranet web page. While looking for a solution I found this post:
http://forums.asp.net/t/152925.aspx?PageIndex=1
Where a poster recommends intercepting the redirect to the login page, submit the data to the database, then either reauthorize the user (without their knowledge) or redirect to login page. My goal is to avoid the situation where a user enters data in a form, walks away, then comes back to submit it, only to be told they have to login again (which is fine, if the data remained and the user was sent right back to the original webform).
Does anyone know how I can accomplish this on specific pages in my app (not all of them)?
It's not necessarily trivial, but you can add an ajax component that makes occasional calls to a page to keep the session alive. This way you could lengthen the session for any particular page you need to without affecting the application as a whole.
EDIT
If you really want to let the session expire, but keep the form data, you can implement
protected void Application_PostAuthenticateRequest (object sender, EventArgs e)
event handler in your global.asax.cs file. This is called before the forms authentication redirect happens, and the form data is available to your application at this point, so you can persist it to whatever medium is necessary until your user is authenticated again. In addition, if you check the
((HttpApplication)sender).Request.Path
property it will tell you which page was requested.
Well, the easy way it to drastically lengthen the timeout specified in the web.config file.
I'm going to try using cookies to preserve the data. My plan is to update the user's cookie after each control is changed, then add logic to the page_load property of the page to populate the form data after the user is logged back in.
Related
I've got an Asp.net MVC action that creates user account(after input validation). And a View containing registration form that invokes this action. While action validates input, user is left with webbrowser waiting for server response and click submit button a few more times. This creates several accounts. Is there a way to prvent user from form resubmition without javascript. I cannot use javascript in this project it is intended for non javascript browsers. Or can you suggest(server) other solution?
EDIT:
This form request use POST method
JavaScript is not allowed because this Web Application is aimed for special web browsers for people with disabilities that do not support javascript
You have to handle the situation on the server-side then, there's no way around that.
There are 3 options that come to my mind atm:
create a cookie and for each submit check if it exists
similar, but using a session object
before creating a new account, always check if the user exists in the database. THIS should be a no-brainer anyway!
You can add a unique hidden token as part of the form. This token can also be saved as part of the session on the server.
When the user posts the form on the first action, the token is validated and a flag set to indicate the request is being processed. The action processed and results presented. If, while awaiting results, the user attempts to repost the request, the token validation fails as the request is still being processed.
On a side node, the main reason people continuously click is that there is no feed back on whether the request was received by the server or not. To this affect, it might be better to redirect the user to an interim page that shows the request is being processed. Which in conjunction with the above can be used to show the request progress and redirect to the appropriate page when completed.
Of-course, you should also consider making the process a bit lighter. So, that the system can respond quickly to input rather than making the user wait.
Is it a requirement to use MVC? I think you can accomplish something similar using WebForms. When the user submit the request, in the code behind you can disabled the submit button like this:
btnSubmit.Enabled = false;
But if MVC is a must be, #walther answer would be correct
I am revamping the authentication system of an ASP.net webforms application (which relies on Forms.Authentication) to limit each user to a single browser session. To support this, I have created a new IHttpModule which uses an application variable to maintain a dictionary that maps userId to sessions, patterned after this article.
All of that is working great, but there is one more component that we want to add: an ok/cancel dialog displayed after login is successful, warning the user that their first session will be closed if they proceed. If they choose to cancel, then we need to interrupt the login process without sending the user to the returnUrl set via Forms.Authentication.
So far, my attempts have been around adding this to the loggedIn event, where the sessionId is captured and compared, however my attempts at stopping things once this point occurs have not worked out -- the user is redirected past my confirm dialog without anything actually firing.
Thus the question: How can I insert a confirm dialog to the login process of Authentication.Forms?
Something you might try - make the form auth an ajax call, then handle your dialog on the client side. So, for example, intercept the login form post using jquery, do an ajax post of the login form, get json or something else back, and then pop the dialog with a redirect on the client side.
Currently, when the using is logged in (using the built in forms authentication) and they let their session timeout, they loose all data when they submit a form. How do I make it so that the viewstate data is resubmitted AFTER logging back in? Example, if they were writing an email and it expires, how do I make it send after they relogin instead of loosing all their data? I don't want a solution that extends the session on these pages please.
viewstate will only work in postback-scenarios,you will lose it if you redirect.So i think you use session for your problem.
I agree with Shree..
You could use a timer of sorts and either do a save to the DB, Session, or Cookie w/ the temp date entered so far.
Also, what I have done on some applications, is before the session will time out give the user a warning popup to "Continue" the session. This takes a little more work..
If you want to preserve the state of the form along with all form data, you don't want automatic redirects to the login page, which means that you need some sort of an "in place" authentication. You may consider intercepting the postback, i.e. adding your own handler to the form submit event, and issuing an AJAX callback to check your session state. If the session is valid, just proceed with the postback, otherwise display a login page in a popup or a modal dialog. The user will be able to resubmit the form after logging in.
I think your problem is not on ViewState, simple solution is save the email and action into local storage[HTML5], when user re-logs on, check the previous action and email, then you can submit email automatically. All browsers except IE6/7 already support local storage now.
I have a user registration page, after entering all the details and successful account creation, I want to stay in the same page, but all the user entered details should be cleared
but if the registration is unsuccessful then all the user entered details should be retained.
which is the right way of achieving this?
is clearing all the values manually in code, the only way?
Viewstate is maintained during postbacks. So, you can do a redirect to the same url if the registration is successful. Make sure that your databindings check for IsPostback.
The state for the textboxes is maintained during postback, so you could clear them manually.
However Ingenu's answer suggest to use whats called the PRG-pattern which is an even better fit. In your case it goes like this:
On succesfull creation of an account, you should issue a redirect to the same page. The redirect will call your registration page as a GET request again, and clear all textboxes.
If the create is unsuccessfull, you should NOT redirect. So that the user stays on the same page with the textboxes still filled.
I'm interested in disallowing the following after logout:
-- no back button
-- no direct access to pages via URL - for example: if the user logs out then they should not be allowed to see a cached page using some URL (e.g., replacing the URL with a valid URL in the site http://mysite.com/Gotothispage.aspx)
I've seen similar questions like this one: How to disable the back button in browser when user logout in asp.net c#
I know that I can set no cache on the master page, but then I lose the ability to use the back button when the user is actually logged in. Am I correct in this understanding?
A page is either cacheable or it isn't, the browser has no idea if you are logged in or not. You can't somehow retrospectively expire objects already cached by the browser.
Then I lose the ability to use the
back button when the user is actually
logged in. Am I correct in this
understanding?
Not entirely - you'll have problems using the back button on pages that are submitted using POST, but not GET.
A simple example would be to imagine an ASP.NET page with a paged Gridview - the user clicks pages 1,2,3,4,5, etc to navigate the grid.
Using POST, every time the user clicks another page in the grid, it will cause a postback to the same page. A page expired error will appear if the user clicks back after doing this.
Using GET, every time the user clicks another page in the grid, it will redirect them to the same page using a querystring (ie, Grid.aspx?Page=2). In this case, the user can click back, and it will take them to the previous page without any problems.
Pages should already be disabled after logging out, if your security is setup correctly.
If you have a master page or basepage class specifically for users that are logged in, you should check if they have a sessionId that you set when they logged in.
If they don't, redirect them to another page.
Users may see a cached version of a page, but can't do anything to it.
In my basepage class for members, i check if they are logged in on the OnInit event:
protected override void OnInit(EventArgs e)
{
base.OnInit(e);
if (!IsLoggedIn)
{
Response.Redirect("default.aspx");
}
}
Edit:
What some sites do is..after you log the person off, they redirect you to a temporary purgatory page that says it is logging you off. This purgatory page will have caching turned off, and has a meta-refresh tag that takes you to your destination page.
So when the user clicks on the back button, it takes them to the purgatory page which then directs them right back to where they were.
Gmail does this, but sometimes it's so fast you can't tell.