I have a fairly complex form (user control actually) with one textbox control on it that needs to NOT post back. Is there a way to remove a control from the post? Yes, this textbox is editable.
More info: This is for a credit card processing form, so the "final" submit will post to another site's page. However, prior to this there is plenty of server-side processing that goes on. I know that I can move the the credit card number text box to another page - but this requirement came very late and I'll trying to not have to re-work a lot of things.
The easiest way would be to use an html input as opposed to an ASP TextBox. These are not accessible from code if runat="server" is not set on them.
Or use the viewstate property (http://msdn.microsoft.com/en-us/library/system.web.ui.control.enableviewstate.aspx)
So the situation is that you have a form that is rendered in the user's browser with an action pointing to a different site and you need to make sure that one of the form fields will not be sent when the form is submitted.
Sounds to me like you cannot in that case make absolutely sure that the value is not posted. There are many different possible ways to solve this using javascript (disable input, clear value, etc before submit) but if scripting is turned off I think you're out of luck.
But since you can prepare for sending the form to the other server (change action on form or enable button with PostBackUrl), I guess you could also then set the Enabled property on the textbox to false. That would mean that it can no longer be edited on the final page beforr posting to the other server. Or you could hide the textbox a (so it's not renered at all) and show the field as a label or literal instead.
But even then you still have to somehow make sure the secret value is not included in the viewstate of the form. Which it will be in case you use a label or literal. And also for a textbox that was disabled or hidden on the last postback. Normally the viewstate is just a base64 encoded string so it would be trivial to find the credit card number from there. You could probably fix this by turning off viewstate for the control in question (or even for the whole page) in the last post back to your page before setting the form up for posting to the other server.
If you cannot tell for sure which will be the last postback to your server, then I think you're out of luck without more significant changes. Sorry to be a downer. Some seemingly trivial things are just hard with Asp.Net web forms.
Maybe you could add a separate page that you populate with just the data that you need to send to the other server and have that a sort of "Confirmation page". In that page you could turn off viewstate, show all the data summarized (using labels and literals etc) and the actual data to post could be included in the form as hidden fields. Then that form would post to the other server when the user "Confirms".
Related
I am trying to create a registration page for my company, and so I put down Password and "Repeat Password" textboxes on my form, along with a CompareValidator. It appears to work just fine, whenever users go into both fields, type data and click the Register/Submit button.
However, I've noticed an issue where my Firefox browser during testing saves a password that I entered. After it's saved the password, if I then go back to the page "fresh", it shows the password already filled in the Password field (though not in the "Repeat Password" field for some reason).
Anyways, if I then populate the e-mail address, I can then click the Register/Submit button with no issues at all!
The most concerning thing is, when I debug into the CodeBehind and even force a validation by triggering both the control's Validate method and the Page's Validate method manually, it still somehow PASSES the validation even though, as you can see in the QuickWatches in my screenshot below, the fields have two different values!
Have I found a bug that I should report to Microsoft, or is it possible that I did something wrong in setting this all up? All I did was plop the CompareValidator on the form, and set the "ControlToCompare" to "txtUserPass" and the "ControlToValidate" to "txtRepeatPass", and the Operation is set to "Equal".
Am I perhaps doing something wrong here, or have I found a genuine bug caused by browsers storing passwords?
As specified on the documentation, the CompareValidator does not trigger for empty values:
If the input control is empty, no validation functions are called and validation succeeds.
Use a RequiredFieldValidator control to require the user to enter data in the input control.
You need to combine the CompareValidator with a RequiredFieldValidator.
I have a web page with multiple separate tabs, all exist in DOM, switching between them is entirely client-side. Each tab contains an ajax form for editing data of a selected app user. For eg. first tab lets you edit name, surname, ..., second tab lets you edit address. Each tab has a save button and each time only properties of current tab are propagated to the DB. All works well :)
BUT, of course, each tab needs PK of the user (user.Id) in question. Its passed to controller via a hidden field
<input type="hidden" asp-for="Id" />, so HTML DOM contains more than one element with the same id and browsers complain.
I know that I could manually set the name/id of these input fields, and manually map them on the controller side, but model binder could do this for me, its nice and clean.
public async Task<IActionResult> EditGeneralData([Bind(GeneralDataBindFieldNames)]AppUser appUser)
Is there a nice & simple way to achieve this? Should I simply forget about the browser warning as I will be careful when/if using getElementById? Whats your take on this?
Yeah... not really the answer I was looking for, but it should suffice. It turns up that the content of these tabs is related to one another. So all the tabs cannot exist in the DOM at the same time, and switching between them cannot be entirely client side.
Now, tab click loads tab content on demand, so theres no multiple input fields in the DOM anymore. Only one tab at a time means only one input field at a time :)
I have an ASP.NET page where at the top of the page is a search box. There are 2 text boxes - one is an autocomplete extender for the Name on a database, and one is just inputting the ID.
The page features DetailsViews and GridViews primarily, and even when no account has been searched for, these display blank data which is not ideal. I sort of fixed this by using if (IsPostBack), encasing the elements in a placeholder and setting it to visible only if the page ispostback. But this doesn't cover if the user types in an incorrect ID.
Also, some accounts have huge amounts of data inside the GridView's. I had an issue where because I have no way of detecting when a data source's rows has changed, I end up binding whenever the page loads (Page_Load method). I've come to realise this is simply very bad - there are lots of times when the user can click various things in the page and have the page postback, and it takes an eternity to load each time I click something for accounts with lots of data.
Anyway, my question is essentially two-fold but I have a feeling the solution will be similar:
1: How can I detect when there are no accounts returned when searching, and disable the Grids/Detailsviews and show an error message?
2: How can I figure out when the user searches for another account and only rebind the grids after that has happened?
Thanks
This method is very ugly but it'll get the work done.
1) To Check whether there are no records; after the AutoComplete Extenders Webservice is called if no record is returned put some value in Session like
Session["NoData"]=true;
if Records are found then;
Session["NoData"]=false;
after the webservice is called do ajax request to check that session & on the basis of value do what you want.
2) You can achieve this also by following the above option.
I'm trying to persist the contents of a textbox through a postback, and I've exhausted all of my effort but can't get it working right.
What should happen is:
User selects a radiobutton
Depending which button was
selection, a usercontrol is loaded
to specify some data and a viewstate
to say which enum type it's
equivalent to.
When they click
save, if the UserControl is just a
textbox input - the simplest), the
contents are read and saved, then
saved to the database with the
format(the radiobutton choice) so
they can be deserialized again
later.
The page posts back, and
the value and format are read from
the database, then the right control
is loaded.
The problem is - the first time the page posts back, it works. Every other postback it resets to the default value of the textbox.
I have a very similar setup elsewhere, so I'm thinking it might be a minor thing I'd never think of. There's a lot of code, so it might be easier to talk about what to do (load the dynamic control, populate the values etc) rather than how to do it.
There was actually a bug in my original code which meant it would never have in the way I was using the modified version. Apparently state is restored in Page_Load, so any controls need to be initialized by to have their values restored.
Creating the control in Page_PreLoad, then populating it after Page_Load solved the problem.
I have several "ASP:TextBox" controls on a form (about 20).
When the form loads, the text boxes are populated from a database.
The user can change the populated values, and when they submit the form, I take the values posted to the server and conditionally save them (determined by some business logic).
All but 1 of the text boxes work as intended.
The odd box out, upon postback, does not contain the updated value that the user typed into the box.
When debugging the application, it is clear that myTextBox.Text reflects the old, pre-populated value, not the new, user-supplied value.
Every other box properly shows their respective user-supplied values.
I did find a workaround.
My solution was to basically extract the text box's value out of the Request.Form object: Request.Form[myTextBox.UniqueID], which does contain the user-supplied value.
What could be going on, here?
As I mentioned, the other text boxes receive the user-supplied values just fine, and this particular problematic text box doesn't have any logic associated to it -- it just takes the value and saves it.
The main difference between this text box and the others is that this is a multi-line box (for inputting notes), which I believe is rendered as an HTML "textarea" tag instead of an "input" tag in ASP.NET.
Are you initially loading the data only when !Page.IsPostBack? Also, is view state enabled for the text box?
this happens to me all the time.
protected void Page_Load(object sender, EventArgs e)
{
if (!Page.IsPostBack)
{
// populate text boxes from database
}
}
I would second Jonathan's response I would check your databinding settings.
If you do not need ViewState for the textboxes (i.e. no postback occurs until form submit) then you should disable it.
It sounds like you are not having problems saving the data (since you said you have managed to get the control to read the correct data back). Therefore, I would say the problem loads in your databinding code.
Remember the order of the page lifecycle, and where you are databinding your form.
PreInit
Init
Load
Your Control Event Handler
If you are reading the value in the Control Event handler, yet databinding in Init or Load, you'll have the old value.
The trick is to always databind in the correct event, or check for postback and don't databind then.
Are you initially loading the data only when !Page.IsPostBack? Also, is view state enabled for the text box?
I had almost forgotten to check the ViewState, but ended up remembering to verify that it wasn't disabled before making my post here on SO. I even set EnableViewState="true" to make sure.
I did find the solution, and it coincided with most of the answers here. The form was indeed loading its data more than once (which is intentional behavior). I implemented some special code for this field, and all is well.
Thanks for your replies, all!