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
Related
How using MVC C# (without the use of JS or JQuery) can I send a user to /home/stasis which will load with a loader image (already implemented using css), and then send them to the final url (which has a really long load time, and users end up clicking multiple times - not helping themselves)
The problem is that the use of JS and JQuery won't work, as this needs to work as an in-app webview as well (which doesn't support either JS or JQuery). So I go to /home/index click on a link to take me to /home/stasis which will load, then automatically begin loading the final url lets say google.com for example.
Without javascript, we have to hope that the browser and server will do the right thing:
The browser will display the entity content when the server returns a 307 redirect.
The server will not return partial entity while the long-running request is pending. In other words. The long-running request should return all its entity data in the final second the request.
The browser won't clear the screen until the first bytes of the next entity have arrived.
Assuming the browser and server behave like this, MVC doesn't offer an easy way to do it. You need to:
Create a new class derived from ActionResult.
In your ActionResult's ExecuteResult() method, write output to ControllerContext.HttpContext.Response. Set the response code to 307, set the RedirectLocation, and write whatever content you want to display to the OutputStream.
I have below scenarios.
My controller check that user has proper rights and then redirect him on proper action.
All action have ChildActionOnly attribute, because these action can't be invoke directly by URL. (only user with proper rights can call invoke action)
Each action return View with special button. This button can call critical action.
In the picture I illustrate it (link is below)
http://s23.postimg.org/fmndgt5p7/mvc.jpg
My question is how can I call DeleteData Action after click a special button? and I don't want have ability to call DeleteData Action directly via URL and I don't want check user rights second time.
I don't want have ability to call DeleteData Action directly via URL
So, you want to send brain waves to the server? How will the server ever get the message to do the delete operation?
I don't want check user rights second time.
The fact of the matter is you are making another round trip to the server, so you must check user rights again, at least if you want to have any measure of security.
MVC doesn't provide any magic. It still depends on the stateless HTTP protocol to function. So everything that it does must communicate over that protocol. You can get fancy and make calls via AJAX so there aren't so many page loads, but every interaction with the server must make a complete round trip (request and response) to the server. There is no way to avoid that.
Sounds like you are already hiding the button if they do not have permissions to delete but you would need to check the permission again when making the delete request since it would be a new request.
Delete actions should be restricted to POST only.
Why shouldn't data be modified on an HTTP GET request?
You would need to expose the delete action via a URL that only responds to POST and it would need to verify permissions again since it's a new request to the server.
It could be done with an ajax request or (Post/Redirect/Get)
http://en.wikipedia.org/wiki/Post/Redirect/Get
A (Post/Redirect/Get) is shown below and prevents the user from clicking refresh and submitting the request again and it will not be in the browsers back history.
[HttpPost]
public ActionResult DeleteSomething(int entityId){
//Delete object then redirect back to original page
return RedirectToAction("Index")
}
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 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.