Re: [dspace-tech] DSpace 7 Wrong "unsafe:hdl" pemanent URIs for communities and collections

['Tim Donohue' via DSpace Technical Support]

Hi,

If I recall correctly, I believe Angular automatically adds "unsafe:" before 
any URL which is not a valid URL.  So, that'd imply to me that these 
Community/Collection URLs are possibly being saved as "hdl:123456789/2" and the 
Angular UI tries to display them as links, which causes Angular to display them 
as "unsafe:hdl:1234356789/2".

So, it sounds to me like somehow the import process is having trouble 
transforming "hdl:123456789/2" (which is how it's stored in an AIP) into 
"https://repo.com/handle/123456789/2;.   It might be something as simple as 
having a misconfigured "handle.canonical.prefix" or "handle.prefix" setting in 
your local.cfg (or dspace.cfg).  Or, maybe there's some other error occurring 
during the import?

There are a few options I can think of.

  *   You might try the import again (a re-import should simply replace the 
existing objects .. overwriting them.)  If you do this, you may want to pay 
close attention to your dspace.log files to see if any errors appear there.  
Also make sure "handle.canonical.prefix" and "handle.prefix" are set correctly 
first.  This is the easiest approach
  *   Or, at the database level, you could modify the "dc.identifier.uri" 
metadata field to have the correct value. You'd have to first determine the 
"metadata_field_id" of that field from metadatafieldregistry (e.g. select * 
from metadatafieldregistry where element='identifier' and qualifier='uri';)   
Then, you'd need to update the "text_value" values of that field in the 
"metadatavalue" table.  I don't have an exact query for that one, you should 
see "text_value" values that start with "hdl:" when you really want this field 
to be a full URL.

Others on this list might think of additional options, but those are the two 
fixes that I immediately think of.  Technically, the import process should be 
transforming these values into full URLs, but it's unclear to me why that isn't 
working correctly in this case.  I'm hoping that if you simply correct the 
"handle.*" configs (if they are incorrect) and try again, it might work.

Good luck and let us know on this list if you need more help.

Tim


From: dspace-tech@googlegroups.com  on behalf of 
P Z 
Sent: Friday, August 5, 2022 11:02 AM
To: DSpace Technical Support 
Subject: [dspace-tech] DSpace 7 Wrong "unsafe:hdl" pemanent URIs for 
communities and collections

Hello everyone. After data migration from one DSpace 7.1 (Windows) instance to 
another with same version, in the another instance the permanent URI links are 
generated wrong (the ones informed in frontend to the user through 
communityPayload.handle and collection.handle variables) . Instead a proper, 
real URL such as https://repo.com/handle/123456879/2 (say for instance), the 
resulting link for these migrated communities and collections is 
unsafe:hdl:123456789/2 . Migrated article links are right. And with 
communities/collections/articles newly created after migration, their links are 
also right.

For the wrong "unsafe:hdl" links, how could I fix it? (preferably without 
wiping/reloading DB)

Thanks in advance.

(
Command line used for export:
dspace packager -d -a -t AIP -e ad...@xxx.xxx -i 123456789/0 output.zip

And for import:
dspace packager -r -a -f -t AIP -e  ad...@xxx.xxx  -i 123456789/0 -o 
skipIfParentMissing=true c:\output.zip
)

--
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
---
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/46e30b83-95aa-4b23-9f72-c55e0980f509n%40googlegroups.com.

-- 
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/PH0PR22MB3274443FA011DE6DAFB146A5ED9E9%40PH0PR22MB3274.namprd22.prod.outlook.com.

[dspace-tech] DSpace 7 Wrong "unsafe:hdl" pemanent URIs for communities and collections

[P Z]

Hello everyone. After data migration from one DSpace 7.1 (Windows) instance 
to another with same version, in the another instance the permanent URI 
links are generated wrong (the ones informed in frontend to the user 
through communityPayload.handle and collection.handle variables) . Instead 
a proper, real URL such as https://repo.com/handle/123456879/2 (say for 
instance), the resulting link for these migrated communities and 
collections is unsafe:hdl:123456789/2 . Migrated article links are right. 
And with communities/collections/articles newly created after migration, 
their links are also right. 

For the wrong "unsafe:hdl" links, how could I fix it? (preferably without 
wiping/reloading DB)

Thanks in advance.

(
Command line used for export:
dspace packager -d -a -t AIP -e ad...@xxx.xxx -i 123456789/0 output.zip

And for import:
dspace packager -r -a -f -t AIP -e  ad...@xxx.xxx  -i 123456789/0 -o 
skipIfParentMissing=true c:\output.zip
)

