I was able to find the endpoints in the list by searching for ".permissions([])", for example in archivesspace/backend/app/controllers/agent_family.rb:
Endpoint.get('/agents/families') .description("List all family agents") .params() .paginated(true) .permissions([]) .returns([200, "[(:agent_family)]"]) \ do handle_listing(AgentFamily, params) end The permissions on this code (and several other classes) were set when the ".nopermissionsyet" scaffolding was replaced about 7 years ago in https://github.com/archivesspace/archivesspace/commit/ff972d222b91a005f6514ba1d30cd772f8b674c4 So it has been this way for quite a while. David On Tue, Sep 29, 2020 at 12:19 PM Joshua D. Shaw <joshua.d.s...@dartmouth.edu> wrote: > I think this is an unintended consequence of the PUI. > > In > https://github.com/archivesspace/archivesspace/blob/master/backend/app/model/group.rb > there is a PUBLIC_GROUP_CODE which is name 'publicanonymous' which is > granted view_repository rights - presumably so that the PUI can function. > > I'm guessing that that specific user should be explicitly *excluded* in > the RESTHelpers module or maybe the User class where the permissions are > actually calculated. > > Joshua > > ------------------------------ > *From:* archivesspace_users_group-boun...@lyralists.lyrasis.org < > archivesspace_users_group-boun...@lyralists.lyrasis.org> on behalf of > Custer, Mark <mark.cus...@yale.edu> > *Sent:* Tuesday, September 29, 2020 12:15 PM > *To:* Archivesspace Users Group < > archivesspace_users_group@lyralists.lyrasis.org> > *Subject:* Re: [Archivesspace_Users_Group] ArchivesSpace RESTful API > authentication and access > > I'm curious if this has always been the case, as well, but it would seem > like it has been. I knew that the repository and location endpoints > could be accessed but didn't try any of the rest for some inexplicable > reason. Not good to have agent contact details available that way. > > Given which endpoints are available, I wonder if this has to do with the > concept of the 'global' repository in ArchivesSpace, to which all agents, > subjects, locations, etc., belong? If so, it seems like that should be > something that could (and should!) be locked down. > > But, as you mention, Joshua, a very good reason to have further > restrictions on access to the API endpoints... but in this case, I > wouldn't think that should be necessary at all. > > ------------------------------ > *From:* archivesspace_users_group-boun...@lyralists.lyrasis.org < > archivesspace_users_group-boun...@lyralists.lyrasis.org> on behalf of > Joshua D. Shaw <joshua.d.s...@dartmouth.edu> > *Sent:* Tuesday, September 29, 2020 11:54 AM > *To:* Archivesspace Users Group < > archivesspace_users_group@lyralists.lyrasis.org> > *Subject:* Re: [Archivesspace_Users_Group] ArchivesSpace RESTful API > authentication and access > > That's a *very* interesting find! I had naively believed the docs that > indicated that most of the endpoints required authentication without > actually trying to bounce off a random endpoint without a token. > > The controllers indicate that there should be permissions involved and > that they should be tied to user roles, but that is obviously not the case. > FYI - This issue has been around since at least 2.5.0 (I tested against > 2.5.0, 2.7.1 and 2.80 running locally). > > For what it's worth, we have additional firewall rules in place (for other > reasons) that limit access to the backend to only a select few IPs. That > doesn't address the actual problem but is a workaround if you have the > resources. > > Joshua > > ------------------------------ > *From:* archivesspace_users_group-boun...@lyralists.lyrasis.org < > archivesspace_users_group-boun...@lyralists.lyrasis.org> on behalf of > David P. Steelman <dstee...@umd.edu> > *Sent:* Tuesday, September 29, 2020 11:36 AM > *To:* Archivesspace Users Group < > archivesspace_users_group@lyralists.lyrasis.org> > *Subject:* [Archivesspace_Users_Group] ArchivesSpace RESTful API > authentication and access > > I've been investigating providing access to the ArchivesSpace RESTful API > to an expanded group of users. > > Through testing, it appears that many of the RESTful API endpoints (see > below) do not require user authentication (i.e., do not require a "session" > key), and access apparently cannot be controlled through the ArchivesSpace > permission infrastructure. > > While the information provided by most of these endpoints might be > considered "public", some (such as information from the "agents" endpoints) > could contain names and contact information that might be considered > sensitive. > > Is the inability to control access to these endpoints via the > ArchivesSpace permissions infrastructure intentional? Is there some way to > control access to these endpoints that I'm missing? > > A (non-exhaustive) list of the endpoints that will return information to > anything that can reach them: > > /agents/corporate_entities - List all corporate entity > /agents/corporate_entities/:id - Get a corporate entity by ID > /agents/families - List all family agents > /agents/families/:id - Get a family by ID > /agents/people - List all person agents > /agents/people/:id - Get a person by ID > /agents/software - List all software agents > /agents/software/:id - Get a software agent by ID > /container_profiles - Get a list of Container Profiles > /container_profiles/:id - Get a Container Profile by ID > /config/enumerations - List all defined enumerations > /config/enumerations/:enum_id - Get an Enumeration > /config/enumerations/names/:enum_name - Get an Enumeration by Name > /config/enumeration_values/:enum_val_id - Get an Enumeration Value > /repositories/:repo_id/archival_contexts/people/:id.xml - Get an EAC-CPF > representation of an Agent > /repositories/:repo_id/archival_contexts/people/:id.:fmt/metadata - Get > metadata for an EAC-CPF export of a person > /repositories/:repo_id/archival_contexts/corporate_entities/:id.xml - Get > an EAC-CPF representation of a Corporate Entity > /repositories/:repo_id/archival_contexts/corporate_entities/:id.:fmt/metadata > - Get metadata for an EAC-CPF export of a corporate entity > /repositories/:repo_id/archival_contexts/families/:id.xml - Get an EAC-CPF > representation of a Family > /repositories/:repo_id/archival_contexts/families/:id.:fmt/metadata - Get > metadata for an EAC-CPF export of a family > /repositories/:repo_id/archival_contexts/softwares/:id.xml - Get an > EAC-CPF representation of a Software agent > /repositories/:repo_id/archival_contexts/softwares/:id.:fmt/metadata - Get > metadata for an EAC-CPF export of a software > /job_types - List all supported job types > /repositories/:repo_id/jobs/import_types - List all supported import job > types > /location_profiles - Get a list of Location Profiles > /location_profiles/:id - Get a Location Profile by ID > /search/location_profile - Search across Location Profile > /locations - Get a list of locations > /locations/:id - Get a Location by ID > /notifications - Get a stream of notifications > /oai_config - Get the OAI Config record > /permissions - Get a list of Permissions > /repositories/:repo_id/preferences/defaults - Get the default set of > Preferences for a Repository and optionally a user > /repositories/:repo_id/rde_templates/:id - Get an RDE template record > /repositories/:repo_id/rde_templates - Get a list of RDE Templates > /reports - List all reports > /repositories/with_agent/:id - Get a Repository by ID, including its agent > representation > /repositories/:id - Get a Repository by ID > /repositories - Get a list of Repositories > /schemas - Get all ArchivesSpace schemas > /schemas/:schema - Get an ArchivesSpace schema > /search/repositories - Search across repositories > /search/subjects - Search across subjects > /space_calculator/buildings - Get a Location by ID > /subjects - Get a list of Subjects > /subjects/:id - Get a Subject by ID > /terms - Get a list of Terms matching a prefix > /users - Get a list of users > /users/complete - Get a list of system users > /version - Get the ArchivesSpace application version > /vocabularies - Get a list of Vocabularies > /vocabularies/:id/terms - Get a list of Terms for a Vocabulary > /vocabularies/:id - Get a Vocabulary by ID > > Thanks, > > David > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group@lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >
_______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group@lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group