Perspective HTTP Binding issues - debug proxy setup

Good morning all,

I’ve been experimenting with (8.0.3) HTTP Binding in Perspective, the GET method calls are working perfectly as per the videos and I’m very impressed with what we can do with it.

I cannot get HTTP PUT/POST methods to work. Ignoring the details of why that won’t work because there are too many reasons and I can’t narrow it down. I’ve come to a point where I’d like to use Burp Suite or another intercepting proxy to listen to the HTTP Method calls on my dev/testing machine.

I want to set a proxy for the perspective client to access the REST API and then intercept the proxy traffic so that I can analyse what is being sent to the API (I could theoretically listen at the API with a debugger but that is another issue due to me not being the direct developer of that part of this demo)

Does anyone know where/how I can tell the perspective client to access the API via a proxy server? Is it a JVM commandline param for the gateway? Is it a matter of setting the browser proxy server (which doesn’t appear to be the answer). Is it a gateway setting somewhere??

Could it be something in the HTTP Binding on the Perspective page element?

Has anyone actually got a NON-scripted (not onChanged Event etc) Perspective HTTP binding to work when it has to PUT/POST to a RESTful API?

Cheers
Simon

We had similar problems using system.net.httpPost with Ignition 7.9.x. and 8.0.x.
I don’t think you really want to use POST/PUT in a binding like you can a GET because the responses can vary so much with network/server/service/data.

Our scripted solution was to import URLLIB and URLLIB2 for POST/PUT functionality.
Here’s an abbreviated code snip:

# import libraries
import urllib	
import urllib2
from urllib2 import URLError, HTTPError

# prepare header and post data
postData= {'dictionary':'data'}
header	= {'Authorization': 'Bearer %s' %accessToken}  # the token provided by the API source
data	= urllib.urlencode(postData)  # this ensures that data is correctly formatted for POST

# call the API
try:
	apiRequest 	= urllib2.Request(endPoint, data, header)
	apiResponse	= urllib2.urlopen(apiRequest)
	appResponse	= apiResponse.read()
	apiResponse.close()	# actively close the connection JIRA Issue: QCT-1678
						# note: we had intermittent errors until this close was added
						# little documentation on close; use it when making frequent calls
except HTTPError, he:
	logger.error( 'Response: %s "%s"' %(str(jsonResponse), str(he)) )
except URLError, ue:	# next version of Jython recommends using "URLError as <alias>"
	logger.error( 'Response: %s "%s"' %(str(jsonResponse),str(ue)) )
except IOError, ioe:
	logger.error( 'Response: %s "%s"' %(str(jsonResponse), str(ioe)) )
except:
	logger.error( 'Response: %s' %str(jsonResponse) )

martinel3746 - Thanks

That’s a really great solution, I did write the same thing in effect with system.net.httpPut in 8.0.3 with no issues. I’m still looking for more information on the HTTP POST/PUT Binding and the proxy issue as well for a couple of reasons.

Do you know how I might be able to intercept my API calls via HTTP Proxy? I was using Burp Proxy (https://portswigger.net/) and I can’t seem to catch the API calls in transit for some reason.

Cheers
Simon

Is the browser proxy setting the only one required to have the Perspective client access the API via that proxy? Or is there a Gateway/JVM proxy parameter that is required?

Scripts and bindings in Perspective are executing on the gateway - any proxy settings in the browser won’t affect the actual execution of an HTTP query/binding, so you would have to set it at on the gateway at some level.

For what it’s worth, I’m actively working on a newer, better set of HTTP methods for scripting that will replace the existing system.net functions - and, one of the key things they add is support for proxies :slight_smile:

Thanks, that is excellent to know. Do you have any advice for how to set a proxy on the gateway for system.net calls?

Do you have a completely non-binding and rough estimate for when those system.net methods might be avaliable?

Additionally, is attempting to bind HttpPut/Post in Perspective totally the wrong way to be going about this architecturally?

Well, if you want my real advice, get a python 2.7 installation of requests and just use that - it’s pure Python, and much, much nicer to use than something like urrllib (and, bonus, directly supports setting proxies). If you don’t want to, or don’t have any luck with that, then you can set a global HTTP proxy for the gateway via two Java command line parameters. You would add these in the wrapper.java.additional section of the <install directory/data/ignition.conf file:

-Dhttp.proxyHost=10.0.0.100 
-Dhttp.proxyPort=8800

For an estimate on the new functions: Nothing firm; hopefully 8.0.6 but there’s no guarantees.

About httpPut/httpPost - really, in a proper “REST” API, they don’t match with what our bindings do - so, yes, I would say scripting them is the “right” thing to do - as always in Perspective, a lot of things get cleaner when you start to embrace message handlers.

PGriffith: Thank you for that, the Proxy host and port at the gateway worked well, I’m going over the message handler videos again and taking far more notice.

Thanks for the advice and direction, both you and martinel3746 were a huge help, cheers
Simon

Thanks @PGriffith for the great tips.
I look forward to the new system.net functions.

PGriffith: Did you ever get to the new http functionality referred to above?

Hi Simon. It made 8.0.6 as forecast:

https://docs.inductiveautomation.com/display/DOC80/system.net.httpClient

1 Like

Thank you very much