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 <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: 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 > > > > > > 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 > > <https://github.com/DSpace/dspace-angular/compare/ui-demo> > > > <https://github.com/DSpace/dspace-angular/compare/ui-demo > > <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 > > <https://github.com/DSpace/dspace-angular/issues> > > > <https://github.com/DSpace/dspace-angular/issues > > <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)> > > < > 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) > >> > > > > > > > > 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 --- 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/745fdf36-1711-4bca-9943-fec5ea7de62fn%40googlegroups.com.
