DSpace 7.5 - status:401 exception: Access is denied

[Karol]

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.

 3) Sometimes when editing item metadata and trying to save changes

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

[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

[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

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

> Screenshot from 2023-07-13 21-29-57.png
>
>  3) Sometimes when editing item metadata and trying to save
> changes
>

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

[Karol]

Hi Tim, Sascha,

Tim, it looks like my first entry, is not correlated with the 401 error - it's just a coincidence. I don't have any additional scripts, nor do I see any bots in the logs that are trying to access this content: /server/api/system/scripts/metadata-import

Sascha, it directed me to conduct tests:

1) I blocked the firewall for everyone opened only for my computer and started opening the main page of my repository. And to my surprise, errors started to appear:
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" and 

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"

even though I only opened the main repository page in the browser. Opening a collection, community, item view or anything else does not cause these errors.

2) I disabled the frontend (angular) left the backend enabled and the errors stopped appearing, which excludes bots that try to get into the  
/server/api/system/scripts/metadata-import
/server/api/system/scripts/metadata-export

Tim, in summary, I have exactly the same problem as Sascha, everytime when I opening, refreshing the main page it generating 2 errors :

GET /server/api/system/scripts/metadata-import HTTP/1.1" 401 1514 

GET /server/api/system/scripts/metadata-export HTTP/1.1" 401 1514

Comes to my mind, because after migrating from dspace6 to dspace7 I once carried out the export and import process of collections from the Administrator - first in simulation mode then in normal mode everything performed correctly, did you Sascha take such actions? Maybe something "crashed" in Angular after this action? 

Thanks guys,

Karol

[DSpace Technical Support]

Hi Karol & Sascha,

I previously misunderstood when you were seeing these 401 responses.   Seeing them appear occasionally from the User Interface is *expected behavior*.  What is going on is that the frontend is checking permissions of the current user to see if they are allowed to export/import in order to provide the proper links in the User Interface if they have access.  If the user is allowed, this request returns a 200.  If they are not allowed, it returns a 401.  It is therefore *not* an error, but a permissions check... as a 401 response simply means you don't have permissions.

Simply put, these are safe to ignore.  You *will* sometimes see the User Interface "ask" the REST API if a user has permissions , or if a feature is enabled.  The REST API then will sometimes respond with 401 or 404 or similar... this is expected behavior at this time.  (It might be possible to reanalyze if there's a different way to achieve this... but this is how it works currently. You are welcome to log a bug ticket though in our ticketing system if you want: https://github.com/DSpace/dspace-angular/issues)

That said, if this is filling up your logs you could use caching to ensure the check happens less frequently.

On the demo site, we have anonymous page caching turned on.  This is why it's not visible there as frequently (it still may appear occasionally), as the pages are cached and this permission check happens less frequently.  See this guide for how to enable that caching: https://wiki.lyrasis.org/display/DSDOC7x/User+Interface+Configuration#UserInterfaceConfiguration-CacheSettings-ServerSideRendering(SSR)

Hopefully that helps explain what is going on better.  At a second glance, I think these are just permissions checks for current users.  But, turning on caching should decrease their frequency.

Tim

[Sascha Szott]

Hi Tim,

SSR is the missing keyword - thank you! I was not aware of the fact that
it is enabled.

Is there a place (e.g. branch in Github) where we can see which frontend
configuration is taken into account to serve the public DSpace demo
instance? It would be helpful in the future to explain such differences.

Best
Sascha


Am 31.07.23 um 17:28 schrieb DSpace Technical Support:

> Hi Karol & Sascha,
>
> I previously misunderstood when you were seeing these 401 responses.
>  Seeing them appear occasionally from the User Interface is *expected
> behavior*.  What is going on is that the frontend is checking
> permissions of the current user to see if they are allowed to
> export/import in order to provide the proper links in the User Interface
> if they have access.  If the user is allowed, this request returns a
> 200.  If they are not allowed, it returns a 401.  It is therefore *not*
> an error, but a permissions check... as a 401 response simply means you
> don't have permissions.
>
> Simply put, these are safe to ignore.  You *will* sometimes see the User
> Interface "ask" the REST API if a user has permissions , or if a feature
> is enabled.  The REST API then will sometimes respond with 401 or 404 or
> similar... this is expected behavior at this time.  (It might be
> possible to reanalyze if there's a different way to achieve this... but
> this is how it works currently. You are welcome to log a bug ticket
> though in our ticketing system if you want:
> https://github.com/DSpace/dspace-angular/issues)
>
> That said, if this is filling up your logs you could use caching to
> ensure the check happens less frequently.
>
> On the demo site, we have anonymous page caching turned on.  This is why
> it's not visible there as frequently (it still may appear occasionally),

> as the pages are cached and this permission check happens /less
> frequently/.  See this guide for how to enable that

> caching: https://wiki.lyrasis.org/display/DSDOC7x/User+Interface+Configuration#UserInterfaceConfiguration-CacheSettings-ServerSideRendering(SSR)
>
> Hopefully that helps explain what is going on better.  At a second
> glance, I think these are just permissions checks for current users.
> But, turning on caching should decrease their frequency.
>
> Tim
> On Saturday, July 29, 2023 at 7:05:20 AM UTC-5 karols...@gmail.com wrote:
>
> Hi Tim, Sascha,
>
> Tim, it looks like my first entry, is not correlated with the 401
> error - it's just a coincidence. I don't have any additional
> scripts, nor do I see any bots in the logs that are trying to access
> this content: /server/api/system/scripts/metadata-import
>
> Sascha, it directed me to conduct tests:
>
> 1) I blocked the firewall for everyone opened only for my computer
> and started opening the main page of my repository. And to my
> surprise, errors started to appear:

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

> even though I only opened the main repository page in the browser.
> Opening a collection, community, item view or anything else does not
> cause these errors.
>
> 2) I disabled the frontend (angular) left the backend enabled and
> the errors stopped appearing, which excludes bots that try to get
> into the
> /server/api/system/scripts/metadata-import
> /server/api/system/scripts/metadata-export
>
> Tim, in summary, I have exactly the same problem as Sascha,
> everytime when I opening, refreshing the main page it generating 2
> errors :

