[dspace-tech] Re: AIP import - bug or my error?

2023-07-28 Thread Chris Clawson 
Thanks Tim,
But I don't see any option with the  -R restore command to direct the 
import to a new collection. The original collection no longer exists, so 
how will the restore -r command work if the target collection no longer 
exists?  My Wordpress site still refers to this old item and it's URI. I 
prefer to direct it to a specific (and new) collection, but don't care too 
much where it goes because I can always move it around later. I do need to 
keep the item URI to respect the references elsewhere.

On Wednesday, July 26, 2023 at 2:45:48 PM UTC-4 DSpace Technical Support 
wrote:

> Hi Chris,
>
> I think you might be missing the "-r" flag to tell the packager command 
> that you want to use *restore* mode.  This will also default to setting 
> "ignoreHandle=false", so that option shouldn't be needed.  See the 
> instructions at 
> https://wiki.lyrasis.org/display/DSDOC7x/AIP+Backup+and+Restore#AIPBackupandRestore-DefaultRestoreMode
>
> By default, if you don't specify "-r", then it defaults to "submit" mode 
> which tries to assign a new URI.  For more on the differences between 
> Submit & Restore, see this section of the docs:  
> https://wiki.lyrasis.org/display/DSDOC7x/AIP+Backup+and+Restore#AIPBackupandRestore-IngestionModes
>
> That said, it does seem like the "ignoreHandle=false" option should have 
> also worked with your command.  Not sure why it would not have worked, but 
> you also may want to check the logs to see if there were errors reported.
>
> Tim
>
> On Tuesday, July 25, 2023 at 6:31:09 PM UTC-5 Chris Clawson wrote:
>
>> I just attempted to import an item that had been exported and deleted. I 
>> wish to import it back to a new collection but want to preserve the 
>> original and full handle. The importer imports the item only as new, 
>> seemingly ignoring the -o option. 
>> The example:
>> /opt/dspace/bin/dspace packager -o ignoreHandle=false -t AIP -e 
>> ch...@mydomain.org -p MHS-01376/6742 /home/chris/it...@mhs-01376-5381.zip
>> A new item is created as MHS-01376-6855 and then added to my expected 
>> collection. I want to keep the MHS-01376-5381 URI.
>>
>> I refer to this old URI in my wordpress site and don't want to run around 
>> my blog posts and rename many occurrences of these newly restored items. I 
>> have tried both "false" and "true" -o options, but neither restores the 
>> original handle,  using this command.
>> Might somebody correct me, please? (This handle has not need reassigned 
>> in my existing db).
>> DSpace 7.6
>>
>

-- 
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/dc41b12b-7e51-4b35-9dfb-2178fe41cf3dn%40googlegroups.com.

Re: [dspace-tech] Re: DSpace 7.5 - status:401 exception: Access is denied

2023-07-28 Thread Sascha Szott 

Hi Karol,

did you checked the requests to /metadata-import and /metadata-export 
are issued when you access the start page of your DSpace instance?


Currently, we see two 401 requests everytime we open the home page of 
our DSpace instance. We are running DSpace 7.5 / CRIS 2023.01. We are 
not able to reproduce this behaviour in the public DSpace demo instances.


The backend response is

{
"timestamp": "2023-07-28T16:32:41.705+00:00",
"status": 401,
"error": "Unauthorized",
"message": "Authentication is required",
"path": "/server/api/system/scripts/metadata-import"
}

{
"timestamp": "2023-07-28T16:32:41.691+00:00",
"status": 401,
"error": "Unauthorized",
"message": "Authentication is required",
"path": "/server/api/system/scripts/metadata-export"
}

We have no idea how to configure the system properly and disable the 
requests.


Best
Sascha


Am 28.07.23 um 16:56 schrieb DSpace Technical Support:

Hi Karol,

A 401 HTTP code / exception means that the client is unauthorized (not 
authenticated).  So, that large number of logs appears to be someone 
which is attempting to access those REST API endpoints without being 
authenticated.   Perhaps your login timed out while you were trying to 
run an export or import (from either the UI or REST API)?  Or, do you 
maybe have a custom script calling these export/import scripts which is 
failing to authenticate?  It also could be some sort of bot/crawler 
which is trying to crawl your REST API and stumbled on these endpoints.  
  It's really difficult to say for certain where the requests came from 
without more details about what you (or others) might have been doing at 
the time.


These are *not* errors in DSpace though. The 401 HTTP Code just means 
that someone tried to do something in DSpace which required 
authentication, and DSpace stopped them from doing it.


Tim

On Friday, July 28, 2023 at 7:57:07 AM UTC-5 karols...@gmail.com wrote:

