I recently installed Portal on-top of our DEV instance of ArcGIS Enterprise. This is my first experience with Portal/ArcGIS Online outside of setting-up some geocoding services in AGOL. We are using Enterprise/Portal 10.6.1.
When I attempt to register a routing service using REST, I receive the following response/error:
"message": "Registration of this item is not allowed",
I triple-confirmed the ClientID as reported by Portal. A "register app" button is not present on the Content Details page of Portal for the service.
Any ideas? I saw there was a bug for "missing button" in 10.4 - Bug: Register option is not available on the Item Details page for apps in the Portal for ArcGIS hom... - however, in my case, I am neither using 10.4, nor am I successful in using the REST interface.
I'm unsure I understand. Are you registering an app or configuring the Portal to use a routing service? Typically a routing service is added to the portal as an item, then if desired configured as a portal utility service. While an app frequently consumes services, it is not itself a service.
Apologies if I used the incorrect terminology - the routing service was published, as a routing service, to ArcGIS Enterprise before Portal was installed and configured. I was able to secure the service and consume within a JSAPI application using the Proxy config - GitHub - Esri/resource-proxy: Proxy files for DotNet, Java and PHP. with username/password credentials.
Now that Portal is installed, it is listed as a Network Analysis tool. This tool, I cannot register using https://myserver/portal/sharing/rest/oauth2/registerApp with the ClientID provided by Portal. This, I need, to obtain clientSecret so that I can authenticate using oauth2 via the Esri Proxy.
Got it. You'd register the app that consumes the service/web tool. The service/tool itself should already be accessible via oAuth since the GIS Server is federated with the Portal.
I guess where there is some confusion, when I developed an AGOL geocoder app, listed specifically as an "Application" in AGOL, a ClientID and AppSecret are viewable on the settings page, so I can use them to obtain a token, like so:
https://geocode.arcgis.com/arcgis/rest/services/World/GeocodeServer/findAddressCandidates?forStorage=true&locationType=rooftop&maxLocations=1&outfields=*&f=pjson&sourcecountry=usa&singleLine=123 Main St, Any Town, Any State, USA&token=tokenObtainedFromOauth2InTheFirstLink..
What I need to do is consume the routing service without requiring authentication/log-in from our users. This would take place via the proxy, which should get a token using clientID and appSecret supplied in the proxy config for this endpoint.
Do I need to configure the tool differently in Portal?
Thanks for the info - I was successful in generating a token, but it was not accepted by the networking service. I did come across this document:
I do see our networking service listed as a utility service... what is the proper way of obtaining a token to consume this in the JSAPI? I don't see anywhere in settings where clientID/appSecret are listed.
Some information on what I'm trying to do... here's the Esri sample from which I'm working:
Per the Esri Proxy documentation (GitHub - Esri/resource-proxy: Proxy files for DotNet, Java and PHP. ), I expect to add this in the config file:
...so the app can consume the network service without a log-in prompt. I had no problems doing this sort of thing with username/password creds stored server-side in the Proxy config before Portal was installed.
Back in Portal, the NAS utility doesn't list clientID/clientSecret. I tried adding a Web Mapping application in Portal and pointing it to the NAS, which does allow registering and a redirect URI, and supplies a clientID/clientSecret. I can then use this to obtain a token hitting https://myServerGIS/portal/sharing/rest/oauth2/token. However, the token returned is not accepted by an example query - it reports that the token is invalid.
I worked with Esri tech support who confirmed that it is not possible to auth using the Proxy against Portal this way. We would need to revert to ArcGIS Server and use roles, like we've done in the past, or we'd need to publish an unsecured service.