-- 
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/46e30b83-95aa-4b23-9f72-c55e0980f509n%40googlegroups.com.

Re: [dspace-tech] 401 unauthorized, error occurred during login via ORCID

['Tim Donohue' via DSpace Technical Support]

Hi Lewatle,

You'll find the cause of the error in the log file you shared... Look for the 
"ERROR" lines in your log and you'll find this one:

2022-08-04 11:43:42,124 ERROR unknown unknown 
org.dspace.authenticate.OrcidAuthenticationBean @ An error occurs registering a 
new EPerson from ORCID
java.lang.IllegalStateException: The email is configured private on orcid
  at 
org.dspace.authenticate.OrcidAuthenticationBean.lambda$registerNewEPerson$0(OrcidAuthenticationBean.java:215)
 ~[dspace-api-7.3.jar:7.3]
  at java.util.Optional.orElseThrow(Optional.java:408) ~[?:?]
  at 
org.dspace.authenticate.OrcidAuthenticationBean.registerNewEPerson(OrcidAuthenticationBean.java:215)
 [dspace-api-7.3.jar:7.3]
  at 
org.dspace.authenticate.OrcidAuthenticationBean.authenticateWithOrcid(OrcidAuthenticationBean.java:181)
 [dspace-api-7.3.jar:7.3]
  at 
org.dspace.authenticate.OrcidAuthenticationBean.authenticate(OrcidAuthenticationBean.java:96)
 [dspace-api-7.3.jar:7.3]
  at 
org.dspace.authenticate.OrcidAuthentication.authenticate(OrcidAuthentication.java:82)
 [dspace-api-7.3.jar:7.3]


Notice that the error message says "The email is configured private on orcid".  
The ORCID account you are using MUST share its email address with DSpace.  See 
this Troubleshooting note in the ORCID documentation:
https://wiki.lyrasis.org/display/DSDOC7x/ORCID+Integration#ORCIDIntegration-I'munabletoauthenticateviaORCID

Tim


From: dspace-tech@googlegroups.com  on behalf of 
Lewatle Johannes Phaladi 
Sent: Friday, August 5, 2022 3:15 AM
To: DSpace Technical Support 
Subject: [dspace-tech] 401 unauthorized, error occurred during login via ORCID

Hi DSpace Colleagues,

I am running DSpace version 7.3, followed the following document enabling ORCID 
integration : https://wiki.lyrasis.org/display/DSDOC7x/ORCID+Integration
I am using orcid sandbox also received client id and secret for our server to 
run this integration.
The problem occur when logging in via ORCID  getting 401 unauthorized error, I 
have attached dspace log file with screenshots that might give indication on 
what is happening.

Your assistance is appreciated.

Regards,
Lewatle

--
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
---
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/ffa1c87e-f18b-4710-a38f-b76f9e134372n%40googlegroups.com.

-- 
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/PH0PR22MB3274AB550F6C9935CF471A0CED9E9%40PH0PR22MB3274.namprd22.prod.outlook.com.

[dspace-tech] Dspace 7 archivo config.prod.yml en inglés y español

[Jose Miguel Ravasi]

Hola, estoy iniciandome en Dspace7 y algunos archivos los estoy traduciendo 
a español pues mi inglés es básico; si los tengo en español me resulta más 
ágil.
Les comparto la traducción de las notas del config.prod.yml  y cada uno lo 
puede personalizar
Saludos, 

José Miguel Ravasi


Se encuentra en  
/home/dspace/nombre_directorio_sourceFE/config/config.prod.yml 



# NOTE: will log all redux actions and transfers in console

# NOTA: registrará todas las acciones y transferencias de redux en la 
consola 


debug: false


# Angular Universal server settings

# NOTE: these must be 'synced' with the 'dspace.ui.url' setting in your 
backend's local.cfg.

# NOTA: estos deben estar 'sincronizados' con la configuración 
'dspace.ui.url' en su backend local.cfg


ui:

ssl: false

host: 10.2.8.35 (IP de tu servidor)

port: 4000


# NOTE: Space is capitalized because 'namespace' is a reserved string in 
TypeScript

# NOTA: Space está en mayúsculas porque 'namespace' es una cadena reservada 
en TypeScript


nameSpace: /


# The rateLimiter settings limit each IP to a 'max' of 500 requests per 
'windowMs' (1 minute).

# La configuración de rateLimiter limita cada IP a un 'máximo' de 500 
solicitudes por 'windowMs' (1 minuto)


rateLimiter:

windowMs: 6 # 1 minute

max: 500 # limit each IP to 500 requests per windowMs


# The REST API server settings