Hi,

I'm back with a problem that is causing a large increase in logs. I
have a very large number of queries from my own server (api), I
can't find why this is happening. Can I ask for some guidance on how
to diagnose which process or user is generating these queries?

MyIP- - [28/Jul/2023:14:53:41 +0200] "GET
/server/api/system/scripts/metadata-export HTTP/1.1" 401 965 "-"
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:41 +0200] "GET
/server/api/system/scripts/metadata-import HTTP/1.1" 401 965 "-"
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:43 +0200] "GET
/server/api/system/scripts/metadata-export HTTP/1.1" 401 1514 "-"
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:43 +0200] "GET
/server/api/system/scripts/metadata-import HTTP/1.1" 401 1514 "-"
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:44 +0200] "GET
/server/api/system/scripts/metadata-export HTTP/1.1" 401 1514 "-"
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:44 +0200] "GET
/server/api/system/scripts/metadata-import HTTP/1.1" 401 1514 "-"
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:47 +0200] "GET
/server/api/system/scripts/metadata-export HTTP/1.1" 401 965 "-"
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:47 +0200] "GET
/server/api/system/scripts/metadata-import HTTP/1.1" 401 965 "-"
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:51 +0200] "GET
/server/api/system/scripts/metadata-export HTTP/1.1" 401 1514 "-"
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:51 +0200] "GET
/server/api/system/scripts/metadata-import HTTP/1.1" 401 1514 "-"
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:53 +0200] "GET
/server/api/system/scripts/metadata-import HTTP/1.1" 401 1514 "-"
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:53 +0200] "GET
/server/api/system/scripts/metadata-export HTTP/1.1" 401 1514 "-"
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:55 +0200] "GET
/server/api/system/scripts/metadata-import HTTP/1.1" 401 1514 "-"
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:55 +0200] "GET
/server/api/system/scripts/metadata-export HTTP/1.1" 401 1514 "-"
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:56 +0200] "GET
/server/api/system/scripts/metadata-export HTTP/1.1" 401 965 "-"
"Mozilla/5.0 (Linux x64)

[dspace-tech] Re: Menu anomaly - DSpace 7.6

2023-07-28 Thread DSpace Technical Support 
Hi Wally,

I think the behavior you are seeing is "expected behavior" (but I agree 
it's quite confusing... and we do want to find a way to improve it for the 
future).

The "Statistics" link in the header is a dynamic link which only appears in 
a few pages:
* On the homepage it links to site-wide statistics (i.e. statistics for the 
Site "object")
* On a Community/Collection/Item page it will link to statistics for that 
object *only*

The "Statistics" link currently doesn't appear on any browse/search pages, 
as those pages don't represent an "object" on which statistics can be 
gathered on.

Looking at our issue tracker, I see that others have reported this as a bug 
already: https://github.com/DSpace/dspace-angular/issues/1392   It's 
waiting on a volunteer though to find a better way to provide access to 
these "Statistics" without having a link in the header that potentially 
changes based on the page you are on.

Tim

On Thursday, July 27, 2023 at 2:19:27 PM UTC-5 Wally Grotophorst wrote:

> I see this in my local testbed 7.6 site and on the 
> https://demo7.dspace.org/home site as well.  To replicate the issue:
>
> After home page loads, click statistics from the top level menu
> The statistics page loads but Statistics is no longer on the main menu
> Click any other top-level menu option (e.g., Communities or All of DSpace)
> You never get the statistic menu item appearing again
>
> I don't know if this was introduced in 7.6 or if it is in older 7.x 
> releases as well
>
> Wally Grotophorst
> George Mason University
>

-- 
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/f7b76aed-ee08-418b-b9bd-b703ec30ea42n%40googlegroups.com.

[dspace-tech] Re: http in API responses (blocked as mixed content)

2023-07-28 Thread DSpace Technical Support 
Hi Matyas,

This sounds like it could be related to this "Common Installation 
Issue": 
https://wiki.lyrasis.org/display/DSDOC7x/Installing+DSpace#InstallingDSpace-MyRESTAPIisrunningunderHTTPS,butsomeofits%22link%22URLsareswitchingtoHTTP

Check the recommendations there and see if they have any impact.

Tim

On Friday, July 28, 2023 at 6:51:07 AM UTC-5 matyas...@gmail.com wrote:

