Re: [Archivesspace_Users_Group] log4j vulnerability in ArchivesSpace?

2021-12-14 Thread Steele, Henry
It uses JRuby

On Dec 14, 2021, at 11:19 AM, Steele, Henry  wrote:

 I’m not sure who supports this now—HM?—, but I wanted to check about the Yale 
EAD exporter’s potential vulnerability.   It’s a plug-in but also has a stand 
alone application




On Dec 13, 2021, at 2:01 PM, Blake Carver  wrote:


Nope, older versions should be safe as well.

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 on behalf of Steele, 
Henry 
Sent: Monday, December 13, 2021 1:52 PM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] log4j vulnerability in ArchivesSpace?


Are people on earlier versions of ArchivesSpace , e.g. 2.7.1 that use 
archivesspace’s internal solr vulnerable?



From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 On Behalf Of Peter 
Heiner
Sent: Saturday, December 11, 2021 9:00 AM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] log4j vulnerability in ArchivesSpace?



While ArchivesSpace itself might not be vulnerable, those who run an extrrnal 
Solr instance should be aware that it itself may be, see 
https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228
 for more information and some possible workarounds.



p



From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 on behalf of Tom Hanstra mailto:hans...@nd.edu>>
Sent: 11 December 2021 13:21
To: Archivesspace Users Group 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] log4j vulnerability in ArchivesSpace?



There is a lot of buzz right now about the log4j exploit being used against 
Java applications. Does anyone know if ArchivesSpace is vulnerable to these 
exploits?



Tom

--

Tom Hanstra

Sr. Systems Administrator

hans...@nd.edu



[https://docs.google.com/uc?export=download&id=1GFX1KaaMTtQ2Kg2u8bMXt1YwBp96bvf0&revid=0B7APN9POn6xAQ244WWFYMFU3aVJwZ0lxbmVHK3FxNXlCd0RRPQ]

___
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] log4j vulnerability in ArchivesSpace?

2021-12-14 Thread Steele, Henry
I’m not sure who supports this now—HM?—, but I wanted to check about the Yale 
EAD exporter’s potential vulnerability.   It’s a plug-in but also has a stand 
alone application




On Dec 13, 2021, at 2:01 PM, Blake Carver  wrote:


Nope, older versions should be safe as well.

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 on behalf of Steele, 
Henry 
Sent: Monday, December 13, 2021 1:52 PM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] log4j vulnerability in ArchivesSpace?


Are people on earlier versions of ArchivesSpace , e.g. 2.7.1 that use 
archivesspace’s internal solr vulnerable?



From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 On Behalf Of Peter 
Heiner
Sent: Saturday, December 11, 2021 9:00 AM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] log4j vulnerability in ArchivesSpace?



While ArchivesSpace itself might not be vulnerable, those who run an extrrnal 
Solr instance should be aware that it itself may be, see 
https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228
 for more information and some possible workarounds.



p



From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 on behalf of Tom Hanstra mailto:hans...@nd.edu>>
Sent: 11 December 2021 13:21
To: Archivesspace Users Group 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] log4j vulnerability in ArchivesSpace?



There is a lot of buzz right now about the log4j exploit being used against 
Java applications. Does anyone know if ArchivesSpace is vulnerable to these 
exploits?



Tom

--

Tom Hanstra

Sr. Systems Administrator

hans...@nd.edu



[https://docs.google.com/uc?export=download&id=1GFX1KaaMTtQ2Kg2u8bMXt1YwBp96bvf0&revid=0B7APN9POn6xAQ244WWFYMFU3aVJwZ0lxbmVHK3FxNXlCd0RRPQ]

___
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] API-only users?

2021-12-14 Thread Peter Heiner
Andrew Morrison wrote on 2021-12-14 13:27:13:
> Does anyone know if there is a way set up an ArchivesSpace user so they can
> query the API but they are blocked from logging-in to the staff interface?

My understanding is that this is not possible.

