I have a basic Squid server setup and I am trying to use Ruby's Net::HTTP::Proxy class to send a POST of form data to a specified HTTP endpoint.
I assumed I could do the following:
Net::HTTP::Proxy(my_host, my_port).start(url.host) do |h|
req = Net::HTTP::Post.new(url.path)
req.form_data = { "xml" => xml }
h.request(req)
end
But, alas, proxy vs. non-proxied Net::HTTP classes don't seem to use the proxy IP Address. my remote service responds telling me that it received a request from the wrong IP address, ie: not the proxy. I am looking for a specific way to write the procedure, so that I can successfully send a form post via a proxy. Help? :)
Hah, turns out that is the right way to do it, my issue was actually with Squid and the API I was pushing to. Interesting tip related to this problem, if you are proxying with Squid proxy server, you probably want to add this server config option:
header_access X-Forwarded-For deny all
This will make sure that the proxy completely ignores any relation to the caller's IP address as far as the HTTP endpoint is concerned.
You may also want to look at the mechanize gem, based on Perl's WWW::Mechanize. If it's anything like the Perl one (and I'm led to believe it is), then it encapsulates much of the common mess that you're dealing with.
Ruby: http://mechanize.rubyforge.org/
Perl: http://search.cpan.org/dist/WWW-Mechanize/
Related
I am trying to use my proxy with the Soundcloud API. The format is
client = soundcloud.Client(client_id=client_id,
client_secret=client_secret,
username=username,
password=password,
proxies=proxies)
However, when I pass something into the proxies variable like
proxies = {'http': 'notavalidip'}
the client is still able to log in and function normally. Why is this happening and how can I test that when I pass an actual valid proxy it will actually be used? I believe this API uses the Python requests library, if that helps.
All those options get handed down to make_request eventually being passed into kwargs inside the request_func, which is indeed backed by the requests library.
Your proxy is passing only because it has the wrong scheme. All connections to Soundcloud are made via https, and not http by default. This means that you have no proxy setup, since your proxies dictionary has no https key.
See here how proxy is simply set to None because the dictionary didn't have the required scheme.
After modifying your proxies variable to https instead of http I got an exception thrown (ProxyError('Cannot connect to proxy.'), so no silent fails.
Hope this makes sense.
Is it ok to pass passwords like this or should the method be POST or does it not matter?
xmlhttp.open("GET","pas123",true);
xmlhttp.send();
Additional info: I'm building this using a local virtual web server so I don't think I'll have https until I put upfront some money on a real web server :-)
EDIT: According to Gumo's link encodeURIComponent should be used. Should I do xmlhttp.send(encodeURIComponent(password)) or would this cause errors in the password matching?
Post them via HTTPS than you don't need to matter about that ;)
But note that you need that the page which sends that data must be accessed with https too due the same origin policy.
About your money limentation you can use self signed certificates or you can use a certificate from https://startssl.com/ where you can get certificates for free.
All HTTP requests are sent as text, so the particulars of whether it's a GET or POST or PUT... don't really matter. What matters for security in transmission is that you send it via SSL (and handle it safely on the other end, of course).
You can use a self-signed cert until something better is made available. It will be a special hell later if you don't design with https in mind now :)
It shouldn't matter, the main reason for not using GET on conventional web forms is the fact that the details are visible in the address bar, which isn't an issue when using AJAX.
All HTTP requests (GET/POST/ect) are sent in plain text so could be obtained using network tracing software (e.g. Wireshark) to protect against this you will need to use HTTPS
I have been trying to get this resolved, without any success.
I have a webapp residing on my domain, say www.myDomain.com. I need to call a service which is present on another domain, say www.anotherDomain.com/service.do?
I'm using SproutCore's SC.Request.getUrl(www.anotherDomain.com/service.do?) to call that service.
I get an error that says, Origin www.myDomain.com is not allowed by access-control-allow-origin.
When I was in dev stages, and using sc-server, the issue was resolved using proxies. Now that I have deployed the app to an actual server, I replaced all the lines where I had set up the proxy with the actual domain name. I have started getting that error again.
The problem is that I CANNOT MAKE ANY CHANGES to the server on the other domain. All the posts that I have come across state that the other server on the other domain ought to provide access-control-allow-origin header and that it ought to support the OPTIONS verb.
My question is, is it possible for me to connect to that service using SproutCore's SC.Request.getUrl() method?
Additionally, the other posts that I have read mentioned that a simple GET request ought not to be preflighted. Why then are my requests going as OPTION instead of GET?
Thanks a ton in advance! :D
This is not a Sproutcore issue; it's a javascript Same Origin Policy issue.
If you can't modify the production server, you have no option but to develop your own proxy server, and have your proxy hit the real service.
This is effectively replacing sc-server in your production environment.
All this server would do is take the incoming request and pass it along to www.anotherDomain.com/?service.do.
You would need to make sure you passed all parameters, cookies, headers, the http verb, etc....
This is far from ideal, because now errors can occur in more places. Did the real service fail? Did the proxy fail? etc.
If you could modify the other domain, you could
1) deploy your SC app there.
2) put in the CORS headers so you could make cross domain requests
The parts
I am developing against two Pylons servers and testing locally. One server is on port 5000 and is the called server. The other is on port 7000. The latter creates a cookie that specifies the same domain as used by the former server. Essentially, the first server uses credentials provided by the second server to impersonate the user.
The first server expects to find an auth token (a cookie, really) in its response.environ at run time. When I authenticate on the server on port 7000 and browser to a service on port 5000, the latter server uses the cookie created by the former and the app works.
The fly in the ointment is that the first server creates an HTML5 app that uses an ajax call to the second server, and I cannot get the cookie to be included in the ajax call. I believe that Chrome (the browser we are using/requiring for HTML5 support reasons) refuses to send the cookie for cross domain reasons: going from foo.net:7000 to foo.net:5000 is considered cross domain.
Oh, and the ajax call is through jQuery.
The question
Is there any way to make an ajax call from an HTML5 app created on a port in the same domain to a server in the same domain but a different port?
What I've tried or discard out of hand
I do not believe I can use dynamic script tag insertion because I am making the call from javascript and the HTML is generated on the client at runtime from other javascript. At least, I don't think that is a desirable solution.
I don't believe Access-Control-Allow-* is applicable because I am going from client to server, not the other way.
I've seen this on jQuery and ports in ajax calls. I've seen this, too.
I know about the same-origin policy.
And this does not work.
Agree with Michael that the simplest solution is JSONP. But even in JSONP you need to configure your server such that it supports JSONP. Many Servers deny this to keep their data secure and sound. JSONP expect your server to send data in the format that can be evaluated as the valid JSON. But its not the case in every JSONP Request and response. So, just watch out for that.
The absolutely simplest solution to this is to use JSON/P. I wish there were an easier, softer way to accomplish this, but I certainly haven't found one.
I'm trying to get Fiddler to work with my company's proxy. Every external request is returning 407.
So far I've tried adding oSession.oRequest["Proxy-Authorization"] = "YOURCREDENTIALS"; to the customized rules where I used my USERNAME:PASSWORD in base64. Still no luck.
Any ideas? Thanks.
What worked for me was much more simpler:
Rules > Automatically Authenticate
Note: There is an answer with a higher voting available. Because of SO sorting it is below the accepted answer.
I had the same problem, too, and solved it like this:
Started Fiddler with it's standard configuration.
Started IE and made a HTTP-request to an external web-site.
The proxy authorization dialogue popped up, where I entered my credentials.
In Fiddler searched the request headers for "Proxy-Authorization".
Copied the header value which looked like "Basic sOMeBASE64eNCODEdSTRING=" to the clipboard.
Altered the CustomRules.js with the following line within OnBeforeRequest:
oSession.oRequest["Proxy-Authorization"] = "Basic sOMeBASE64eNCODEdSTRING=";
So my approach was quite similar to yours just that in advance I checked what kind of proxy authorization the server required by using Fiddler to debug the authorization header. That way I found out I had to add "Basic" before the Base64 encoded credentials and I didn't even have to use the tool to encode the credentials to Base64. Just copied the value from the proxy authorization header.
My Answer is simple. If your company proxy is NTLM, download ,setUp and configure cntlm. Route your fiddler to cntlm port by setting proxy settings.
Done! that is how i configured fiddler in my company
What version of Fiddler are you using?
Fiddler will automatically chain to your organization's proxy, and all current versions of Fiddler support passing of authentication information between the client and the authenticating proxy.
How are you generating the HTTP requests in question? What are the exact HTTP response headers?
http://blog.bareweb.eu/2010/10/http-debugging-fiddler-tip-1/
There's an entry in the "Rules" menu for Requiring Proxy Authentication. Use that and you should get a bit further!
Fiddler should pick up native proxy configuration automatically.