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.
Related
I`m wondering if it is possible to implement following:
I have some service in GO (used for Firebase Cloud Messaging) it uses go package from firebase (firebase.google.com/go/v4) to send messages. This packge sends https requests. And One of them is to https://oauth2.googleapis.com/token to get token.
I can't change code in Firebase go-package, but I need to use proxy, that is why before sending message I need to set HTTPS_PROXY environment variable to my proxy address. It works fine.
Now I need to do some automatic tests and I have an emulator that has /token endpoint and return a valid token as response. Is it possible to use some kind of proxy that can redirect https requests to my emulators endpoint so that all requests to https://oauth2.googleapis.com/token should be redirected to my emulators endpoint /token?
And another question is there are any possible problems because of HTTPS ?
Is it possible to get rid of https and use only http after the proxy?
Found following solution:
Firebase Cloud Messaging package uses clone default transport to create http.client under the hood.
So we can configure http.DefaultTransport before calling app.Messaging(ctx) and set up any parameters we need (proxy, insecureSkipVerify ...).
So no problems at all.
I have code where the the webtarget is passed to me from a different library. I do not have access to the code to modify the ResteasyClient. What I am trying to do is the equivalent of
Client client = new ResteasyClientBuilderImpl()
.defaultProxy("127.0.0.1", 9999, "http")
.build();
I already tried -Dhttp.proxyHost=127.0.0.1 -Dhttp.proxyPort=9999
I also tried
System.setProperty("http.proxyHost", "127.0.0.1");
System.setProperty("http.proxyPort", "9999");
System.setProperty("java.net.useSystemProxies", "true");`
Neither one does the equivalent of defaultProxy("127.0.0.1", 9999, "http")
Seems like they might have a solution over here. I tried signing up to see the solution. But they have no easy way subscribe where I can just punch in my credit card number.
I guess another way to ask this question would be, is there a way, where I can set all instances of org.apache.http.client.config.RequestConfig have its proxy property set to http://127.0.0.1:9999
Additional details:
What I am trying to do is to route http traffic thru a proxy server. I don't want to modify anything at the OS level (traffic shaping stuff). If I use a regular http client in java the parameters -Dhttp.proxyHost=127.0.0.1 -Dhttp.proxyPort=9999 work. But when using jboss resteasy client those parameters do not work.
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
I've been creating a Credential Provider DLL that authenticates via the internet before allowing login. However this hasn't worked as well as I expected because my WinHTTP request isn't getting sent. I've confirmed this using wire shark. but I can't figure out why it's not sending any requests off. I've checked that my code is actually calling the functions properly - and they are. But the http request never makes it off. I'm slightly confused at this point and I'm seeking to know if there is some blanket block against https Requests at login.
If you are using C++ CP-V2, so you can use easily from CPPRESTSDK library.
Note: You must note the DNS address and the digital certificate you are using must be valid.
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/