ArchivesSpace does not expose any way to limit users to API or UI access only,
neither using its permissions model or the authentication source used. It also
cannot make authorisation decisions on information provided by the backend as
it is commonly done, among others, using LDAP group membership information.

This means that once you can authenticate, you get access based on whatever
permissions are assigned to your user in the database.

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


Re: [Archivesspace_Users_Group] Query re search functionality - ArchivesSpace 3.1

2021-12-14 Thread Joshua D. Shaw
Hey Andrew

Pretty sure this does affect the typeahead sort (at least in the 3.x series). 
The 2.8.x were a bit buggy about this and I know I had to override the sort in 
an init for those for some types (definitely agents).

jds


From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 on behalf of Andrew 
Morrison 
Sent: Tuesday, December 14, 2021 8:22 AM
To: archivesspace_users_group@lyralists.lyrasis.org 

Subject: Re: [Archivesspace_Users_Group] Query re search functionality - 
ArchivesSpace 3.1


I don't think user preferences affect the drop-down displayed when you start 
typing. That's hardcoded to sort by title (I agree that relevance would be 
better.)


You could try prefixing with a Solr index field name. For example, to only list 
resources which have the word cheese in their title, not elsewhere, enter 
title:cheese in the Resource field.


How many hits you get back will also be influenced by the value of 
AppConfig[:solr_params] in your config.rb file. If your system isn't set up 
with 'q.op' => 'AND', or 'mm' => '100%', then the more terms you add the more 
hits you'll get. You can add + or - to terms to specify whether they must, or 
must not, be present for a record to match. For example +title:tennis 
-title:golf will list only records with titles containing the word tennis, 
excluding any whose titles contain the word golf.


Andrew.




On 14/12/2021 12:32, Joshua D. Shaw wrote:
Hi Isobel

In versions 2.8.0 (maybe 2.8.1) forward, there are additional options to set 
browse/search sort order that also affect the typeaheads. Go to the dropdown by 
your username in the top right and set the default sort column and direction in 
either the global or repo settings (depends on your need).

The sort column & direction defaults to title, ascending for pretty much 
everything which makes it really hard to find things in the typeaheads. I think 
the default should probably have been relevance, descending which is what I've 
set ours to.

Hope that helps,
Joshua


From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org
 

 on behalf of Isobel Johnstone 
Sent: Monday, December 13, 2021 8:00 PM
To: 'Archivesspace Users Group' 

Subject: [Archivesspace_Users_Group] Query re search functionality - 
ArchivesSpace 3.1


Hi all,



We’re in the process of upgrading from ArchivesSpace 2.1.2 to ArchivesSpace 
3.1.1. We’ve noticed some differences in search functionality, notably when 
searching for Resources/Accessions in Top Containers (“Manage Top Containers” 
–> searching in the “Resource” or “Accession” fields).



e.g. Searching by Identifier or Title in our current instance brings up the 
relevant collection at the top search result; when we perform the same searches 
in AS 3.1, the relevant collection appears very low down the dropdown list of 
search results, or not at all. Searching in inverted commas doesn’t make a 
noticeable difference.



Has anyone else experienced this? And any tips about how to improve the search 
results?



Thanks for your help,

Isobel





Dr Isobel Johnstone  | Archival Processing team | Collection Management | 
National Library of Australia



The National Library of Australia (NLA) acknowledges Australia’s First Nations 
Peoples – the First Australians – as the Traditional Owners and Custodians of 
this land and gives respect to the Elders – past and present – and through them 
to all Australian Aboriginal and Torres Strait Islander people.

[A close up of a logo 
Description automatically 
generated]



nla.gov.au

+61 (02) 6262 

Parkes Pl, Canberra ACT 2600



[A picture containing drawing Description automatically 
generated]

[Archivesspace_Users_Group] API-only users?

2021-12-14 Thread Andrew Morrison

Hello,