> **
> *GET /server/api/system/scripts/metadata-import HTTP/1.1" 401 1514
> *
> *GET /server/api/system/scripts/metadata-export HTTP/1.1" 401 1514*
> **

> --
> All messages to this mailing list should adhere to the Code of Conduct:
> https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
> <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...@googlegroups.com
> <mailto:dspace-tech...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dspace-tech/fe2f4e69-b707-429a-bf6d-051c77313270n%40googlegroups.com <https://groups.google.com/d/msgid/dspace-tech/fe2f4e69-b707-429a-bf6d-051c77313270n%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
Sascha Szott
Abteilung Forschungsinformation und Publizieren
Universitätsbibliothek
Helmut-Schmidt-Universität
Universität der Bundeswehr Hamburg
Holstenhofweg 85
22043 Hamburg

📞 +49 171 6433825
🌍 https://ub.hsu-hh.de/

[DSpace Technical Support]

Hi Sascha,

Yes, the demo site has it's own "ui-demo" branch for the UI at this time: https://github.com/DSpace/dspace-angular/compare/ui-demo

That said, I'll admit we are currently migrating the demo site to a new platform, and that new platform won't use the same GitHub branch-based setup anymore.  So, this branch unfortunately won't be a resource for much longer.  The branch already is incomplete though, as it cannot contain any private information (like the private application keys used to connect the demo to the ORCID sandbox or similar).

That said, we might be able to find a different way to simply document the enabled features on the wiki or similar.

Tim

[Karol]

Tim,

thank you, now I understand that it is not a "bug" in my repository, but the way how it works. I have and had Anonymous cache enabled:

    anonymousCache:
      # Maximum number of pages to cache. Default is zero (0) which means anonymous user cache is disabled.
      # As all pages are cached in server memory, increasing this value will increase memory needs.
      # Individual cached pages are usually small (<100KB), so a value of max=1000 would only require ~100MB of memory.
      max: 3000
      # Amount of time after which cached pages are considered stale (in ms). After becoming stale, the cached
      # copy is automatically refreshed on the next request.
      # NOTE: For the anonymous cache, it is recommended to keep this value low to avoid anonymous users seeing outdated content.
      timeToLive: 10000 # 10 seconds
      # When set to true, after timeToLive expires, the next request will receive the *cached* page & then re-render the page
      # behind the scenes to update the cache. This ensures users primarily interact with the cache, but may receive stale pages (older than timeToLive).
      # When set to false, after timeToLive expires, the next request will wait on SSR to complete & receive a fresh page (which is then saved to cache).
      # This ensures stale pages (older than timeToLive) are never returned from the cache, but some users will wait on SSR.
      allowStale: true

 but still the occurrences are very high: 50450 daily times metadata-import:401. Probably this is due to bots, or the monitoring system in my IT department (zabbix etc). Perhaps I will install fail2ban.