> Hi Team,
>
> please could you help us with installation - setting the access to https 
> only.
>
> We have backend and frontend on the same server (eduo.osu.cz), backend 
> calls are redirected by apache proxy to localhost:8080 tomcat port.
>
> In local.cfg, we have set: dspace.server.url = https://eduo.osu.cz/server
>
> When I open the DSpace homepage, primary API calls are correct, like
> https://eduo.osu.cz/server/api   [HTTP/1.1 200  75ms]
>
> Still, the API calls that contain uri parameter, like
>
>
> https://eduo.osu.cz/server/api/authz/authorizations/search/object?uri=http://eduo.osu.cz/server/api/core/sites/0f53bf85-4114-4307-9813-d1cbeea2cf33=isCollectionAdmin=feature
>
> have http:// protocol in the uri argument value. These requests are 
> blocked by API/backend:
>
> # curl 
> '
> http://localhost:8080/server/api/authz/authorizations/search/object?uri=http://eduo.osu.cz/server/api/core/sites/0f53bf85-4114-4307-9813-d1cbeea2cf33=isCollectionAdmin=feature
> '
> {"timestamp":"2023-07-28T11:40:05.876+00:00","status":400,"error":"Bad 
> Request","message":"Request is invalid or 
> incorrect","path":"/server/api/authz/authorizations/search/object"}[root@eduard
>  
>
> config]#
>
> If I manually change the ?uri to uri=https://..., I get the correct API 
> answer:
>
>
> https://eduo.osu.cz/server/api/authz/authorizations/search/object?uri=https://eduo.osu.cz/server/api/core/sites/0f53bf85-4114-4307-9813-d1cbeea2cf33=isCollectionAdmin=feature
> OR
> curl 
> '
> http://localhost:8080/server/api/authz/authorizations/search/object?uri=https://eduo.osu.cz/server/api/core/sites/0f53bf85-4114-4307-9813-d1cbeea2cf33=isCollectionAdmin=feature
> '
> {
>   "_links" : {
> "self" : {
>   "href" : 
> "
> http://localhost:8080/server/api/authz/authorizations/search/object?uri=https://eduo.osu.cz/server/api/core/sites/0f53bf85-4114-4307-9813-d1cbeea2cf33=isCollectionAdmin
> "
> } ... ...
>
>
> Please, don't you have any idea, which settings etc. causes the "http:" 
> in uri argument, or how to change it to https?
>
>
> Thank you a lot in advance for any response!
>
> Best!
>
> Matyas F. Bajger
>
> library systems administrator
> University of Ostrava - University Library
> https://library.osu.eu
>
>

-- 
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/819ad4a5-558d-4f9c-9d18-0829508a0080n%40googlegroups.com.

[dspace-tech] Re: DSpace 7.5 - status:401 exception: Access is denied

2023-07-28 Thread DSpace Technical Support 
Hi Karol,

A 401 HTTP code / exception means that the client is unauthorized (not 
authenticated).  So, that large number of logs appears to be someone which 
is attempting to access those REST API endpoints without being 
authenticated.   Perhaps your login timed out while you were trying to run 
an export or import (from either the UI or REST API)?  Or, do you maybe 
have a custom script calling these export/import scripts which is failing 
to authenticate?  It also could be some sort of bot/crawler which is trying 
to crawl your REST API and stumbled on these endpoints.   It's really 
difficult to say for certain where the requests came from without more 
details about what you (or others) might have been doing at the time.

These are *not* errors in DSpace though. The 401 HTTP Code just means that 
someone tried to do something in DSpace which required authentication, and 
DSpace stopped them from doing it. 

Tim

On Friday, July 28, 2023 at 7:57:07 AM UTC-5 karols...@gmail.com wrote:

> Hi,
>
> I'm back with a problem that is causing a large increase in logs. I have a 
> very large number of queries from my own server (api), I can't find why 
> this is happening. Can I ask for some guidance on how to diagnose which 
> process or user is generating these queries?
>
> MyIP- - [28/Jul/2023:14:53:41 +0200] "GET 
> /server/api/system/scripts/metadata-export HTTP/1.1" 401 965 "-" 
> "Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
> MyIP- - [28/Jul/2023:14:53:41 +0200] "GET 
> /server/api/system/scripts/metadata-import HTTP/1.1" 401 965 "-" 
> "Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
> MyIP- - [28/Jul/2023:14:53:43 +0200] "GET 
> /server/api/system/scripts/metadata-export HTTP/1.1" 401 1514 "-" 
> "Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
> MyIP- - [28/Jul/2023:14:53:43 +0200] "GET 
> /server/api/system/scripts/metadata-import HTTP/1.1" 401 1514 "-" 
> "Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
> MyIP- - [28/Jul/2023:14:53:44 +0200] "GET 
> /server/api/system/scripts/metadata-export HTTP/1.1" 401 1514 "-" 
> "Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
> MyIP- - [28/Jul/2023:14:53:44 +0200] "GET 
> /server/api/system/scripts/metadata-import HTTP/1.1" 401 1514 "-" 
> "Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
> MyIP- - [28/Jul/2023:14:53:47 +0200] "GET 
> /server/api/system/scripts/metadata-export HTTP/1.1" 401 965 "-" 
> "Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
> MyIP- - [28/Jul/2023:14:53:47 +0200] "GET 
> /server/api/system/scripts/metadata-import HTTP/1.1" 401 965 "-" 
> "Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
> MyIP- - [28/Jul/2023:14:53:51 +0200] "GET 
> /server/api/system/scripts/metadata-export HTTP/1.1" 401 1514 "-" 
> "Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
> MyIP- - [28/Jul/2023:14:53:51 +0200] "GET 
> /server/api/system/scripts/metadata-import HTTP/1.1" 401 1514 "-" 
> "Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
> MyIP- - [28/Jul/2023:14:53:53 +0200] "GET 
> /server/api/system/scripts/metadata-import HTTP/1.1" 401 1514 "-" 
> "Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
> MyIP- - [28/Jul/2023:14:53:53 +0200] "GET 
> /server/api/system/scripts/metadata-export HTTP/1.1" 401 1514 "-" 
> "Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
> MyIP- - [28/Jul/2023:14:53:55 +0200] "GET 
> /server/api/system/scripts/metadata-import HTTP/1.1" 401 1514 "-" 
> "Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
> MyIP- - [28/Jul/2023:14:53:55 +0200] "GET 
> /server/api/system/scripts/metadata-export HTTP/1.1" 401 1514 "-" 
> "Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
> MyIP- - [28/Jul/2023:14:53:56 +0200] "GET 
> /server/api/system/scripts/metadata-export HTTP/1.1" 401 965 "-" 
> "Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
> MyIP- - [28/Jul/2023:14:53:56 +0200] "GET 
> /server/api/system/scripts/metadata-import HTTP/1.1" 401 965 "-" 
> "Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
> MyIP- - [28/Jul/2023:14:53:56 +0200] "GET 
> /server/api/system/scripts/metadata-import HTTP/1.1" 401 965 "-" 
> "Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
>
> and much more line like this ...
>
> Thanks,
>
> Karol
>
>
>
>
> czwartek, 13 lipca 2023 o 21:33:56 UTC+2 Karol napisał(a):
>
>> Hi,
>>
>> editors report incidental problems to me:
>>
>> 1) when depositing items sometimes there is a problem with automatic 
>> "saving changes" or manual 
>> 2) sometimes "loading dots" appear on the screen when moving to the next 
>> step or editing, and so on until you refresh the page, go to the home page 
>> and log in again.
>>
>> [image: Screenshot from 2023-07-13 21-29-57.png]
>>
>>  3) Sometimes when editing item metadata and trying to save changes 
>>
>> [image: Screenshot from

[dspace-tech] Re: DSpace 7.5 - status:401 exception: Access is denied

2023-07-28 Thread Karol 
Hi,

I'm back with a problem that is causing a large increase in logs. I have a 
very large number of queries from my own server (api), I can't find why 
this is happening. Can I ask for some guidance on how to diagnose which 
process or user is generating these queries?

MyIP- - [28/Jul/2023:14:53:41 +0200] "GET 
/server/api/system/scripts/metadata-export HTTP/1.1" 401 965 "-" 
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:41 +0200] "GET 
/server/api/system/scripts/metadata-import HTTP/1.1" 401 965 "-" 
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:43 +0200] "GET 
/server/api/system/scripts/metadata-export HTTP/1.1" 401 1514 "-" 
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:43 +0200] "GET 
/server/api/system/scripts/metadata-import HTTP/1.1" 401 1514 "-" 
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:44 +0200] "GET 
/server/api/system/scripts/metadata-export HTTP/1.1" 401 1514 "-" 
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:44 +0200] "GET 
/server/api/system/scripts/metadata-import HTTP/1.1" 401 1514 "-" 
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:47 +0200] "GET 
/server/api/system/scripts/metadata-export HTTP/1.1" 401 965 "-" 
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:47 +0200] "GET 
/server/api/system/scripts/metadata-import HTTP/1.1" 401 965 "-" 
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:51 +0200] "GET 
/server/api/system/scripts/metadata-export HTTP/1.1" 401 1514 "-" 
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:51 +0200] "GET 
/server/api/system/scripts/metadata-import HTTP/1.1" 401 1514 "-" 
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:53 +0200] "GET 
/server/api/system/scripts/metadata-import HTTP/1.1" 401 1514 "-" 
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:53 +0200] "GET 
/server/api/system/scripts/metadata-export HTTP/1.1" 401 1514 "-" 
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:55 +0200] "GET 
/server/api/system/scripts/metadata-import HTTP/1.1" 401 1514 "-" 
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:55 +0200] "GET 
/server/api/system/scripts/metadata-export HTTP/1.1" 401 1514 "-" 
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:56 +0200] "GET 
/server/api/system/scripts/metadata-export HTTP/1.1" 401 965 "-" 
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:56 +0200] "GET 
/server/api/system/scripts/metadata-import HTTP/1.1" 401 965 "-" 
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
MyIP- - [28/Jul/2023:14:53:56 +0200] "GET 
/server/api/system/scripts/metadata-import HTTP/1.1" 401 965 "-" 
"Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"

