-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to make authentication work with arcgis online #178
Comments
I assume your trying to add a Koop FeatureServer to AGO. If so, @koopjs/auth-direct-file _should work. It was specifically developed and tested for AGO. Are you getting any errors that could help trouble shoot? |
Yes, that is correct and that was the answer I was hoping for! I will get some more info on the behavior we are seeing and get back to you. |
Currently, we get an error message "The layer, TestLayer, cannot be added to the map." after trying to add the layer. These are the steps we took:
We also tested this w/o the auth plugin and AGO was able to add the layer and pull data. Is there a way to get more error/log information on AGO side? |
Ok, I think the issue is that AGO cannot reach your localhost. When you try to add this layer, it's not just the browser code that uses your Koop URL - the browser takes that URL and sends it off to the AGO servers, where it gets used in the authentication dance among other things. If you want to test this locally, you still can - I've done it by using ngrok (the ngrok page is down as of this writing) to generate a url that tunnels to my localhost, then I give the ngrok'd url to AGO. Without something like ngrok, you'll have to deploy your koop instance and expose it so the AGO servers can reach it and make requests. |
I have a service running that has auth turned on and is publicly accessible but I still can't get it to add to AGO. I tried adding the service as an item under "Content" but once I enter the URL, the dialog just hangs with the message The service is running here so maybe you can try it and let us know if it looks like it is behaving correctly: |
Thanks @jkerr5. Unfortunately, something appears to have changed. Possibly with the AGO auth pattern, but I am not sure. No requests are failing, but yes, it fails to proceed. When we developed this, this "fetching" stage was followed by a prompt for username and password. It may be a few weeks before I can personally look into/repair this. If you are interested in debugging, my suggestion is to follow the network traffic when connecting AGO to a secured ArcGIS server service and see what we are missing in Koop. |
When auth is on, koop returns the following:
And then the call to
So, it seems to recognize that it is secured but then nothing else happens. Is that 499 code the correct http response for this? |
It used to be, at least. Do you have access to a genuine ArcGIS Server service that must be authenticated? If so, I would try to add that ArcGIS Server service to AGO and follow the network traffic - see if their is any differences in the responses of the genuine ArcGIS server service compared to Koop service. |
OK, some clues:
This returns with
And then a call to
returns
For my koop service with auth turned on, it does the first call but does not follow up with a call to the If I understand this correctly, if I have a service with this URL
After the call to "checkurl", it should then make a call to
Instead, the dialog just hangs saying "Fetching Service Info...". There are no errors or anything an no further network calls are made. Maybe there's some issue parsing the URL? I'm at a loss at this point unless I can find some documentation on the authentication process. |
When you add your Koop service to AGO, always do so with the layer, and use the Feature server endpoints that include I think this may do the trick; many arcgis clients will fail if they don't see |
OK, I will try that but other secured services work without doing that so I
really don't understand what it doesn't like about the koop services. I
compared responses and response headers and I really can't see a difference.
…On Wed, Apr 1, 2020 at 3:36 PM Rich Gwozdz ***@***.***> wrote:
When you add your Koop service to AGO, always do so with the layer, and
use the Feature server endpoints that include rest/services in the path:
https://coronavirus-marklogic-featureservice.azurewebsites.net/marklogic//rest/services/GDeltExample/FeatureServer/0
I think this may do the trick; many arcgis clients will fail if they don't
see rest/services in url.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#178 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAB7YASZCZF6X6CFXZF5YXTRKM7O5ANCNFSM4LU3QXAA>
.
|
Let me know. I do believe the content of the service URL is the issue. In your test of a working service notice the url contains |
It looks like that is it! I have two serviceURLs that work and they both contain |
Yes, sorry for the doc omission. I think it's only been lightly used, otherwise this probably would have come up. This is the reason those |
No problem. Thanks for the help! |
Is it possible to secure koop feature services and use them with ArcGIS online? We tried with the @koopjs/auth-direct-file auth plugin but it doesn't seem to work.
The text was updated successfully, but these errors were encountered: