I have a standard html registration page that targets an external .asp page on submit.
What happens is that currently the .asp (which I don't have access to)returns an entire html page.
Instead I would like to somehow parse the returned html and populate the existing form with either
a) validation errors if incorrect
or
B) some sort of success message if all validated
Can anyone tell me if this is possible and or help with some pseudo code?
This is doable in JavaScript using ajax, but it requires that the ASP page (presumably on a different domain) sends appropriate CORS HTTP headers. Even if you don't have access to the actual ASP page, you may be able to get someone to setup the headers in IIS on their server.
Otherwise, you're stuck moving everything server-side, i.e. simulating the POST on your own webserver, and scraping the HTML to get the status back. That looks something like:
Postback the page to your own page (or use Ajax)
On your server, initiate a web request post of the data to the ASP page
Parse the results in your server code
Return an appropriate response to the browser client
The best you can do, assuming I'm interpreting your question correctly, is "scrape" the HTML returned from the asp page and make proper assumptions about the location and meaning of the text within the markup. I, personally, would strongly advise against developing anything of any kind of robustness based on what amounts to screen scraping, especially considering you don't have access to the .asp file itself. If I've misunderstood your problem, my apologies.
Related
I'm trying to manipulate a .net ASP form on a site that's using AJAX Control Toolkit. The site is only accessible to valid logins, and I do have a valid account. It consists of a search page with a form. Each time a submit button is clicked on the form, the server is updated using the values of some text fields on the form, and then the VIEWSTATE and EVENTVALIDATION tokens will be updated based on the response from the server, ready for the next request.
I'm using HttpClient in Java to do this. I suspect there's something I'm not doing correctly with regard to interacting with ASPX forms in general.
When I hit the main search page for the first time (cookies are validating my login with the server), I get the HTML for the search page back. I extract the VIEWSTATE and EVENTVALIDATION tokens for the next request. I've examined the exact form fields and their values that need to be sent to the server in a POST by looking at the Chrome debugger utility after making a request on the site manually. I've replicated them exactly as they should be, inserting the VIEWSTATE and EVENTVALIDATION appropriately.
But the response I get back from the server is not what it should be. What I get back is just the same HTML for the main search page that I get the first time I hit the webpage. The form data I'm using looks like this:
ctl00$ScriptManager1:ctl00$ContentPlaceHolder1$UpdatePanel1|ctl00$ContentPlaceHolder1$TabContainer1$TabPanel1$acceptButton
ctl00_ContentPlaceHolder1_TabContainer1_ClientState:{"ActiveTabIndex":0,"TabState":[true,true]}
__EVENTTARGET:
__EVENTARGUMENT:
__LASTFOCUS:
__VIEWSTATE:<token extracted from first page hit>
__VIEWSTATEENCRYPTED:
__EVENTVALIDATION:<token extracted from first page hit>
ctl00$ContentPlaceHolder1$LabelFee:0
ctl00$ContentPlaceHolder1$TabContainer1$TabPanel1$RadioButtonList1:Person
ctl00$ContentPlaceHolder1$TabContainer1$TabPanel1$snameText:aSurname
ctl00$ContentPlaceHolder1$TabContainer1$TabPanel1$HiddenField1:
ctl00$ContentPlaceHolder1$TabContainer1$TabPanel1$fnameText:aFirstname
ctl00$ContentPlaceHolder1$TabContainer1$TabPanel1$dayFromTextBox:01
ctl00$ContentPlaceHolder1$TabContainer1$TabPanel1$monthFromTextBox:January
ctl00$ContentPlaceHolder1$TabContainer1$TabPanel1$yearFromTextBox:2001
ctl00$ContentPlaceHolder1$TabContainer1$TabPanel1$dayToTextBox:01
ctl00$ContentPlaceHolder1$TabContainer1$TabPanel1$monthToTextBox:January
ctl00$ContentPlaceHolder1$TabContainer1$TabPanel1$yearToTextBox:2008
ctl00$ContentPlaceHolder1$TabContainer1$TabPanel1$DropDownList1:aCity
ctl00$ContentPlaceHolder1$TabContainer1$TabPanel1$PropText:
ctl00$ContentPlaceHolder1$TabContainer1$TabPanel2$RefText:
__ASYNCPOST:true
ctl00$ContentPlaceHolder1$TabContainer1$TabPanel1$acceptButton:Accept
I've also tried replicating the headers that the Chrome debugger shows, so my request is including the same Content-Type, Host, Origin, Referer, User-Agent (for my browser) and every other header, including this header X-MicrosoftAjax: Delta=true.
I know there's a lot of moving parts here, but I intentionally haven't mentioned how I'm actually making the POST request with the HttpClient lib because I'd don't want to complicate the question anymore or alienate anyone who doesn't know Java but knows ASP. I'd like to know if there's an ASP issue I'm not addressing, but I can post the Java code is necessary.
Edit:
I've checked the debugging info that HttpClient is outputting just before sending the request, and the form data is being added properly as multi-part form data. The headers are all there too.
This answer is a long shot, but I've seen weirder things.
You mention this header:
X-MicrosoftAjax: Delta=true
I did some deep googling and found that this is often shown as all lower case in dumps of Ajax and UpdatePanel POST requests:
x-microsoftajax: Delta=true
See here and here.
Could it be as simple as not casing the header correctly?
I eventually got this working. The problem was not specific to ASP in general, it was actually a problem with how Java (specifically HttpClient) was sending the request. I was using HttpClient to compile the request using multi-part form, but after using Fiddler to analyse and compare the requests (see the edited part of this question for more details on that) sent from both my application and the actual webpage, my app request was structured very differently.
The real website request had the form options embedded in the request body in what looked like a URL encoded query string. My request was a series of entries in the request body where each option was wrapped in the Content-Type and Content-Disposition headers. The requests succeeded after changing the POST to add the parameters like:
request.setEntity(new UrlEncodedFormEntity(paramList));
Regarding to a static link on a web page, the browser will issue GET or POST request to the web site, depending on whether a form of parameters attached.
However, I want the browser to issue a PUT request for that link, how can I do that? I know that Ajax could do it, but I don't want to use Ajax.
I want the browser to issue a PUT request for that link
it seems that PUT and DELETE are currently unsupported in html forms, according to this submission to the w3.
I know that Ajax could do it
Not always true. Because PUT and DELETE are at times unsupported by some browsers, ajax cannot consume them without making a dummy param to trigger a real PUT or DELETE server side, which gives the illusion of full HTTP support by ajax.
So... I've got an ASP.NET app. Let's assume I configure IIS to always point to the same file, index.aspx. Let's say I want to write all my code in C# and then return some HTML I generated in the C#. How do I do that?
Would I just have 1 file with 1 line of code,
<%# Page CodeBehind="mycode.cs"
Is it necessary to have such a "useless" file? I can't direct the request straight into the code-behind?
Secondly, where are some good tutorials on code-behinds? Specifically, I see this Page_Load event that I guess gets called automatically?
Are there other events? What are they?
Also, how would I access things like POST data, or the request URL?
How would I return a HTML response? Or a 404?
I'm seeing a lot of tutorials on "inline" ASP, but I don't really care about that.
Sounds like you want a generic handler. They are available in the New Item... dialog. This will give you a .ashx file where you can handle incoming web requests just like you would in your scenario, but in a cleaner way. Using these you can return any kind of HTTP response, including HTTP errors. You have full access to the HTTP context for POST data, URL parameters, cookies, etc. See more here.
Another alternative is to implement IHttpHandler yourself, although with generic handlers there isn't much point in going through the effort.
Are there other events? What are they?
There is a whole lot of Events available when you inherit from System.Web.UI.Page. You can see them http://msdn.microsoft.com/en-us/library/ms178472.aspx
Also, how would I access things like POST data, or the request URL?
this.Request.Form, would let you access the PostData from a page. this.Request.Url would let you access the url.
How would I return a HTML response? Or a 404?
You can override the Render method of the page to provide HTML Response. You can throw a HttpException(404, "file not found") to return 404.
After going through your questions, you most likely need ASP.NET MVC rather than ASP.NET webforms or you can use a handler as suggested by Martin
I'm using code in the Application_BeingRequest() handler of my Global.asax to do some very primitive URL Rewriting. That works fine, however, I'm having issues fetching the rewritten URL in JavaScript.
So using URL Rewriting www.mydomain.com/dothis becomes www.mydomain.com/?action=dothis on the server-side. Using ASP.Net and Request.QueryString["action"], I get the expected result of dothis. JavaScript, of course, still sees www.mydomain.com/dothis because that's what is displayed in the browser.
I don't suppose there is a way for JavaScript to see the actual page URL, even though it's not displayed in the address bar?
What happens on the server beyond the http interface is not visible to the UA if you don´t tell it explicitly.
The rewrite is happening on the server before the server forward the request to the appropriate handler.
You can tell the UA this in many ways (ask Tim Toady ^^). Hidden form control, a JavaScript variable to mention a few. This is ofc if your framework/server supports this.
I've been using user controls extensively but never use a HttpHandler and was wondering if I am doing something suboptimal or wrong
Unfortunately your question is a little like "Should I use a sandwich or a cement mixer". HttpHandlers and User controls are completely different things.
HttpHandlers are used to process HTTP requests. For example, if you wanted to dynamically create an RSS feed, you could write an HTTP handler that handles all requests for ".rss" files, creates the output and sends it back to the user.
User controls are used within ASPX pages to encapsulate units of functionality that you want to re-use accross many pages.
Chances are, if you're using user controls successfully, you don't want to use HttpHandlers!
Basically a user control is a piece of server logic and UI. An HTTP Handler is only a piece of logic that is executed when a resource on your server is requested. For example you may decide to handle requests for images sent to your server through your own handler and serve images from a database instead of the file system. However, in this case there's no interface that the user sees and when he visits a URL on your server he would get the response you constructed in your own handler. Handlers are usually done for specific extensions and HTTP request types (POST, GET). Here's some more info on MSDN: http://msdn.microsoft.com/en-us/library/ms227675(VS.80).aspx
Expect a better answer (probably before I finish typing this) but as a quick summary.
A user control is something that can be added to a page.
A HttpHandler can be used instead of a page.
Just to clarify the question. I was reading the Hanselman post
http://www.hanselman.com/blog/CompositingTwoImagesIntoOneFromTheASPNETServerSide.aspx
and thinking that I would never solved the problem with a HttpHandler, maybe with a simple page returning a binary content.
This led me to think that I should add HttpHandler to my developer tool belt.
Even an Asp.Net page is an HttpHandler.
public class Page : TemplateControl, IHttpHandler
A user control actually resides within the asp.net aspx page.