I was exploring LayerAccessSOI java sample.
Attached the LayerAccessSOI to SampleWorldCities map service, when accessed the map service in ArcGIS REST Services Directory...
Before Login - "Layers" section was not showing any layers, this is the correct behaviour.
After Login - "Layers" section was still not showing any (authorized) layers, seems there is something wrong.
When I DEBUG the SOI for "After Login" scenario the "userName" is getting empty for the below lines of code.
IServerUserInfo userInfo = ServerUtilities.getServerUserInfo();
String userName = userInfo.getName();
Please refer to the attachment.
Did any body experienced this? Can help?
Edit:
- I checked the LayerAccessSOI .Net sample, it has no issues.
- For .Net, every page refresh on the map service rest directory was triggering handleRESTRequest method. But it's not the case with Java sample.
Solved! Go to Solution.
Implementing layer-level access control
If you implement layer level-access control through an SOI, you'll also need to configure ArcGIS Server's REST handler to disable caching of all layer resources included the service.
This will allow you to intercept operations and filter out layers which are not allowed. You can disable this by setting the service's disableCaching property to true in the ArcGIS Server Administrator Directory.
when you are in "after login" you are sure to be in the right trigger because every request passes there handleRESTRequest no matter what you are doing
Implementing layer-level access control
If you implement layer level-access control through an SOI, you'll also need to configure ArcGIS Server's REST handler to disable caching of all layer resources included the service.
This will allow you to intercept operations and filter out layers which are not allowed. You can disable this by setting the service's disableCaching property to true in the ArcGIS Server Administrator Directory.
when you are in "after login" you are sure to be in the right trigger because every request passes there handleRESTRequest no matter what you are doing
Hi Domenico,
Thanks for your reply.
As mentioned under "EDIT" in my question, the .Net LayerAccessSOI sample working as expected, but the issue is only with Java LayerAccessSOI sample.
After doing the below, Java sample also working as expected. Thank you Domenico.
In the properties section of the service JSON, add the disableCaching property and set its value to true, for example: "properties": { ... "disableCaching": "true", ... }
Note: Without doing the above, .Net sample was working fine.
Hi Domenico,
With dotnet sample also we got the same issue. Upon setting "properties": { ... "disableCaching": "true", ... } ,mapservice rest URLS work fine. While debugging the SOI code, we can see the logged in user id is getting passed to SOI. But the same does not hold true for FeatureServer and KMLServer URL. When intercepted in SOI the user ID is always NULL. We tried to apply "properties": { ... "disableCaching": "true", ... } on all capabilities one by one but to no use.
Understand that Layer Level access control works on Mapserver along with all capabilities (e.g. Feature Access, KMLServer and OGC services). Please correct me if I am wrong.
Thanks,
Pankaj Roy
Hi All,
With dotnet sample also we got the same issue. Upon setting "properties": { ... "disableCaching": "true", ... } ,mapservice rest URLS work fine. While debugging the SOI code, we can see the logged in user id is getting passed to SOI. But the same does not hold true for FeatureServer and KMLServer URL. When intercepted in SOI the user ID is always NULL. We tried to apply "properties": { ... "disableCaching": "true", ... } on all capabilities one by one but to no use.
Understand that Layer Level access control works on Mapserver along with all capabilities (e.g. Feature Access, KMLServer and OGC services). Please correct me if I am wrong.
Hi All,
ESRI Inc. has acknowledged that SOI is currently limited to dynamic map service along with WMS capability only. It does not work for Feature access, WFS and KML services. They will very soon reflect this limitation in their documentation.
Hi,
7 years have passed since then
Tested on version 10.9.1 Full-Patched
Tested on version 11.1 Full-Patched
Still in Feature access return null for UserInfo.Name from ServerUtilities.GetServerEnvironment();