What are you trying to get from those websites? I think you can get some things if you sandbox them.
The websites my application have to access is:
My own, via HTTPS
reCAPTCHA to fetch a challenge string, via HTTPS
A separate website, via HTTP
My own, I can host any type of required policy file. I'd of course need help with what the policy file needs to include, though.
reCAPTCHA, I need to fetch a challenge string, which then is used to fetch the CAPTCHA (https://api.recaptcha.com/image?k=<challenge string> i think) and later I need to submit the answer there to check it.
A separate website, after I check the answer with reCAPTCHA it will give me a token which my application then needs to submit to that website.
All requests are currently through HTTP, I don't know how to communicate through HTTPS yet and need help with that.
With the separate website, it's a type of ranking website that needs all of the requests to it to be through unique IP addresses, and so I need the applet to send/receive data to/from that website directly from the user's computer.
reCAPTCHA checking involves submitting the value of $_SERVER['REMOTE_ADDR'] which reCAPTCHA checks to make sure is the IP address that requested the CAPTCHA, so I need the applet to send/receive data to/from that from the user's computer as well.
My own website, I can add any workaround on that as I want.
You may know, there's no hope of me getting Google to add a policy file or whatever onto reCAPTCHA without it going at least a few months of approval process and also there's no way I can use a proxy because then the IP logged is the proxy's IP rather than the user's IP.
Not sure what you mean by sandbox. I'm currently using HTTPService if that helps at all, it works fine locally but if I try HTTPS it won't work, and if I try loading it onto my website it will never load the CAPTCHA.
It is a HTML based website, I'm just using this application to check the CAPTCHA itself.
The crossdomain.xml on reCAPTCHA is:
<?xml version="1.0"?><!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd"><cross-domain-policy><site-control permitted-cross-domain-policies="by-content-type" /></cross-domain-policy>
I have no idea what it means for me though.
The crossdomain.xml on the other website is nonexistant, and there's no way I can get them to add it, believe me I've tried something similar with it, a even smaller modification and it was turned down.
I'm ok with even a warning box saying "Are you sure you want to allow this to connect to http;//domain.com", it's a fully legitimate application and two legitimate websites, nothing shady.
Why does it have to be entirely done in Flash?
Somehow, all of these other websites are using reCAPTCHA aren’t they? Why don’t they have the same crossdomain.xml issue?
It's a very different implementation I'm doing.
Basically: It's a ranking site, I need a way to get a callback when the user votes. Some of these ranking sites do not provide a callback or even a "Vote success" message so I have to do this type of workaround.
Well, then you might be stuck. It sounds like you want to provide high-security for your app while finding a way around someone else’s security. There might be some other captcha provider with a SWF version.
So, no way, even if I were to have a security popup display or something?
It depends on what you are fetching. If you’ve tried it and the request is denied, then there is no workaround to allow that request other than a proxy server.
There might be CAPTCHA vendors that do support SWFs.
Alright, so I get this error:
[RPC Fault faultString="Security error accessing url" faultCode="Channel.Security.Error" faultDetail="Destination: DefaultHTTP"]
So even if like stated here (http://kb2.adobe.com/cps/142/tn_14213.html), "When placed on a server, it tells the Flash Player to allow direct access to data on that server, without prompting the user grant access." if I were to have a prompt show up, no way?
The server owner has locked you out, and Flash is not going to allow the end user to open the lock.
Heh. Would this application be impossible to make then, in this case?
You said that in a HTML/JS solution, there is JS hosted on their server you can use. If you can find a way to use that with their permission, then you have a solution. Basically, the provider has to provide the mechanism, you can’t force them, otherwise there would be no security.
I thought the crossdomain thing was to prevent flash files from sending /localhost or /intranet_tradesecrets, not to prevent the usage of a public API.
So short of going to Google and making them update their crossdomain this is hopeless?
That is the primary reason, but the configuration is essentially the same.
A quick search showed that there might be some SWF-based CAPTCHA services, but I could be wrong about that.
Well, I can't exactly control what CAPTCHA service someone else's website uses.