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.
Related
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.
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.
I am devolping a web application.the problem is that i am using a login control (not a .NET control) which is a part of master page and is acessible from all pages. if user log In from a page the login control updates itself and displlay some statistics of logged In user but the specific page does not reload. (some options on page are visible only to authenticated users, so that after login, page should be reloaded to display such options)
after logIn methoed I wrote
Reponse.Redirect(Request.Url.AbsoluteUri)
after this the browser response the "Page cannot be displayed"
It would be of great help to me.
Many Thanks, Regards. AZHAR
From you description it is not clear what happens, but with high possibility you get infinite loop, when page is redirected to itself again and again.
Most obvious problem that you place redirect code in Page_Load,
as possible resolution:
Place Reponse.Redirect(Request.Url.AbsoluteUri) to OnLogin event of your login control
if you anyway want use Page_Load, at least add following check:
if(IsPostBack)
Reponse.Redirect(Request.Url.AbsoluteUri)
But last case is very bad style because may have lot of side effects.
Make sure your redirect is not causing a loop. Check Page.IsPostBack
Be aware that POST variables are lost during this operation.
Another thing that you should look at is the roles that you allow in the folder (in the web.config file in the folder).
I accidentally misspelt a role name and it kept redirecting my users to the login page.
Hi I'm getting a strange problem while inserting records into database.
In my button click event I'm trying to insert some values into my database it is working fine. Once insertion is completed... again if I press F5 or refresh the browser a new row is getting inserting with the previous values in the table.
Why it is happening?
Thank you
When you click the button, it sends a POST request to the server, and the updated page is sent back as the response. In order to refresh that page, the same POST must be made again, and the server interprets this as another button click.
Most Web browsers give a warning in this situation, saying that refreshing the page may repeat any action that was just performed (in your case, inserting a row in the database). But if you want to prevent this from happening at all, the best way is probably to respond to the POST request with a redirect. In ASP.NET with C#, the way to do this is:
Response.Redirect(url);
Redirecting back to the same page is fine, or you could also redirect to a different page. When the browser receives this redirect, it will issue a GET request for the specified page. Then if you refresh, no action will be taken.
you need to handle you page refresh event handler and check.
Simply because refresh caused another postback which re-do the insertion operation.
You might want to perform a redirect to the same page to prevent that. There are some other means to handle this issue as well.
It's happening because you're requesting the page again, using the same POST parameters that were used to request it the first time.
To fix it: either check for a page refresh in your code and don't do the insert in that event, or set a cookie the first time, and then don't do the insert again if the cookie is there. The cookie could either have a fixed duration (say 30 minutes), or it could be a session cookie, which would last until the users closes the browser.
Check the solution in the following link
http://aspalliance.com/687_Preventing_Duplicate_Record_Insertion_on_Page_Refresh.4