ps. Sascha, thanks for pointing the way.

Greetings,

Karo

[Sascha Szott]

Hi Karol, Tim,

thanks again.

I think that it is not sufficient to add "anonymousCache" to config.yml
- this setting only affects the configuration of the SSR cache.

Another step is required to enable SSR. Currently I'm looking for a
explanation in the DS documentation.

You can simply check if SSR is enabled on your DSpace site by disabling
JavaScript on your browser. If the site's content is still visible
without JavaScript, it is using SSR. If the site appears blank, it is
not using SSR.

In my case I see a blank page on my local DS instance. In contrast,
https://demo7.dspace.org is visible without JavaScript.

Best
Sascha


Am 01.08.23 um 13:59 schrieb Karol:

> <https://github.com/DSpace/dspace-angular/issues>)

> >
> > That said, if this is filling up your logs you could use
> caching to
> > ensure the check happens less frequently.
> >
> > On the demo site, we have anonymous page caching turned on.
> This is why
> > it's not visible there as frequently (it still may appear
> occasionally),
> > as the pages are cached and this permission check happens /less
> > frequently/.  See this guide for how to enable that
> > caching:

> https://wiki.lyrasis.org/display/DSDOC7x/User+Interface+Configuration#UserInterfaceConfiguration-CacheSettings-ServerSideRendering(SSR) <https://wiki.lyrasis.org/display/DSDOC7x/User+Interface+Configuration#UserInterfaceConfiguration-CacheSettings-ServerSideRendering(SSR)>

[DSpace Technical Support]

Hi Sascha,

SSR should always be enabled by default as it is *required* for SEO (e.g. Google Scholar will not index your site unless you are using SSR).  

DSpace 7 therefore always has SSR enabled, and you'd have to go out of your way to disable it (you have to change default code, as it's not possible to disable SSR via simple configs).  Nonetheless, if you've somehow disabled SSR, then we have a guide in our SEO documentation about how to reenable SSR: https://wiki.lyrasis.org/display/DSDOC7x/Search+Engine+Optimization#SearchEngineOptimization-Ensuretheuserinterfaceisusingserver-siderendering

Tim

[Sascha Szott]

Hi Tim,

thanks again for helping out.

I think the key point is that we use a Docker container to run the
DSpace frontend.

The DS documentation says

"Per the frontend Installation instructions, you must also be running
your production frontend/UI via either yarn run serve:ssr or yarn start."

but in the Dockerfile provided by DSpace we found

CMD yarn serve --host 0.0.0.0

I have tried to change it to serve:ssr but it doesn't work.
Unfortunately, I'm not that familiar with nodejs / yarn, but I can
confirm that SSR is disabled if you run the DSpace frontend in a Docker
container based on the Dockerfile provided in Github.

Best
Sascha

Am 01.08.23 um 16:36 schrieb DSpace Technical Support:

> Hi Sascha,
>
> SSR should always be enabled by default as it is *required* for SEO
> (e.g. Google Scholar will not index your site unless you are using SSR).
>
> DSpace 7 therefore always has SSR enabled, and you'd have to go out of
> your way to disable it (you have to change default code, as it's not
> possible to disable SSR via simple configs).  Nonetheless, if you've
> somehow disabled SSR, then we have a guide in our SEO documentation
> about how to reenable
> SSR: https://wiki.lyrasis.org/display/DSDOC7x/Search+Engine+Optimization#SearchEngineOptimization-Ensuretheuserinterfaceisusingserver-siderendering
>
> Tim
>
> On Tuesday, August 1, 2023 at 7:07:57 AM UTC-5 Sascha Szott wrote:
>
> Hi Karol, Tim,
>
> thanks again.
>
> I think that it is not sufficient to add "anonymousCache" to config.yml
> - this setting only affects the configuration of the SSR cache.
>
> Another step is required to enable SSR. Currently I'm looking for a
> explanation in the DS documentation.
>
> You can simply check if SSR is enabled on your DSpace site by disabling
> JavaScript on your browser. If the site's content is still visible
> without JavaScript, it is using SSR. If the site appears blank, it is
> not using SSR.
>
> In my case I see a blank page on my local DS instance. In contrast,

> https://demo7.dspace.org <https://demo7.dspace.org> is visible

