Update to latest Angular 20 and remove reliance on Host HTTP Header

[tdonohue]

References

• Patches against Angular CVE-2026-27739 by updating to a patched version of Angular 20.x. As noted on mailing lists, sites are currently only protected by the proxy in front of DSpace.

Description

This PR implements two main changes:

1. Updates us to Angular 20.3.17, which is patched against CVE-2026-27739 (First and third commits)
   • This requires passing a new allowedHosts setting to Angular SSR which must specify the list of trusted hostnames.
   • The existing environment.ui.baseUrl setting has been updated to allow sites to specify the public URL of their site. This value is then used to prepopulate the allowedHosts setting.
2. Removes all usage of the Host HTTP Header, replacing it with using the environment.ui.baseUrl. Because this setting is now required, it's more secure then trusting the Host header. (Second commit)
   • This commit could be manually backported to 7.x.x and 8.x as an additional layer of protection to those releases (by removing all usage of Host HTTP Header in favor of the environment.ui.baseUrl configuration)

This PR should be backported to dspace-9_x as it also uses Angular 20.x.

Instructions for Reviewers

1. With this PR, you MUST update your config.*.yml to add the ui.baseUrl:

   ui:
     ...
    # Specify the public URL that this user interface responds to. This corresponds to the "dspace.ui.url" property in your backend's local.cfg.
    # SSR is only enabled when the client's "Host" HTTP header matches this baseUrl. The baseUrl is also used for redirects and SEO links (in robots.txt and sitemaps). 
    baseUrl: http://localhost:4000
   

2. Build the UI in production mode (in order to enable SSR): e.g. npm run build:prod && npm run serve:ssr
3. Verify that SSR functions properly with the ui.baseUrl set to your DSpace's public URL. You should see no errors in the SSR logs and the homepage & Community/Collection/Item pages should respond with Javascript disabled.
4. Verify that SSR fails if you set ui.baseUrl to a different URL (e.g. https://my.dspace.org). This proves that Angular SSR is accurately validating the hostname via the allowedHosts parameter. You will see an error in the SSR logs that says something like this:

   ERROR: URL with hostname "[Invalid-hostname]" is not allowed.Please provide a list of allowed hosts in the "allowedHosts" option in the "CommonEngine" constructor.
   Error in server-side rendering (SSR)
   Error details :  Error: URL with hostname "[Invalid-hostname]" is not allowed
   ...
   Falling back to serving direct client-side rendering (CSR)
   

5. The above can be tested also behind a proxy (Apache/Nginx) to verify no changes in behavior.

[kshepherd]

+1 by inspection, looks great - i also like the angular config property (vs fetching direct from backend) for keeping our request overhead down. thanks @tdonohue

[artlowel]

Thanks @tdonohue!

The code looks good, I don't see any issues using it, and I've verified with @kshepherd's python script that you can no longer reproduce the issue with this PR.

[tdonohue]

@artlowel and @kshepherd : Just a note, I had to push up another small modification to this PR to workaround a new bug that I've discovered in environment variable overrides. See #5279.

The reason this PR was failing the docker-deploy step within GitHub CI was that our Docker images were unable to override the default empty value of environment.ui.baseUrl via a DSPACE_UI_BASEURL environment variable (see docker-compose-dist.yml in this PR which sets that environment variable). Once I added this optional baseUrl setting to default-app-config.ts (in the latest commit to this PR) that bypassed the bug.

This doesn't change the PR significantly, but I wanted to point out the reason why I had to modify default-app-config.ts, since I was not expecting to have to do so.

[tdonohue]

Unfortunately, docker-deploy is still not working even though I've verified the bug described in #5279 (on my local machine). There's still some issue going on with environment variables in GitHub CI where GitHub isn't picking up my customizations to DSPACE_UI_BASEURL.

I'll have to continue debugging this tomorrow, but this is an odd issue. This PR works entirely on my local machine (including env variable overrides), but still is having issues in GitHub CI.

[kshepherd]

@tdonohue the SSR detection test also seems to be failing now (though the "start SSR" task succeeds")