Block users from accessing ArcGIS.com

[DanSmith27]

When creating an app for someone, it would be great if they could somehow be limited to only viewing the app, rather than logging in to ArcGIS.com with their username and seeing all of the content behind the app. 

[BernSzukalski]

Check out this help topic: https://doc.arcgis.com/en/arcgis-online/share-maps/share-items.htm

Privately sharing within a group might solve your issue.

[KenBuja]

This is something I'd like to solve also.

My use case that I've created an app in Web AppBuilder with a custom widget. This widget restricts how a user can edit data in a hosted feature layer, only allowing certain options for that user. The feature layer has to be shared with the user for this to work.

Even though I've only given users the URL of the app itself, some users have enough knowledge to directly access the feature layer in AGOL and edit the layer directly, bypassing the editing restrictions

[MartínGonzález]

Please we need that functionality as soon as possible.

We have a hosted layer with data on jobs done by contractors and we have a filtered dashboard for each contractor.

But if a contractor logs into AGOL with his username can see the information of other contractors simply by accessing the layer that uses the dashboard.

Is there another solution other than creating 15 views of the hosted layer and 15 identical dashboards?

[DanSmith27]

@BernSzukalski  - Sharing to a group does not solve the issue - we need to block people from seeing the ArcGIS.com landing page all together - @MartínGonzález gives a good example of the issue as well. I want a user to only see their app - no other views on ArcGIS.com. If they have a username and search the link given to them for the app instead of putting it in their URL bar- the search result directs them to ArcGIS.com, where they log in and get confused because they don't see their app. They see the dashboard landing screen of ArcGIS.com. @KenBuja also gives a good example.

[BernSzukalski]

@DanSmith27 It is possible to completely mask off a contractor or volunteer from all organization content by creating a custom role and placing the contractor in a private group with _only_ what you want that contractor to see and use in that group. I actually just prototyped this the other week for a non-profit that wanted to have a couple of volunteers as members in their org to use Survey123 but did not want them to see any other content within the organization. It does work (though with a couple of minor caveats WRT JSAPI 4.X and public sharing).

Though I've not exercised all possibilities, this should cascade out to what's visible on the Home page and throughout the sharing /Online ecosystem. But public things are public, and always discoverable. I'll see if I can exercise this quickly on my ArcGIS Online Labs home page.

[BernSzukalski]

@DanSmith27 I still had the custom role set up for my test user and just took a look at this using my home page. Only public content is visible to this user on my Home page after they sign in, or if I had shared only the content in their private group on the home page they would see that as well. No organization content is visible. This include groups.

And to be clear, I am not opposed to this idea, just trying to find something you might find workable now. 

[MartínGonzález]

In our case it is not about hiding a layer or not from the logged in user.
Rather, it is related to the data in the same layer.

The tractors and machines that work in the field send information that we receive with geoevent and post-process with spatial analysis geoprocesses, generating areas and activities worked.
The result of this process is shown in a dashboard filtered by contractor.
But we have the security problem that we mentioned in the previous post.

We need a more efficient way to protect each contractor's information.

Unlike the information created in BernSzukalski's example, in our case the information is generated by the server and not by the user.
In the case that the information is generated by the user, there are filters in the Feature Layer, so that users can see their own data and not others.

But as I mentioned before, the information is generated by a centralized process in our case and we can't use that option.

It would be great to be able to block user access to the feature layer used by the dashboard,
this would protect the information and that it can only be accessed from an app, in our case with ArcGIS Dashboards.

[CMV_Erik]

I've been using the information in this article to work around this for a few years: How To: Limit access to secured hosted services or map services in ArcGIS Online for public-facing w... Not the most intuitive solution, but seems to get the job done.

Basically, it creates an ArcGIS Online item that a) points back to the original layer, b) has a username/password saved that can see that layer and c) is limited to only be open-able by URLs you specify.

• After you configure the map and app, limit the layer's access to just the app's URL. After that, the map will not display the layer if you open in directly, but the layer WILL show normally in the app. 
• Once it's configured, the end user sees the new "layer" as an AGOL feature service, but they'll get an error if they try to see the data.

[DylanKennard-tt]

@BernSzukalski as the ESRI rep on the forum idea has this made any progress or thoughts?

I think it's key that people can only access the APP front end. This is how it use to be with ArcServer before Portal and AGOL. The App Link is provided. Then the App itself uses a Service Account to access all the underlying map services, etc. This setup has been around for 20+ years. With Portal and AGOL this simple, but super important, architecture was removed.

To reimplement that 20+ year old theory in the modern ESRI Enterprise Pattern it could be as simple as:

1) Make a Group

2) Group configuration is "Let Group Members Access these item types:"

1) App

2) Map

3) Data Items

4) You then just check on the boxes you want the group to access.

Issue: We have users that we give access to the App. They then accidently go to the main AGOL URL, start messing with items, make goofy maps, then call and complain they cannot see xyz, the app doesn't work, etc but it's because they had access to all the items and just went nuts. This then creates a negative view of ESIR, GIS Staff, etc because we are wrong but they went and mangled it all up. GIS is a science not "for everyone"

Fundamental Issue: I firmly believe ESRI needs to stop pushing "everyone can make maps". It's belittling and no other field out there says "Everyone can be a biologist bird observer or a train engineer". If ESRI stops thinking that way then addressing a feature like this would move into a top priority. 

[DylanKennard-tt]

I made an updated post to hopefully re-surface this idea and get some Kudos and attention from ESRI for the road map.

https://community.esri.com/t5/arcgis-online-ideas/block-users-from-accessing-the-items-that-create/i...