and much more line like this ...

Thanks,

Karol




czwartek, 13 lipca 2023 o 21:33:56 UTC+2 Karol napisał(a):

> Hi,
>
> editors report incidental problems to me:
>
> 1) when depositing items sometimes there is a problem with automatic 
> "saving changes" or manual 
> 2) sometimes "loading dots" appear on the screen when moving to the next 
> step or editing, and so on until you refresh the page, go to the home page 
> and log in again.
>
> [image: Screenshot from 2023-07-13 21-29-57.png]
>
>  3) Sometimes when editing item metadata and trying to save changes 
>
> [image: Screenshot from 2023-07-13 21-25-40.png]
>
>
> I asked them to save the error hour and checked in the logs. I found 
> something like this:
>
> *org.dspace.app.rest.exception.DSpaceApiExceptionControllerAdvice @ 
> Authentication is required (status:401 exception: Access is denied at: 
> org.springframework.security.access.vote.AffirmativeBased.decide(AffirmativeBased.java:73))*
>
> Everything happens sometimes. I have the impression that as long as they 
> deposit an item, or long work logged into the repository. It looks like 
> there is a problem with the session because the editors have admin access ( 
> after logging in everything works ). Does anyone have similar problems and 
> is there any way to fix this?
>
> Greetings,
>
> Karol
>

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