# NOTE: these must be 'synced' with the 'dspace.server.url' setting in your 
backend's local.cfg

# NOTA: estos deben estar 'sincronizados' con la configuración 
'dspace.server.url' en su backend local.cfg


ui:

ssl: false

host: 10.2.8.35 (IP de tu servidor)

port: 4000



# NOTE: Space is capitalized because 'namespace' is a reserved string in 
TypeScript

# NOTA: Space está en mayúsculas porque 'namespace' es una cadena reservada 
en TypeScript


nameSpace: /


# The rateLimiter settings limit each IP to a 'max' of 500 requests per 
'windowMs' (1 minute).

# La configuración de rateLimiter limita cada IP a un 'máximo' de 500 
solicitudes por 'windowMs' (1 minuto)


rateLimiter:

windowMs: 6 # 1 minute

max: 500 # limit each IP to 500 requests per windowMs


# The REST API server settings

# NOTE: these must be 'synced' with the 'dspace.server.url' setting in your 
backend's local.cfg

# NOTA: estos deben estar 'sincronizados' con la configuración 
'dspace.server.url' en su backend local.cfg


rest:

ssl: false

host: 10.2.8.35 (IP de tu servidor)

port: 8080


# NOTE: Space is capitalized because 'namespace' is a reserved string in 
TypeScript

# NOTA: Space está en mayúsculas porque 'namespace' es una cadena reservada 
en TypeScript


nameSpace: /server


# Caching settings

cache:


# NOTE: how long should objects be cached for by default

# NOTA: por cuánto tiempo deben almacenarse en caché los objetos de forma 
predeterminada


msToLive:

default: 90 # 15 minutes

control: max-age=60 # revalidate browser

autoSync:

defaultTime: 0

maxBufferSize: 100

timePerMethod:

PATCH: 3 # time in seconds


# Authentication settings


auth:


# Authentication UI settings

ui:


# the amount of time before the idle warning is shown

# la cantidad de tiempo antes de que se muestre la advertencia de 
inactividad

timeUntilIdle: 90 # 15 minutes


# the amount of time the user has to react after the idle warning is shown 
before they are logged out.

# la cantidad de tiempo que el usuario tiene para reaccionar después de que 
se muestra la advertencia de inactividad antes de cerrar la sesión.


idleGracePeriod: 30 # 5 minutes


# Authentication REST settings

rest:

# If the rest token expires in less than this amount of time, it will be 
refreshed automatically.

# El rest token caduca en menos de esta cantidad de tiempo, se actualizará 
automáticamente.

# This is independent from the idle warning.

# Esto es independiente de la advertencia de inactividad.


timeLeftBeforeTokenRefresh: 12 # 2 minutes



# Form settings

form:

# NOTE: Map server-side validators to comparative Angular form validators

validatorMap:

required: required

regex: pattern


# Notification settings

notifications:

rtl: false

position:

- top

- right

maxStack: 8


# NOTE: after how many seconds notification is closed automatically. If set 
to zero notifications are not closed automatically

# NOTA: después de cuántos segundos, la notificación se cierra 
automáticamente. Si se establece en cero, las notificaciones no se cierran 
automáticamente

timeOut: 5000 # 5 second

clickToClose: true

# NOTE: 'fade' | 'fromTop' | 'fromRight' | 'fromBottom' | 'fromLeft' | 
'rotate' | 'scale'

animate: scale


# Submission settings

submission:

autosave:


# NOTE: which metadata trigger an autosave

# NOTA: qué metadatos activan un autoguardado

metadata: []


# NOTE: after how many time (milliseconds) submission is saved automatically

# NOTA: después de cuánto tiempo (milisegundos) el envío se guarda 
automáticamente

# eg. timer: 5 * (1000 

[dspace-tech] Re: 401 unauthorized, error occurred during login via ORCID

[Lewatle Johannes Phaladi]

On Friday, 5 August 2022 at 10:15:01 UTC+2 Lewatle Johannes Phaladi wrote:

> Hi DSpace Colleagues,
>
> I am running DSpace version 7.3, followed the following document enabling 
> ORCID integration : 
> https://wiki.lyrasis.org/display/DSDOC7x/ORCID+Integration 
> I am using orcid sandbox also received client id and secret for our server 
> to run this integration.
> The problem occur when logging in via ORCID  getting 401 unauthorized 
> error, I have attached dspace log file with screenshots that might give 
> indication on what is happening.
>
> Your assistance is appreciated.
>
> Regards,
> Lewatle 
>

-- 
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/f9612652-56c9-438f-ac79-fedc8b2390ecn%40googlegroups.com.