Open GoogleCodeExporter opened 8 years ago
Salesforce returns a new location after the login() call, and even though my
internal
call to the SOAP client to change it _shouldn't_ have any effect on the proxy,
I bet
it's being unset. Could you try the following? In base.py, in _setEndpoint,
after
this line
self._location = location
could you try adding
self._sforce.set_options(proxy = {{'http':'http://proxyhost:8080'})
and see if all subsequent calls work?
If that fixes it, I'll add a quick commit, and if that is the issue, I'll file
it
with Suds, as that's not the correct behavior IMO.
Thanks for reporting this!
Original comment by dlanst...@gmail.com
on 19 Apr 2010 at 9:55
As in your comment, Google Code has stripped the closing curly brace + closing
paren
for some reason in this line:
self._sforce.set_options(proxy = {'http':'http://proxyhost:8080'
Original comment by dlanst...@gmail.com
on 19 Apr 2010 at 9:57
That didn't actually help, but it got me to figure out the problem: I note
that what
salesforce is sending back for location is:
https://na7-api.salesforce.com/services/Soap/c/18.0/ORGID
Which sforceenterpriseclient then passes off the SUDS, which notes that there
is no
https proxy in the dictionary, and goes after it directly.
I confirmed that if I manually set the location in setEndpoint to my correct URL
(override anythign you get back from salesforce, note the change from https to
http):
location = 'http://na7-api.salesforce.com/services/Soap/c/18.0/ORGID'
that it does indeed work correctly and thru the proxy.
I'm not really sure who the bug lays with then - it would seem to me that
salesforce
should probably send back a URL with the same protocol as that with which it was
access (http), and that perhaps the Toolkit should recognize that salesforce is
being
stupid and munge things as needed.
Thoughts?
Original comment by mcow...@gmail.com
on 19 Apr 2010 at 11:07
If you are interested in a fix, I've attached a modified copy of base.py that
implements a forceHTTP keyword arg that does a simple string replacement that
fixes
this issue.
Original comment by mcow...@gmail.com
on 19 Apr 2010 at 11:50
Attachments:
Well, the initial request is also going over HTTPS, and it works transparently
with
your HTTP proxy... I'm not sure why changing the location causes the requests
not to
proxy, but if the bug is in Suds, a hack like re-instantiating the SOAP client
with
the new endpoint may be necessary. I'll look into this in the next couple of
days
and report back.
Original comment by dlanst...@gmail.com
on 19 Apr 2010 at 11:51
Thanks for the fix, I'd really prefer to get this sorted though, as I don't want
anyone to send their data over HTTP just to work around this issue.
Original comment by dlanst...@gmail.com
on 19 Apr 2010 at 11:53
Fair enough.
Thanks for the help.
Original comment by mcow...@gmail.com
on 19 Apr 2010 at 11:56
Original issue reported on code.google.com by
mcow...@gmail.com
on 19 Apr 2010 at 9:03