Geek Answers Handbook

Cross domain javascript form filling, reverse proxy

I need to fill out a javascript form that can bypass the “same origin policy” that most modern browsers implement.

I created a script that opens the desired website / form in a new browser. With the handler returned by the window.open method, I want to get the inputs using WindowHandler.document.getElementById ('inputx') and populate them (access is denied).

Is it possible to solve this problem using Isapi Rewrite ( official site ) in IIS 6 acting as a reverse proxy? If so, how do I set up a reverse proxy?

Here is how far I got:

RewriteEngine on RewriteLogLevel 9 LogLevel debug RewriteRule CarChecker https://the.actualcarchecker.com/CheckCar.aspx$1 [NC,P]

Rewriting works http://ourcompany.com/ourapplication/CarChecker , which is obvious when registering. From within our site, I can launch the token as if it were in our own domain. In addition, the "same origin policy" is still valid.

Update

I stopped using Isapi Rewrite, since the free version does not include a proxy component. I started using url-rewriter from Managed Fusion.

My current working rewrite:

 RewriteRule /MySecuredSite/CarChecker https://the.actualcarchecker.com [NC,P]

Now I get the error message: The main connection was closed: Failed to establish trust for the SSL / TLS secure channel.

I think this is happening because our ssl certificate is being sent to the carchecker website. How to set up a reverse proxy to transfer a carchecker site certificate?

Hi,

Michelle

+4
source share
3 answers

Without knowing a few more details, I decided it might be useful to point out some of the limitations that you encounter, and some of the tricks you could use:

  • I'm not an ASP developer, but I know that, as you mentioned, there is some kind of viewstate variable that needs to be presented along with the ASP form. I assume that this viewstate can be verified using only form fields that need to be resubmitted. That’s all I would expect (if it weren’t supercomplex), since the form the browser receives is all that it sends back (along with the values). So the point is that you need to have a valid view in the view when you submit to an aspx page, but perhaps you can grab any view you want from the server if the form fields that you submit are identical.

  • You can write a web page that acts just like your browser. It can capture an aspx page (thus creating a valid viewport), then you can create all the fields needed for the POST on the aspx page, including the viewstate, and do it. Regardless of the results, you can return from the web page to the browser. If you do not have the ability to modify another server, I really do not see another option at the moment, but maybe someone else might be more useful.

  • If you can change another server, you have a few more options. One of them includes a trick for transferring data between frames. If you use a hidden iframe to get an aspx page, you will not be able to return the result to the parent page due to the restriction between domains. But since you can change another server (running on the.actualcarchecker.com), you can get around this. To do this, simply make this server provide JavaScript to submit the form asynchronously, and then set the result (serialized to a string) in window.name.

    Now, in order to access window.name from your domain, you install iframe window.location on the page of your domain, which simply calls the function that you wrote in JavaScript loaded in the parent window. Like window.parent.process (window.name). Since the iframe loads the page in your domain, it will have access to window.name, which will not be changed even if you change the location of the window. Then the process () function in the parent window can deserialize the line, delete the hidden iframe, show the results, do whatever you want, etc.

  • You will not be able to fill out an aspx form loaded into a hidden iframe unless you do a similar trick on another domain server. For this server, JavaScript will need to be read from window.name to get the input to fill out the form. However, if both servers are in focus, you do not need to write proxies, you can simply transfer data through window.name.

+1
source

What server language are you using? Using it, you can create a proxy server that should easily bypass the policy of one domain ...

Php

 <?php $handle = fopen("https://the.actualcarchecker.com/CheckCar.aspx", "r"); $contents = ''; while (!feof($handle)) { $contents .= fread($handle, 8192); } fclose($handle); echo $contents; ?>

I would suggest that it will be a similar process with other languages.

0
source

Why don't you use the JSONP approach? That is, use JavaScript to read the values ​​entered into the form and send them to the server-side handler using the dynamically generated <script> element ( <script> and img elements can refer to resources from external domains).

 var e = document.createElement("script"); e.setAttribute("type", "text/javascript"); e.setAttribute("src", "https://the.actualcarchecker.com/CheckCar.aspx?input1=value1&input2=value2"); document.getElementsByTagName('head')[0].appendChild(e);

You probably won't need a serious rewrite of the URL at all, if you use this approach - just make sure CheckCar.aspx returns a valid JSON.

JQuery even has several convenient functions for this: AFAIK $ .getJSON will transparently switch from XHR to a dynamic script insert method if the request is cross-domain. In addition, it supports specifying callbacks. See jQuery docs and this IBM for more information.

Will this method work for you?

0
source

More articles:


All Articles