Does anyone know if there is a way set up an ArchivesSpace user so they 
can query the API but they are blocked from logging-in to the staff 
interface?


Thanks,

Andrew.


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


Re: [Archivesspace_Users_Group] Query re search functionality - ArchivesSpace 3.1

2021-12-14 Thread Andrew Morrison
I don't think user preferences affect the drop-down displayed when you 
start typing. That's hardcoded to sort by title (I agree that relevance 
would be better.)



You could try prefixing with a Solr index field name. For example, to 
only list resources which have the word /cheese/ in their title, not 
elsewhere, enter /title:cheese/ in the Resource field/./


/
/

How many hits you get back will also be influenced by the value of 
/AppConfig[:solr_params]/ in your config.rb file. If your system isn't 
set up with 'q.op' => 'AND', or 'mm' => '100%', then the more terms you 
add the more hits you'll get. You can add + or - to terms to specify 
whether they must, or must not, be present for a record to match. For 
example /+title:tennis -title:golf/ will list only records with titles 
containing the word /tennis,/ excluding any whose titles contain the 
word /golf/.



Andrew.




On 14/12/2021 12:32, Joshua D. Shaw wrote:

Hi Isobel

In versions 2.8.0 (maybe 2.8.1) forward, there are additional options 
to set browse/search sort order that also affect the typeaheads. Go to 
the dropdown by your username in the top right and set the default 
sort column and direction in either the global or repo settings 
(depends on your need).


The sort column & direction defaults to title, ascending for pretty 
much everything which makes it really hard to find things in the 
typeaheads. I think the default should probably have been relevance, 
descending which is what I've set ours to.


Hope that helps,
Joshua


*From:* archivesspace_users_group-boun...@lyralists.lyrasis.org 
 on behalf of 
Isobel Johnstone 

*Sent:* Monday, December 13, 2021 8:00 PM
*To:* 'Archivesspace Users Group' 

*Subject:* [Archivesspace_Users_Group] Query re search functionality - 
ArchivesSpace 3.1


Hi all,

We’re in the process of upgrading from ArchivesSpace 2.1.2 to 
ArchivesSpace 3.1.1. We’ve noticed some differences in search 
functionality, notably when searching for Resources/Accessions in *Top 
Containers* (“Manage Top Containers” –> searching in the “Resource” or 
“Accession” fields).


e.g. Searching by Identifier or Title in our current instance brings 
up the relevant collection at the top search result; when we perform 
the same searches in AS 3.1, the relevant collection appears very low 
down the dropdown list of search results, or not at all. Searching in 
inverted commas doesn’t make a noticeable difference.


Has anyone else experienced this? And any tips about how to improve 
the search results?


Thanks for your help,

Isobel

Dr Isobel Johnstone  | Archival Processing team | Collection 
Management | National Library of Australia


The National Library of Australia (NLA) acknowledges Australia’s First 
Nations Peoples – the First Australians – as the Traditional Owners 
and Custodians of this land and gives respect to the Elders – past and 
present – and through them to all Australian Aboriginal and Torres 
Strait Islander people.


A close up of a logo Description automatically generated 







*nla.gov.au* 



*+61 (02) 6262 *

*Parkes Pl, Canberra ACT 2600*

A picture containing drawing Description automatically generated 
**A 
picture containing gear, ware Description automatically generated 
**A 
picture containing drawing, light Description automatically gener

Re: [Archivesspace_Users_Group] ASpace API - Query by Location Barcode?

2021-12-14 Thread Andrew Morrison
The /search/repositories endpoint searches for repositories, so 
filtering that to only return locations will always return no hits. To 
search globally, say for a location with a barcode of 123456789, you 
could use something like this:



/search?q=123456789&page=1&page_size=100&type[]=location


All search endpoints return Solr documents. If you want guaranteed 
up-to-date location records, sourced from the MySQL database, extract 
the "uri" from the matched Solr docs, and send GET requests for each.



Andrew.



