Not sure if your issue is the same I ran into when I got this error, but to solve I did the following:

1. In the Eclipse installer, click the 'Network' button (it's next to the ? Help button in the lower tool bar.)

2. Make sure your Active Provider setting is set to Direct. By default, the installer was set to Manual I think and after I changed to Direct, I was able to read the repository.

Thanks Robert, I understand. I ended up solving this another way anyway... I realized I did not have my REST Dispatch Web App sharing the same cookies path as my main web app so even though I was logging in with authorized credentials that should have no problem running this query, when I tried to execute it via REST I passed into another 'cookie domain' and lost the authorization header.

Once I fixed that setting, it works just fine for the users it should and I don't have to grant Unknown User elevated privileges, which is ideal.


Thanks again!

Thanks for your answer, Robert. I had considered the option of using a 'Privileged Application' and after your post, have started down that path but that still leaves open my original question...

How do I determine what resource/privilege is required to execute this query?  %Developer does not work. 

Is there documentation I'm missing in the API reference or elsewhere that indicates the necessary permissions needed to make certain calls? I only wish to grant the minimum necessary but right now, only %All makes it work. Is there some sort of debug I can use to see what role it's running a $SYSTEM.Security.Check on when it tries to execute this query?

Awesome, this is exactly what I was looking for! Thank you. I was getting close with %Get and the iterator but wasn't quite making the connection with the whole line.LineNumber part.



Thanks for your answer as well! This is actually what we were already doing with 2015.1 when handling JSON. So moving into 2017.1, I was hoping to make more use of the built-in JSON handlers because the JSON response I posted was a rather simple one - some of our more complex responses has our string manipulations getting quite long-in-the-tooth.