Re: [Archivesspace_Users_Group] Startup error with ArchivesSpace v3.3.1/aspace-oauth plugin

[David P. Steelman]

Tom,

Thanks for the suggestion. If I understand you correctly, the suggestion is
to  modify the "Gemfile.lock" file on the "aspace-oauth" gem to change the
"public_suffix" version to 4.0.6.

I gave it a try, and made the following changes to the "Gemfile.lock" file
(and reran the "initialize-plugin.sh" script), and was able to start
ArchivesSpace without error:

* "public_suffix (4.0.7)" to "public_suffix (4.0.6)"
* "addressable (2.8.1)" to "addressable (2.8.0)"
* "public_suffix (>= 2.0.2, < 6.0)" to "public_suffix (>= 2.0.2, < 5.0)"

I wonder, though, if the actual issue is something deeper. The
"addressable"/"public_suffix" gem versions are specified in the following
files of the ArchivesSpace v3.3.1 source code:

* Gemfile.lock (addressable v2.7.0, public_suffix v4.0.6)
* frontend/Gemfile.lock (addressable v2.8.0, public_suffix v4.0.6)
* public/Gemfile.lock (addressable v2.8.0, publix_suffix v4.0.6)

Also, the "backend/Gemfile" specifies the "rubyXL" v3.4.18 gem, which has a
transitive dependency in its "Gemfile.lock" file (
https://github.com/weshatheleopard/rubyXL/blob/v3.4.18/Gemfile.lock) on the
public_suffix v4.0.6 and addressable v2.8.0 gems.

This problem does not seem to occur in our previous version (v3.1.1),
because the addressable v2.80 and public_suffix v4.0.6 gems were provided
in the "gems/gems" directory of the ArchivesSpace v3.1.1 binary
distribution, but are not provided in the v3.3.1 binary distribution.

Since at least one gem (rubyXL) in the ArchiveSpace source code appears to
rely on the addressable/public_suffix gems, should they be included in the
"gems/gems" directory of the ArchivesSpace binary distribution?

Thanks for all the help,

David

On Tue, Dec 6, 2022 at 3:47 PM Tom Hanstra  wrote:

> Try updating the Gemfile.lock to use the 4.0.6 version of the gem and then
> run the initialize_plugin script. I'm pretty sure that was how I got around
> the issue at one point.
>
> You just need to get the plugin bundled. Version does not matter (in my
> experience).
>
> Tom
>
> On Tue, Dec 6, 2022 at 3:03 PM David P. Steelman  wrote:
>
>> Thanks for the quick responses.
>>
>> I have tried using aspace-oauth v3.2.0, and am running the
>> 'initialize_plugin" script, and still receiving the same error.
>>
>> On the server, there is a
>> "plugins/aspace-oauth/gems/cache/public_suffix-4.0.7.gem" file, and a
>> "plugins/aspace-oauth/gems/gems/public_suffix-4.0.7" directory, so the
>> "aspace-oauth" gem appears to be using the "public_suffix:4.0.7" gem
>>
>> The "WEB-INF/Gemfile.lock" file in the "public.war" and "frontend.war"
>> WAR files from the ArchivesSpace distribution each contain a reference to
>> "public_suffix" v4.0.6.
>>
>> In the ArchivesSpace v3.3.1 source distribution there are references to
>> "plugin_suffix:4.0.6" in the following files:
>>
>> * Gemfile.lock
>> * docs/Gemfile.lock
>> * frontend/Gemfile.lock
>> * public/Gemfile.lock
>>
>> So I'm wondering if there is some kind of confusion about which version
>> of the gem is supposed to be used.
>>
>> Thanks,
>>
>> David
>>
>> On Tue, Dec 6, 2022 at 2:55 PM Tom Hanstra  wrote:
>>
>>> There was a version of the aspace-oauth plugin in which the
>>> public_suffix gem did not compile. I remember having some problems with
>>> that.
>>>
>>> I just rebuilt mine here and it looks like the current version is
>>> working right, with the 4.0.7 version. So it may help to simply download
>>> again.
>>>
>>> Tom
>>>
>>> On Tue, Dec 6, 2022 at 2:19 PM Blake Carver 
>>> wrote:
>>>
>>>> Try using the latest tag version on that plugin.
>>>>
>>>>
>>>>  https://github.com/lyrasis/aspace-oauth/tags
>>>> --
>>>> *From:* archivesspace_users_group-boun...@lyralists.lyrasis.org <
>>>> archivesspace_users_group-boun...@lyralists.lyrasis.org> on behalf of
>>>> David P. Steelman 
>>>> *Sent:* Tuesday, December 6, 2022 2:02 PM
>>>> *To:* Archivesspace Users Group <
>>>> archivesspace_users_group@lyralists.lyrasis.org>
>>>> *Subject:* [Archivesspace_Users_Group] Startup error with
>>>> ArchivesSpace v3.3.1/aspace-oauth plugin
>>>>
>>>> Hello all,
>>>>
>>>> In attempting to upgrad

Re: [Archivesspace_Users_Group] Startup error with ArchivesSpace v3.3.1/aspace-oauth plugin

[David P. Steelman]

Thanks for the quick responses.

I have tried using aspace-oauth v3.2.0, and am running the
'initialize_plugin" script, and still receiving the same error.

On the server, there is a
"plugins/aspace-oauth/gems/cache/public_suffix-4.0.7.gem" file, and a
"plugins/aspace-oauth/gems/gems/public_suffix-4.0.7" directory, so the
"aspace-oauth" gem appears to be using the "public_suffix:4.0.7" gem

The "WEB-INF/Gemfile.lock" file in the "public.war" and "frontend.war" WAR
files from the ArchivesSpace distribution each contain a reference to
"public_suffix" v4.0.6.

In the ArchivesSpace v3.3.1 source distribution there are references to
"plugin_suffix:4.0.6" in the following files:

* Gemfile.lock
* docs/Gemfile.lock
* frontend/Gemfile.lock
* public/Gemfile.lock

So I'm wondering if there is some kind of confusion about which version of
the gem is supposed to be used.

Thanks,

David

On Tue, Dec 6, 2022 at 2:55 PM Tom Hanstra  wrote:

> There was a version of the aspace-oauth plugin in which the public_suffix
> gem did not compile. I remember having some problems with that.
>
> I just rebuilt mine here and it looks like the current version is working
> right, with the 4.0.7 version. So it may help to simply download again.
>
> Tom
>
> On Tue, Dec 6, 2022 at 2:19 PM Blake Carver 
> wrote:
>
>> Try using the latest tag version on that plugin.
>>
>>
>>  https://github.com/lyrasis/aspace-oauth/tags
>> ------
>> *From:* archivesspace_users_group-boun...@lyralists.lyrasis.org <
>> archivesspace_users_group-boun...@lyralists.lyrasis.org> on behalf of
>> David P. Steelman 
>> *Sent:* Tuesday, December 6, 2022 2:02 PM
>> *To:* Archivesspace Users Group <
>> archivesspace_users_group@lyralists.lyrasis.org>
>> *Subject:* [Archivesspace_Users_Group] Startup error with ArchivesSpace
>> v3.3.1/aspace-oauth plugin
>>
>> Hello all,
>>
>> In attempting to upgrade from ArchivesSpace v3.1.1 to v3.3.1, I am
>> encountering the following error on startup:
>>
>> 
>>   Dec 05, 2022 8:23:43 PM
>> org.eclipse.jetty.server.handler.ContextHandler$Context log
>>   WARNING: ERROR: initialization failed
>>   org.jruby.rack.RackInitializationException: Could not find
>> public_suffix-4.0.6 in any of the sources
>>   from
>> /apps/aspace/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/spec_set.rb:86:in
>> `block in materialize'
>>   from org/jruby/RubyArray.java:2621:in `map!'
>>   from
>> /apps/aspace/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/spec_set.rb:80:in
>> `materialize'
>>   from
>> /apps/aspace/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/definition.rb:170:in
>> `specs'
>>   ...
>> 
>>
>> We are using the "aspace-oauth" plugin (
>> https://github.com/lyrasis/aspace-oauth) -- if we remove this plugin
>> from the configuration the error does not occur.
>>
>> Comparing the ArchivesSpace v3.1.1 distribution to v3.3.1, the
>> "gems/gems" directory in the v3.3.1 distribution includes significantly
>> fewer gems, and no longer includes a "public_suffix-3.0.6" directory.
>>
>> Any pointers in handling this issue are appreciated.
>>
>> Thanks,
>>
>> David
>> ___
>> Archivesspace_Users_Group mailing list
>> Archivesspace_Users_Group@lyralists.lyrasis.org
>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>>
>
>
> --
> *Tom Hanstra*
> *Sr. Systems Administrator*
> hans...@nd.edu
>
>
> ___
> 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

[Archivesspace_Users_Group] Startup error with ArchivesSpace v3.3.1/aspace-oauth plugin

[David P. Steelman]

Hello all,

In attempting to upgrade from ArchivesSpace v3.1.1 to v3.3.1, I am
encountering the following error on startup:


  Dec 05, 2022 8:23:43 PM
org.eclipse.jetty.server.handler.ContextHandler$Context log
  WARNING: ERROR: initialization failed
  org.jruby.rack.RackInitializationException: Could not find
public_suffix-4.0.6 in any of the sources
  from
/apps/aspace/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/spec_set.rb:86:in
`block in materialize'
  from org/jruby/RubyArray.java:2621:in `map!'
  from
/apps/aspace/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/spec_set.rb:80:in
`materialize'
  from
/apps/aspace/archivesspace/gems/gems/bundler-2.1.4/lib/bundler/definition.rb:170:in
`specs'
  ...


We are using the "aspace-oauth" plugin (
https://github.com/lyrasis/aspace-oauth) -- if we remove this plugin from
the configuration the error does not occur.

Comparing the ArchivesSpace v3.1.1 distribution to v3.3.1, the "gems/gems"
directory in the v3.3.1 distribution includes significantly fewer gems, and
no longer includes a "public_suffix-3.0.6" directory.

Any pointers in handling this issue are appreciated.

Thanks,

David
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] Archivesspace and Java 11

[David P. Steelman]

Eric,

It wasn't clear if your question was specifically about Java 11, or just on
Oracle Java vs OpenJDK.

I can't speak to Java 11, but we've been running ArchivesSpace (v2.7.0 and
then v2.7.1) on our production server with OpenJDK v8 since December and
have not encountered any issues. Also, while Oracle Java v8 is no longer
receiving public updates, the OpenJDK v8 still is (and is expected to for
several more years).

Hope this helps,

David



On Mon, Oct 19, 2020 at 3:24 PM Gadsby, Eric T.  wrote:

> Dear Friends,
>
>
>
> Good afternoon. I hope today finds you well and in good spirits.  Last
> week our library met with our central IT services and they informed us that
> our institution will not be adopting paid Java.  I know (perhaps not as
> well as I should) that there are Java components in Aspace.  Is Aspace
> going to require we get a license for our server or can it use the openSKD
> or is it simply not an issue?  I look forward hearing what the groups
> thoughts or understanding of the situation are. Thanks!
>
>
>
>
>
>
>
> [image: Towson University logo] 
>
> *Eric T. Gadsby*
>
> *Pronouns: he/him/his*
>
> IT Operations Specialist  |  Albert S. Cook Library
>
> *—*
>
> P: 410-704-3340
>
> SMS: ‪443-338-3792
> egad...@towson.edu  |  libraries.towson.edu
> 
>  *—*
>
>
>
> Confidentiality Notice: This message may contain information that is
> confidential, privileged, proprietary, or otherwise legally exempt from
> disclosure. If you are not the intended recipient, you are notified that
> you are not authorized to read, print, copy or disseminate this message,
> any part of it, or any attachments. If this message has been sent to you in
> error, please notify the sender by replying to this transmission, or by
> calling Albert S. Cook Library at 410-704-3340 .
>
>
> ___
> 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

Re: [Archivesspace_Users_Group] ArchivesSpace RESTful API authentication and access

[David P. Steelman]

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 
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 
> *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 
> *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 
> *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

[Archivesspace_Users_Group] ArchivesSpace RESTful API authentication and access

[David P. Steelman]

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

Re: [Archivesspace_Users_Group] Containerised ArchivesSpace in production

[David P. Steelman]

Joshua,

I think the Dockerfile(s) might be of general interest to the list, if they
are something that can be safely distributed.

I, for one, would be especially interested in the production Dockerfile.

Thanks

David

On Mon, Sep 28, 2020 at 1:53 PM Joshua D. Shaw 
wrote:

> Hi Peter
>
> We are running AS in docker containers for everything from local
> development to production. Happy to share our dockerfile and put you in
> touch with our sysadmin if you'd like.
>
> Joshua
>
> --
> *From:* archivesspace_users_group-boun...@lyralists.lyrasis.org <
> archivesspace_users_group-boun...@lyralists.lyrasis.org> on behalf of
> Peter Heiner 
> *Sent:* Friday, September 25, 2020 12:21 PM
> *To:* archivesspace_users_group@lyralists.lyrasis.org <
> archivesspace_users_group@lyralists.lyrasis.org>
> *Subject:* [Archivesspace_Users_Group] Containerised ArchivesSpace in
> production
>
> Dear list,
>
> For want of a better list to send this, I have a few questions regarding
> running ArchivesSpace containerised. List archives suggest this has not
> been brought up in a while and it was exactly a year ago that Laney
> McGlohon added words to docs/user/docker.md reading 'Docker is not
> supported as an install method'. Whilst I believe I have a pretty good
> idea of at least some of the answers, I think it might be useful to know
>
>  - if people run it in production using containers all the same;
>  - what the developers think the obstacles are to it being supported as
>containerised workload;
>  - what they think needs to happen for it to become supported;
>  - what can the community do to advance this.
>
> I currently maintain several Docker-based development and staging
> instances and several other systems including user training and
> production systems that run bare, and it would be lovely to be able to
> optimise the latter away, so my interest in this is not at all academic.
>
> Thanks,
> p
> ___
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group@lyralists.lyrasis.org
>
> https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Flyralists.lyrasis.org%2Fmailman%2Flistinfo%2Farchivesspace_users_group&data=02%7C01%7Cjoshua.d.shaw%40dartmouth.edu%7C510f06d7fe1547411e8708d8616f11f6%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637366476964122557&sdata=f5lCBvZG4FTw7qNj%2FZmj2s1%2FWxFuXgPTF%2FEAVKvv0WI%3D&reserved=0
> ___
> 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