On 13/12/2021 23:04, Joshua D. Shaw wrote:
I don't see a specific endpoint for location by barcode, but I think 
you could hit the generic search endpoint with the following. It's 
going to show all locations that match that particular string, so not 
guaranteed that you'll only get one result.

|/search/repositories?|filter_term[]={"primary_type"%3A"location"}&q={MY_BARCODE}&sort=score+desc
This is across all repos, so you could also limit to a specific repo 
by|/repositories/{REPO_ID}/search?|filter_term[]={"primary_type"%3A"location"}&q={MY_BARCODE}&sort=score+desc

Joshua

*From:* archivesspace_users_group-boun...@lyralists.lyrasis.org 
 on behalf of 
Matthew Adair 

*Sent:* Monday, December 13, 2021 3:27 PM
*To:* Archivesspace Users Group 

*Subject:* [Archivesspace_Users_Group] ASpace API - Query by Location 
Barcode?
Maybe I just haven't figured it out yet, but is there a way in the API 
to return information about a Location by searching by it's barcode?


Thanks,
- Matt

*
Matthew Adair*
Lead Archivist for Digital Imaging and Infrastructure
/[Due to working remotely, email is the best method to reach me.]
/
/
/

Bentley Historical Library
1150 Beal Avenue
Ann Arbor, Michigan 48109-2113
734-647-3537
http://bentley.umich.edu
@UmichBentley 



/The Bentley Historical Library acknowledges that coerced cessions of 
land by the Anishnaabeg and Wyandot made the University of Michigan 
possible, and we seek to reaffirm the ancestral and contemporary ties 
of these peoples to the lands where the University now stands./


___
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] Query re search functionality - ArchivesSpace 3.1

2021-12-14 Thread Joshua D. Shaw
Hi Isobel

In versions 2.8.0 (maybe 2.8.1) forward, there are additional options to set 
browse/search sort order that also affect the typeaheads. Go to the dropdown by 
your username in the top right and set the default sort column and direction in 
either the global or repo settings (depends on your need).

The sort column & direction defaults to title, ascending for pretty much 
everything which makes it really hard to find things in the typeaheads. I think 
the default should probably have been relevance, descending which is what I've 
set ours to.

Hope that helps,
Joshua


From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 on behalf of Isobel 
Johnstone 
Sent: Monday, December 13, 2021 8:00 PM
To: 'Archivesspace Users Group' 

Subject: [Archivesspace_Users_Group] Query re search functionality - 
ArchivesSpace 3.1


Hi all,



We’re in the process of upgrading from ArchivesSpace 2.1.2 to ArchivesSpace 
3.1.1. We’ve noticed some differences in search functionality, notably when 
searching for Resources/Accessions in Top Containers (“Manage Top Containers” 
–> searching in the “Resource” or “Accession” fields).



e.g. Searching by Identifier or Title in our current instance brings up the 
relevant collection at the top search result; when we perform the same searches 
in AS 3.1, the relevant collection appears very low down the dropdown list of 
search results, or not at all. Searching in inverted commas doesn’t make a 
noticeable difference.



Has anyone else experienced this? And any tips about how to improve the search 
results?



Thanks for your help,

Isobel





Dr Isobel Johnstone  | Archival Processing team | Collection Management | 
National Library of Australia



The National Library of Australia (NLA) acknowledges Australia’s First Nations 
Peoples – the First Australians – as the Traditional Owners and Custodians of 
this land and gives respect to the Elders – past and present – and through them 
to all Australian Aboriginal and Torres Strait Islander people.

[A close up of a logo  Description automatically 
generated]



nla.gov.au

+61 (02) 6262 

Parkes Pl, Canberra ACT 2600



[A picture containing drawing  Description automatically 
generated]
   [A picture containing gear, ware  Description automatically generated] 

[A picture containing drawing, light  Description automatically generated] 

[A close up of a logo  Description automatically generated] 

[A picture containing drawing  Description automatically generated]