What is updated when an Update is triggered? What goes to the server? What comes back?
I was under the impression that only the content of the panel was transmitted to the server and back (without touching anything in the page outside the panel), but I'm experiencing strange results, probably because I don't really understand how it works exactly.
Can someone provide an easy explanation as to how exactly it works?
What is generated is a form submit through AJAX, which means essentially XML HTTP in the browser. When it hits the server, the server sees it as an AJAX call and it routes the Request to the correct method.
As for precisely what is sent, it is anything that the form submit should send, which can very well be information outside of the UpdatePanel. the sever then figures out what to work with and sends back a Response.
This is all well and good as theory, but you are dealing with problems not theory. What strangeness are you experiencing? If you can post, we can focus on the particulars of the problem.
The post that goes to the server contains pretty much all the information of the post, including the viewstate. The difference is on what is actually returned back to the browser.
To process the request, the full page is instantiated, if anything is updated outside the update panel, then you can get some ugly errors.
Update 1: this is different to other ajax approaches, that only send the bit of info needed and doesn't use viewstate i.e. autocompleteextender of the ajax control toolkit - look for json, ajax requests, and other related info.
It might work for you, but you are correct to look into understanding what is going on, that way you need when it is appropriate to just other solutions instead.
Related
It is possible to have a control that would proxy requests to another domain/Web site, including postback?
In this control, you would specify the URL you wanted to execute, and whenever the control executed, it would make a GET request to this other URL, and render the HTML return. (This part is not hard.)
However, when the page is posting back, it would make a POST request, with all of its postback variables intact, to this other page.
I'm really looking for a blind proxy. Some control that will take the incoming request and throw it another URL, and render the results. The other page would really have no idea it wasn't interacting with a human.
I want to think I could develop this, but I can't be the first person who wants to do it, so there has to be some reason why Google isn't revealing the solution to me. I suspect I'm going to run into the same Big Problem that anyone else with this idea has run into.
I'm not exactly sure what the value of this is; which is probably why you haven't found a solution yet.
However, it seems to me that there are two possible solutions.
When the page is rendered have the control modify the form action to point elsewhere; or,
on post back, have the control execute a web request to the alternate URL with the post variables and decide what to do with the results at that time.
In this end, this never had much of a chance of working. I experimented with it for a while, but Postback requires intimate knowledge of the control tree, and there's no way that you're going to be able to apply a postback from the calling page to the other page and have it overlay correctly because the control trees between the two pages are totally different.
Now, if you wanted to write the backend app as a more traditional Web app (even something not in ASP.Net), it might work. During postback, you could iterate the Request.Form values and send them back, and just have your backend app prepared to accept those incoming values and deal with them, but this wouldn't be a traditional postback.
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 only need to parse URL Request.Querystrings on GET, not on postback, right?
if(!IsPostBack)
{
Viewstate["magic_number"] = Parse(Request.Query);
}
The user can't be expected to modify the URL in the Request for subsequent postbacks, or can they?
Motivation for question-- I don't control the javascript snippet that does the postback, so it's something of blackbox to me.
The URL is not expected to change. But remember that each postback is a new instance of your page class. So if you didn't save the results somewhere on the first view you need to be prepared to do it again on the next one, and so on. In this case you saved it to ViewState, and so that should be fine.
However, I suspect you wouldn't be asking the question unless you had observed behavior that led you to suspect otherwise. So let's consider for a moment what things could cause this to break:
It is possible to modify ViewState at the client where you saved your results (though not trivial and definitely not recommended).
You can fake a postback before the initial page view.
You can use javascript to alter the posted url.
However, for all these things you would certainly know if you have written anything to do that.
Your assumption is correct, the URL is not expected to be modified in subequent post backs and you need to parse the query string only on the GET, which happens the first time the page is loaded.
The URL does not normally change for a postback.
It's of course possible to use a tool like FireBug to edit the URL in the form tag before the postback, but then you probably don't want the value that the user injected anyway, but the original value.
As others have pointed out, The URL is not expected to change. Of course if we lived in a perfect world you would never get email spam and noone would ever attempt to do anything malicious to your website.
In the real world you should expect that malicious people will attempt to hijack your website and need to be concerned with things like injection attacks
You should never make any assumptions that the data received on a postback is valid.
I need to read data from an online database that's displayed using an aspx page from the UN. I've done HTML parsing before, but it was always by manipulating query-string values. In this case, the site uses asp.net postbacks. So, you click on a value in box one, then box two shows, click on a value in box 2 and click a button to get your results.
Does anybody know how I could automate that process?
Thanks,
Mike
You may still only need to send one request, but that one request can be rather complicated. ASP.Net is notoriously difficult (though not impossible) to screen scrape. Between event validation and the ViewState, it's tricky to get your requests just right. The simplest way to do it is often to use a sniffer tool like fiddler to see exactly what the http request looks like, and then just mimic that request.
If you do still need to send two requests, it's because the first request also places some state in a session somewhere, and that means whatever you use to send those requests needs to be able to send them with the same session. This often means supporting cookies.
Watin would be my first choice. You would code the selecting and clicking, then parse the HTML after.
I'd look at HtmlAgilityPack with the FormProcessor addon.
I am working on a form, which I would like to validation features like This. Should this all be done on clientside? or server side? I am aware of using some of MS ajax controld, however, at what point do I display the message at the top?
I hope I explained myself.
You should validate at both ends.
Client side to make sure feedback is immediate so users can complete it fast (a bonus for them) and you save server resources (bonus for you).
Server side to make sure that any user-agents not using JS can check the incoming data. This is essential to stop malicious/corrupt data entering your system.
If you were only going to do one, make it server side, but there are considerable benefits to the user by implementing a dual-system.
validation on the client-side and provide feedback when they click the submit button
but since you cannot trust client-side validation, also validation on the server side and display feedback on postback if everything is not correct
but since you cannot trust the calling code, also validate in the database server (stored procedures are best) and raise errors back to the calling code if something is amiss
that way you've covered all the bases
It's generally considered a good practice to validate on both the client side and the server side...just in case someone attempts to directly submit a form POST without actually loading a page.
As far as when to display the validation message, it is something of a personal preference. I tend to perfer giving feedback as soon as possible, so I would do things like regex validation when the field looses focus.
Its really easy, you can use the ASP.NET Validation controls, you can use them in both, client and server side.
Check this resources:
How Do I: Use Validation Controls in ASP.NET? (video)
Form Validation with ASP.NET - It Doesn't Get Any Easier!
In general terms (depending upon the quality of your Ajax Framework) client-side validation is out. It's a relic from the past (Pre Ajax Times) and not really needed anymore...
Run all your validation on the server. After all with Ajax everything is 100 times as fast anyway, right...?