> https://wiki.lyrasis.org/display/DSDOC7x/User+Interface+Configuration#UserInterfaceConfiguration-CacheSettings-ServerSideRendering(SSR) <https://wiki.lyrasis.org/display/DSDOC7x/User+Interface+Configuration#UserInterfaceConfiguration-CacheSettings-ServerSideRendering(SSR)> <https://wiki.lyrasis.org/display/DSDOC7x/User+Interface+Configuration#UserInterfaceConfiguration-CacheSettings-ServerSideRendering(SSR) <https://wiki.lyrasis.org/display/DSDOC7x/User+Interface+Configuration#UserInterfaceConfiguration-CacheSettings-ServerSideRendering(SSR)>>

[DSpace Technical Support]

Hi Sascha,

As of 7.6, there's a separate Dockerfile/image for running the frontend in "production" mode: https://github.com/DSpace/dspace-angular/blob/dspace-7_x/Dockerfile.dist   (We are working on updating our demo site to use this same image)

That said, as noted in our Docker README, these images really are not guarantied "production ready" (e.g. we don't perform security scans or similar on these images).  They provide the basics for how to run DSpace on Docker, but we highly recommend that a Docker expert on your end verify each script/image before using in production scenarios.  https://github.com/DSpace/dspace-angular/blob/dspace-7_x/docker/README.md

Nonetheless, if you update your Docker setup o be similar to our new "dist" image, that should allow you to run the UI in production mode on Docker.

Tim

[Sascha Szott]

Hi Tim,

thank you. We've setup a DS 7 frontend container in production mode
(with SSR enabled) and we can confirm that both 401 REST API requests
(to metadata-import and metadata-export) have disappeared.

Thanks again!

Best
Sascha


Am 01.08.23 um 18:05 schrieb DSpace Technical Support:

> https://wiki.lyrasis.org/display/DSDOC7x/Search+Engine+Optimization#SearchEngineOptimization-Ensuretheuserinterfaceisusingserver-siderendering <https://wiki.lyrasis.org/display/DSDOC7x/Search+Engine+Optimization#SearchEngineOptimization-Ensuretheuserinterfaceisusingserver-siderendering>

> https://wiki.lyrasis.org/display/DSDOC7x/User+Interface+Configuration#UserInterfaceConfiguration-CacheSettings-ServerSideRendering(SSR) <https://wiki.lyrasis.org/display/DSDOC7x/User+Interface+Configuration#UserInterfaceConfiguration-CacheSettings-ServerSideRendering(SSR)> <https://wiki.lyrasis.org/display/DSDOC7x/User+Interface+Configuration#UserInterfaceConfiguration-CacheSettings-ServerSideRendering(SSR) <https://wiki.lyrasis.org/display/DSDOC7x/User+Interface+Configuration#UserInterfaceConfiguration-CacheSettings-ServerSideRendering(SSR)>> <https://wiki.lyrasis.org/display/DSDOC7x/User+Interface+Configuration#UserInterfaceConfiguration-CacheSettings-ServerSideRendering(SSR) <https://wiki.lyrasis.org/display/DSDOC7x/User+Interface+Configuration#UserInterfaceConfiguration-CacheSettings-ServerSideRendering(SSR)> <https://wiki.lyrasis.org/display/DSDOC7x/User+Interface+Configuration#UserInterfaceConfiguration-CacheSettings-ServerSideRendering(SSR) <https://wiki.lyrasis.org/display/DSDOC7x/User+Interface+Configuration#UserInterfaceConfiguration-CacheSettings-ServerSideRendering(SSR)>>>

[Karol]

Hi,

sorry for the delay. I checked by disabling java script and with me everything works - so SSR is enabled. Nevertheless, the errors still occur, but I do not use docker - I do not like this solution. Greetings,

Karol

[Oliver Goldschmidt]

Hello Karol,

same here - although SSR is enabled we are seeing those 401 errors for `metadata-import` and `metadata-export` on a non-Docker-environment.

Best

Oliver

[DSpace Technical Support]

Hi Karol & Oliver,

This thread has gotten a bit confusing as there are several topics in discussion here.  To clarify, these 401 "errors" are *safe to ignore*.  They are not actually errors, but are the backend telling the frontend that the current user cannot access those "metadata-import" and "metadata-export" scripts.  See my full description in this earlier email: https://groups.google.com/g/dspace-tech/c/YlWBpX_h4Tg/m/H5_aX7_OAQAJ

There is no fix for this issue at this time as it's expected behavior.  The only way to have it occur *less frequent* it to enable anonymous page caching (as I describe in the email linked above).

Tim

[Karol]

Yes Tim, I understood. I meant that despite the SSR being enabled there are still a fair number of these logs. But I feel more reassured that this is "normal" behavior and it is save to ignore. Thanks 

Karol