Prywatna wiadomość na temat: [dspace-tech] Re: DSpace 7.5 - status:401 exception: Access is denied

[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

środa, 16 sierpnia 2023 o 21:27:48 UTC+2 DSpace Technical Support 
napisał(a):

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

On Wednesday, August 16, 2023 at 6:15:11 AM UTC-5 Oliver Goldschmidt wrote:

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
Karol schrieb am Sonntag, 13. August 2023 um 11:22:22 UTC+2:

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

środa, 2 sierpnia 2023 o 17:48:38 UTC+2 Sascha Szott napisał(a):

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: 
> 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 
> 
> On Tuesday, August 1, 2023 at 10:02:35 AM UTC-5 Sascha Szott wrote: 
> 
> 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
 
<
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 

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

[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

On Wednesday, August 16, 2023 at 6:15:11 AM UTC-5 Oliver Goldschmidt wrote:

> 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
> Karol schrieb am Sonntag, 13. August 2023 um 11:22:22 UTC+2:
>
>> 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
>>
>> środa, 2 sierpnia 2023 o 17:48:38 UTC+2 Sascha Szott napisał(a):
>>
>>> 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: 
>>> > 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 
>>> > 
>>> > On Tuesday, August 1, 2023 at 10:02:35 AM UTC-5 Sascha Szott wrote: 
>>> > 
>>> > 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
>>>  
>>> <
>>> 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 

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

[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
Karol schrieb am Sonntag, 13. August 2023 um 11:22:22 UTC+2:

> 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
>
> środa, 2 sierpnia 2023 o 17:48:38 UTC+2 Sascha Szott napisał(a):
>
>> 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: 
>> > 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 
>> > 
>> > On Tuesday, August 1, 2023 at 10:02:35 AM UTC-5 Sascha Szott wrote: 
>> > 
>> > 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
>>  
>> <
>> 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  
>> > > is visible 
>> > > without JavaScript. 
>> > > 
>> > > Best 
>> > > Sascha 
>> > > 
>> > > 
>> > > Am 01.08.23 um 13:59 schrieb 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) 
>> > 

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

[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

środa, 2 sierpnia 2023 o 17:48:38 UTC+2 Sascha Szott napisał(a):

> 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:
> > 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
> > 
> > On Tuesday, August 1, 2023 at 10:02:35 AM UTC-5 Sascha Szott wrote:
> > 
> > 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
>  
> <
> 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 
> > > is visible
> > > without JavaScript.
> > >
> > > Best
> > > Sascha
> > >
> > >
> > > Am 01.08.23 um 13:59 schrieb 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 

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

[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

On Tuesday, August 1, 2023 at 10:02:35 AM UTC-5 Sascha Szott wrote:

> 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  is visible
> > without JavaScript.
> > 
> > Best
> > Sascha
> > 
> > 
> > Am 01.08.23 um 13:59 schrieb 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: 1 # 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 

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

[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  is visible
without JavaScript.

Best
Sascha


Am 01.08.23 um 13:59 schrieb 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: 1 # 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
 >
 > poniedziałek, 31 lipca 2023 o 17:53:39 UTC+2 DSpace Technical
Support
 > napisał(a):
 >
 > 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
  

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

[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 is visible without JavaScript.
>
> Best
> Sascha
>
>
> Am 01.08.23 um 13:59 schrieb 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: 1 # 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
> > 
> > poniedziałek, 31 lipca 2023 o 17:53:39 UTC+2 DSpace Technical Support 
> > napisał(a):
> > 
> > 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
> > On Monday, July 31, 2023 at 10:40:04 AM UTC-5 Sascha Szott wrote:
> > 
> > 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 

Re: Prywatna wiadomość na temat: [dspace-tech] Re: DSpace 7.5 - status:401 exception: Access is denied

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

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: 1 # 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

poniedziałek, 31 lipca 2023 o 17:53:39 UTC+2 DSpace Technical Support 
napisał(a):


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
On Monday, July 31, 2023 at 10:40:04 AM UTC-5 Sascha Szott wrote:

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 

Prywatna wiadomość na temat: [dspace-tech] Re: DSpace 7.5 - status:401 exception: Access is denied

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

poniedziałek, 31 lipca 2023 o 17:53:39 UTC+2 DSpace Technical Support 
napisał(a):

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
On Monday, July 31, 2023 at 10:40:04 AM UTC-5 Sascha Szott wrote:

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, 

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

[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
On Monday, July 31, 2023 at 10:40:04 AM UTC-5 Sascha Szott wrote:

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

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

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

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

piątek, 28 lipca 2023 o 18:44:44 UTC+2 Sascha Szott napisał(a):

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

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

[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*
>
> 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
>
> piątek, 28 lipca 2023 o 18:44:44 UTC+2 Sascha Szott napisał(a):
>
>> 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). 

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

[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

piątek, 28 lipca 2023 o 18:44:44 UTC+2 Sascha Szott napisał(a):

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

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

[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: DSpace 7.5 - status:401 exception: Access is denied

[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

[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