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": "/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) 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. > > 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))* > > 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 <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 <mailto:dspace-tech+unsubscr...@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/ -- All messages to this mailing list should adhere to the Code of Conduct: https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx--- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/f6b6a68c-98f9-b1fd-d350-1ddffb30ef8a%40hsu-hh.de.
smime.p7s
Description: S/MIME Cryptographic Signature