[dspace-tech] http in API responses (blocked as mixed content)

2023-07-28 Thread Matyas F. Bajger 

Hi Team,

please could you help us with installation - setting the access to https 
only.


We have backend and frontend on the same server (eduo.osu.cz), backend 
calls are redirected by apache proxy to localhost:8080 tomcat port.


In local.cfg, we have set: dspace.server.url = https://eduo.osu.cz/server

When I open the DSpace homepage, primary API calls are correct, like
https://eduo.osu.cz/server/api   [HTTP/1.1 200  75ms]

Still, the API calls that contain uri parameter, like

https://eduo.osu.cz/server/api/authz/authorizations/search/object?uri=http://eduo.osu.cz/server/api/core/sites/0f53bf85-4114-4307-9813-d1cbeea2cf33=isCollectionAdmin=feature

have http:// protocol in the uri argument value. These requests are 
blocked by API/backend:


# curl 
'http://localhost:8080/server/api/authz/authorizations/search/object?uri=http://eduo.osu.cz/server/api/core/sites/0f53bf85-4114-4307-9813-d1cbeea2cf33=isCollectionAdmin=feature'
{"timestamp":"2023-07-28T11:40:05.876+00:00","status":400,"error":"Bad 
Request","message":"Request is invalid or 
incorrect","path":"/server/api/authz/authorizations/search/object"}[root@eduard 
config]#


If I manually change the ?uri to uri=https://..., I get the correct API 
answer:


https://eduo.osu.cz/server/api/authz/authorizations/search/object?uri=https://eduo.osu.cz/server/api/core/sites/0f53bf85-4114-4307-9813-d1cbeea2cf33=isCollectionAdmin=feature
    OR
curl 
'http://localhost:8080/server/api/authz/authorizations/search/object?uri=https://eduo.osu.cz/server/api/core/sites/0f53bf85-4114-4307-9813-d1cbeea2cf33=isCollectionAdmin=feature'

{
  "_links" : {
    "self" : {
  "href" : 
"http://localhost:8080/server/api/authz/authorizations/search/object?uri=https://eduo.osu.cz/server/api/core/sites/0f53bf85-4114-4307-9813-d1cbeea2cf33=isCollectionAdmin;

    } ... ...


Please, don't you have any idea, which settings etc. causes the "http:" 
in uri argument, or how to change it to https?



Thank you a lot in advance for any response!

Best!

Matyas F. Bajger

library systems administrator
University of Ostrava - University Library
https://library.osu.eu

--
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/55b039c0-b998-bcbb-363f-b57a06599d44%40seznam.cz.