I have this flow but don't know how to deal with it. I think "Forward" button should use GET because it is safe and idempotent but the textarea contains a large amount of text so I think can't put in in URI. I changed to POST.
The OK button on confirmCreateAlbum surely POST.
The flow says When click "Cancel" on confirmCreateAlbum, it returns to nameAlbum with the fields were filled for editing. I put OK button in a form with action="confirmCreateAlbum". The problem is how to back to nameAlbum?
Note: nameAlbum will show errors if the required fields are not provided.
Although there is no specific length limitation for GET requests in the RFC, browsers impose limits on URI lengths. There are also considerations with some server implementations.
You said the textarea "contains a large amount of text" so it is recommended to use POST in this situation because it won't be subjected to URI limitations.
On to your original question, "The problem is how to back to nameAlbum?"
In your confirmCreateAlbum form, you can actually use two separate forms. A form for the "OK" which the action calls your specified script for confirming, and a form for the "Cancel" which has an action calling your nameAlbum form.
Anther option is getting clever with hidden input fields and passing the data around but that can get messy.
Personally, if it were up to me, I'd be using jQuery/Javascript for confirming form submission. It's a simple client side solution that doesn't require you to leave your original form if "Cancel" is pressed. But that's just me...
I don't think post or get is the problem here.
You can create two form: one with the ok button, post/get to further step; one with the cancel button, post/get to nameAlbum.
Or you can create one form with two button with same name and two different value and post/get to some page. On that page you check the value and redirect to further step or to nameAlbum.
After posting to confirmCreateAlbum, where do you store the data from the textarea?
I assume you store it in the session so in nameAlbum you can fill the data (if there's any) to the field.
And if you can use javascript, you can just handler the next, cancel button with some javascript and avoid some round trip.
Related
Such a button is not rendered to the browser, so is there any way a malicious user would be able to trigger the action defined by the invisible button? e.g. with a JavaScript call to WebForm_DoPostBackWithOptions? Would ASP.NET accept a POST that appeared to be triggered by this button, even though it wasn't rendered?
Short answer yes.
It is always up to you (the developer) to ensure data received from user input (in this case a post) is valid. Having said that the asp.net framework will do a lot of verification for you, such as "suspicious looking post values".
It is possible to construct a post to a web endpoint, even if the page you display does not have a submit button.
Edit
This would be an example of security through obscurity and is generally not a best practice. Asp.Net "submit" buttons modify a hidden form field called __EVENTTARGET. The asp.net handlers will inspect this field when determining a button click "event". This value can be spoofed if the attacker knew the name of the event target.
Hiding/showing UI elements are good for improving the user experience, but you should always validate (on the server) user input before performing any business actions.
I don't believe it would, if it's not rendered it shouldn't accept the postback. .net uses hidden fields on the page to know which controls were on the page and can verify that during postback, so it knows what triggered the post back. if the control was not there to begin with it shouldn't accept it.
Yes, this is definitely possible. ASP.NET accepts all POST values for controls defined on the page, visible or not. Beware too of i.e. textfields that are set to "read-only". Don't use readonlyControl.Text after the post, and trust that it has the same value as it had the last time you set it.
Take a look at what is posted when you perform a submit with ASP.NET with i.e. Chrome Developer tools, Fiddler, etc, and you should be able to figure out how to add your own value to an "invisible" text field.
I've been playing around with different aspects of MVC for some time now, and I've reached a situation where I'm not sure what would be the best way to solve a problem. I'm hoping that the SO community will help me out here :P
I've seen a number of examples of Ajax.BeginForm on the internet, and it seems like a very nifty idea. E.g. you have a dropdown where you select a customer - and on selecting one it will load this client's details in some placeholder on the page. This works perfectly fine.
But what to do if you want to tie in some validation in the box?
Just hypothetically, imagine an article page, and user comments in the bottom. Below the comments area there's an ajax-y "Add comment" box. When a user adds a comment, it will appear in the comments area, below the last comment there.
If I set the Ajax.BeginForm to Append the result of the call to the Comments area, it will work fine. But what if the data posted is not valid? Instead of appending a "successful" comment to the comments area I have to show the user validation errors.
At this point I decided that the area INSIDE the Ajax.BeginForm will be inside a partial, and the form's submits will return this partial. Validation works fine. On each submit we reload the contents inside the form element. But how to add the successful comment to the top?
Other things to consider: The comment form also has a "Preview" button. When the user clicks on Preview, I should load the rendered comment into a preview box. This will probably be inside the form area as well.
I was thinking of using Json results instead. When the user submits the form, the server code will generate a Json object with a Success value, and html rendered partials as some properties. Something like
{ "success": true, "form": "<html form data>", "comment": "successful comment html to inject into the page" }
This would be a perfect solution, except there's no way in MVC to render a partial into a string, inside the controller (separation of context, remember?).
UPD: Seems like nobody knows an answer to this one.. Does it mean that there's no way to do this, or you just don't know, guys?
Here is an example how to post using jQuery and how to deal with error in the validation.
http://jvance.com/blog/2010/02/20/MakingAnAjaxFormWithJQueryInASPdotNETMVC.xhtml
After giving it more consideration + getting more experience with MVC, I decided to break down the problem, and came to the following conclusion. Not sure if anyone will find it useful
With an Ajax.BeginForm that requires field validation, the return from the submit should return the form's html. This way, if the validation failed- the response will contain the error messages, and the interface will look seamless.
The result will also most likely contain the whole form, including the declaration of it.
The preview in this case is a simple issue. When the user clicks on the preview button, the form can be posted, and the result will contain the populated form + the preview box. Alternatively, the Preview button can be an Ajax.LinkButton that will serialize the form, post the data to the server, that will render it into a comment. The js on the client side will then put this preview in the required container.
On successful submit, there are a couple options, depending on the requirements and the layout.
a) The result of the form submit can return the comment + the blank form (ready for a new comment)
e.g. when the comment form is below all the comments, this will look as if the comment has been added to the bottom of the form
b) The result can contain the blank form + a small js script that will update the comments area / load the latest comment to the page
c) It can also force a refresh of the parent page, to ensure the newly posted comment will be immediately visible to the user.
Basically, this choice depends on the requirements of the particular case.
I have the following problem
I have a web framework built with classic asp that saves the page state in hidden textboxes, and then issues a submit to itself.
Before submitting, we have a javascript functions that saves the action in a hidden "action" input, and then performs the submit.
The page loads the state from those hidden texts, reads the action issued, reads extra parameters, like the id of the record to edit, and then builds the page accordingly.
I'd like to make a url link to automatically start the page with "edit" action on a "x" id.
So I was thinking about building the following url, for example
http://myapp/user?action=edit&id=23
the problem is that when the page auto-submits, que url string keeps the parameters.
I'd like to achieve the following:
when the user clicks on
http://myapp/user?action=edit&id=23
my page should receive the posted values action=edit and id=23
but the url should be just http://myapp/user
and both parameters should be kept in the hidden texts... (I wonder if I make myself clear...)
thanks a lot
saludos
sas
ps: I have a couple of ideas about how to solve it, but I'll post them as answers...
The first solution that came to my mind was to save the values in the session, issue a redirect without the parameters, and then load the parameters and remove them from the session...
the other solution, and the easiest one to implement, is that whenever I read parameters I first read them from the querystring (request.queryString) and then overwerite them from the posted values (request.form)
that way I wouldn't care if the parameters from the querystring keep being sent, the only problem left would be the annoying url...
I have a webservice that I need called, the result of which determines whether or not the user is allowed to submit the form.
Since this call is from javascript and not from code behind is it not reliable? Is there any way the user can get around the check -- by either going in with firebug and enabling the submit button, somehow making the method give a different result than was actually returned by the webservice, any other ways of being able to get around it?
Basically is there any way to call a webservice from javascript and have it's result determine whether or not a form can be submitted, and actually prevent the user from submitting the form at all? -- whether or not they have firebug, etc...
No, not possible.
Just to name a few possible reasons:
what if javascript is disabled?
what if the user submits the raw POST (using libcurl, for example)?
what if the browser, that the user is using interprets javascript in a way, different from your expectations (think, portable devices)?
Javascript validation is there for your users' convenience only and should never ever be used as a means of providing security.
You can never prevent the user from making an HTTP request that mimics submission of the form. While disabling the form via Javascript prevents submission for 95% of the users who both have Javascript enabled and don't want to circumvent your access control, anyone who understands HTTP can make the call and you are correct in showing that anyone with Firebug can do it in a matter of seconds.
Javascript isn't reliable for preventing anything. It shouldn't be seen as a security-wall, as it's too easily disassembled with things like firebug, iedevelopertoolbar, and many other browser toys.
Even if you could prevent them from submitting your form on your page, nothing stops them from creating a brand new form, on their own page, and point it toward the action of your form. Thus they're removing themselves from your "secure" environment, and instead chosing to play in their own.
Your suspicion is correct; the user can easily get around any possible Javascript validation.
You will need to use server-side code.
No, it is not reliable. Try disabling Javascript in your browser to see for yourself how easily you can get around it.
The user could simply disable javascript in their browser, or use something like NoScript. The best you could do is to try setting the form action itself in the return from the Ajax request, that way the form, as loaded, won't submit (except to itself). This will probably stop casual users but would be no impediment to a slightly more determined (or just bored and tech savvy) user. You will need to check on the server side whatever you do.
In general, no. You can make the form hard to submit without going through Javascript. Make the submit button not an actual submit button (<input type="submit">), but a pushbutton (<input type="button">) that submits the form in its onClick handler.
As everyone else said, no you can't do it. The only real solution is to have the web service return some dynamic value which the Javascript inserts in a hidden form input. Then whatever server-side code processes the form submission should reject the request if that value is not present.
I want to redirect the user to another page to fill out a captcha but i would like to keep the post data, and if the captcha pass to send it 'back' and complete the previous page action.
When/if the user succeeds i like to add an captchaPass=true and would like access the post data and continue processing. Right now i am using redirects but ATM i am not required to use it.
Is it possible to carry the post data? keep in mind i may the user access multiple pages so separating data and not having a mixup is necessary.
One idea is to get and save all posted data [1] on the captcha page, and then recreate a middle white page with this form data and automatically make a new post to the previous page.
Can this work with out any issues with hash checks and security ?
Is there a better idea with out this white redirect page ?
[1] One other issue here, how to send this posted data with the redirect ? and not change the url - or make it too big to accept it. Keep in mine that a server transfer may not good idea because is complicate the thinks on captach post back.
Update 1
The basic idea here is how some one capture the full post back of a page, show a different one page and then send the post back data to the original first one.
The reason is to stop a bad user, or an attacker bot program that try to bring down the pages/server by making many post back from different pages in short time. All that happens with out javascript, and most attackers use custom made programs that just make post of data to all page together try to bring down the system.
For example, if a page have a search box, is very easy for most of the the site to bring them down by start making hundred of random search with wildcard (called and Dos Attacks using SQL wildcards) and make the sql server and the computer spend his time and cpu to search and search thinks. So to prevent an attack like this you need to recognize multiple post backs from the same computer, and then the next step is to redirect him to a captcha page to block him out in case that is a computer program.
Other example, many page have email submit, very easy you can submit hundred times the email of his and full his mail box in no time with hundred of emails, or on a store to place all items on the cart again and again and full the database with stuff like that.
So ajax and javascript is not working in this case, and we need a way to redirect him after the post back to a page that can check if is a real user or an attacker and stop him - but if is a real user must return back to his normal action.
Update 2
This all must be done in a general way, eg on BasePage, or on Global.asax or somewhere that is independed from the content of any page. Because we try to prevent a DoS attack, or multiple submit anywhere on any random place of any random page.
Yes I know how you can place a captcha on the contact page, but this is not what this question was first asked for - this questions asked how can carry post data to one different page, keep them there and then resend them back to the original one.
The obvious solution is to read all post back, and save them on the form, and then read them back and make on fly a form only with that data and make the post back. Here I am asking if there are any other better than this solution.
Other Applications
There is also the case that a user is inside a page that request authentication, but the authentication ticket has expired, and the user make post back. In this case we need to keep somewhere all the posted back data, to proceed with the login page, and resend them back to the first page that request the authentication.
Sure, just write the form data out to the captcha page in hidden elements with the additional captcha fields added to the form. Have your submit action post the whole thing back to the original. Using ASP.NET it's probably easier to have the captcha written to the same page with the form fields hidden, but you can do cross-page postbacks as I've described above.
Cross Page Posting might help you.
Why not implement the CAPTCHA with AJAX? Load the captcha object and form with Javascript in a div perhaps displayed lightbox style, accept the user input and post it to your server for validation, hence continue with the users post request or keep them there until they get it right (or cancel).
A more specific situation example:
Give the form submittal button an onClientClick value of some Javascript function. This function decides if this particular form needs a CAPTCHA. If it does it loads an interface for taking the CAPTCHA (which you'd need to do with some server-side code) and inserts the CAPTCHA's input element to the form that the user clicked to submit.
Once the user has entered the CAPTCHA input and clicks some button whose click event is bound to return to your first JS function, the Javascript intercepts this action and posts the full form, all the data from the original form and the CAPTCHA for validation. Your server script can now process all this at once!
This is the best solution I can think of that works similar to how you've asked, but I can't imagine why you want to perform the CAPTCHA on a different page.
Server.Transfer with MultiViews, Panels like control is fine with you? In this way, no need to bother about the Data Maintenance and Postbacks. You can do the validations in javascript.
You can keep both functionality in the same page to avoid moving data from one page to another page/Bring the data back to original page. You can utilize Session for this intermediate operation. Set it back to associated controls across Postback. You can create a class, Instantiate it and Initialize the control values in this class object. Save class object in Session. On Postback, You can reassign the values to the associated controls. This will definitely keep the things simple and without much complexity.
Doubts ?