We are currently evaluating the pros and cons of ArcGIS Online vs. ArcGIS Enterprise. Part of that evaluation involves determining the differences in implementing our automation toolsets. These are written in Python and consume ArcGIS via the REST API. In both ArcGIS Online and ArcGIS Enterprise we are serving a hosted feature service and an app (with its ClientID and ClientSecret). Both are shared with a group.
For all intents and purposes, both the AGOL and the AGEnt implementation patterns are identical.
Running with same code returns different results: An access token is obtained using the ClientID/ClientSecret. Using that access token to query the feature service returns the desired JSON payload when consuming from AGOL (i.e., features and geometries). Using the access token to query the feature service when consuming from AGEnt returns a code 498, Invalid token.
Why is this happening to me? Below is the executed Python
TIA
query_string = {"client_id":appID,"client_secret":appSecret,"grant_type":"client_credentials"}
# get an access token
response00 = requests.post(tokenUrl, params=query_string)
access_token = response00.json()["access_token"]
where = "1=1" # MAGIC where clause
params = {"where": where, "outFields": "*", "f": "json", 'token': access_token}
response01 = requests.post(url = featureServiceQueryUrl, params = params)
# extracting data in json format
data01 = response01.json()
fields = data01.get('fields')
features = data01.get('features')
We are also experiencing a similar issue on Enterprise. Can't comment on the our similarity to AGOL, but the issue appears in almost all applications that use portal token auth - Web Appbuilder, Operations Dashboard, Python ELT, etc. It is quite frustrating for the implementers and users, and is preventing the adoption of ArcGIS Enterprise in our org. I have also been trying to get support on this issue for over 2 months now and have gone through 3 tiers only to be told that Esri cannot work on Windows IIS issues because it isn't their product. Go figure. Their answer is to spend money on professional services to solve the issue. Would love to hear from any Esri people out there on this issue......
Hello!
FYI I opened a case with Esri tech support - which is still open. The analyst managed to recreate the issue; now I'm trying to convince them that this is a bug.
Also FYI we're doing the same exercise with SharePoint Online vs. SharePoint on-premise and the results have been quite similar. Using OAuth against SPO is easy and straightforward; we still haven't gotten OAuth to work against SharePoint on-premise.
Cheers!
Thanks for the update Dirk. Are you using a reverse proxy in a dmz or is it all internal? Have you federated servers to your portal?
All internal, we're federated, using internal security (not enterprise or SAML), a pretty vanilla installation really.
Hi Dirk
Did you ever manage to solve this issue? I believe I am running into a similar problem. See my thread here:
Cheers