Hi Juan, It's difficult for me to provide advice on your WAF (web application firewall) configuration or setup. All I can say is that, if your WAF doesn't support Javascript-based web applications, then it may require updates.
Because the DSpace User Interface is an Angular/Javascript application, it *must* run in your users' browsers. This means that your users' browsers will be making direct requests to your backend (REST API) from wherever they are in the world. The backend URL that your users' browsers will use is the one configured in your "rest:" section of the config.*.yml settings. So, this URL can never be localhost...as that cannot be accessed from all over the world. It's worth noting that SSR (server side rendering) is the *only scenario* where the frontend code is running on your server and directly accessing the backend (also on your server). However SSR is primarily used for SEO and to render the *first page* that an anonymous user sees when they access your site. After that, Angular automatically switches users from that SSR generated page over to the JavaScript application running in their browser. (In other words, your authenticated users, especially administrators will mostly *never* be using SSR. SSR is mostly for indexing bots and some anonymous users.) For more on how Angular SSR works, see: https://v17.angular.io/guide/ssr Tim On Wednesday, June 12, 2024 at 3:59:04 PM UTC-5 juanlop...@gmail.com wrote: > Forgot to mention, we have SSR set in our DSpace. > > El miércoles, 12 de junio de 2024 a las 15:55:43 UTC-5, Juan López > escribió: > >> Hi Tim! >> >> Thank you for the response. So does this mean that the IT team needs to >> change the WAF configuration to fit the needs of the DSpace architecture? >> >> Juan. >> El lunes, 10 de junio de 2024 a las 17:01:42 UTC-5, DSpace Technical >> Support escribió: >> >>> Hi Juan, >>> >>> Because the frontend is a *Javascript application* (built on >>> Angular.io), it runs in a user's browser by default (except when Angular's >>> server-side rendering is triggered). >>> >>> This means that (at least some of the time) your users are running the >>> frontend in their browser and only sending requests to your backend (REST >>> API). >>> >>> This is why trying to set "rest" to "localhost" won't work. Because, in >>> that scenario, your users are running the frontend in their browser and >>> it's trying to connect to "localhost" (which would be the user's own >>> machine, and *not* your REST API). >>> >>> This is exactly why the REST API always needs to be configured as a >>> publicly available URL...because all your users are sending requests to the >>> REST API directly whenever they are running the UI in their browser. >>> >>> In terms of whether the frontend needs to send every request through >>> your WAF (web application firewall)...that's harder to answer. If every >>> external request is going through the WAF, then these requests will need to >>> as well. But, maybe there's some way to change your firewall settings to >>> "trust" requests coming from your frontend? I don't know the answer here, >>> but maybe someone else on this list may have ideas if they've dealt with >>> this before. >>> >>> You also may want to review the "Common Installation Issues" >>> documentation >>> <https://wiki.lyrasis.org/display/DSDOC7x/Installing+DSpace#InstallingDSpace-CommonInstallationIssues> >>> >>> in case some of the communication errors you are seeing are ones noted >>> there. We also have an ongoing discussion related to performance of Server >>> Side Rendering (of the frontend) which could be of interest: >>> https://github.com/DSpace/dspace-angular/issues/3110 >>> >>> Hopefully those give you a few ideas to start with. Maybe others on >>> this list will have additional suggestions. >>> >>> Tim >>> >>> On Friday, June 7, 2024 at 12:10:55 PM UTC-5 juanlop...@gmail.com wrote: >>> >>>> Hello! >>>> >>>> We're haven issues with an installation of DSpace 7.6.1. >>>> >>>> When we were on development mode the service was working as expected. >>>> We had a DNS with https and the front-end/back-end communication was set >>>> like this: >>>> ui: >>>> ssl: false >>>> host: localhost >>>> port: 4000 >>>> nameSpace: / >>>> rateLimiter: >>>> windowMs: 60000 >>>> max: >>>> useProxies: true >>>> >>>> rest: >>>> ssl: true >>>> host: test.mydspace.com >>>> port: 443 >>>> nameSpace: /server >>>> >>>> However, now that we are in production, we've changed the URLs in the >>>> front and back configuration files, and the service is working really slow >>>> and throwing communications errors from time to time between the backend >>>> and frontend. >>>> >>>> The IT team has detected that this errors are happening because the >>>> front-end is passing through the WAF everytime it needs to get data from >>>> the back-end. >>>> >>>> We've tried setting the rest-host to "localhost", but DSpace won't work >>>> after that. >>>> >>>> Is there a way to make both, the frontend and backend point to >>>> "localhost" so the backend does not have to go through the firewall? >>>> >>>> Or is there another possible configuration for this to work smoothly? >>>> >>>> Best regards, >>>> >>>> Juan >>>> >>>> -- 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/bd6d1bfd-d395-4bfe-9eaf-5992591aac56n%40googlegroups.com.
