Provide a setting to use a different REST url during SSR execution #3358

atarix83 · 2024-09-26T14:02:06Z

References

Add references/links to any related issues or PRs. These may include:

Fixes Unable to route network requests to different DSpace REST API URL during SSR #1485
Requires Provide a setting to use a different REST url during SSR execution DSpace#9856

Description

This pull request provide the possibility to use a different DSpace REST url during the SSR

Instructions for Reviewers

List of changes in this PR:

Added a new setting ssrBaseUrl where to specify a different DSpace REST url to use during SSR
Added a new interceptor which replaces the base url used to contact the REST server, if a different DSpace REST url is provided
Changed the behaviour of the thumbnail component. The thumbnail component now renders exclusively in the browser. This change is necessary to prevent issues during server-side rendering (SSR). When a page containing a thumbnail is rendered on the server, the HTML content delivered to the browser would attempt to download the thumbnail using the URL specified in the ssrBaseUrl property. If this URL was not publicly accessible, it would result in an error. By rendering the thumbnail only in the browser, we avoid this problem.
An additional change is required with the ServerHardRedirectService. In case the url to redirect contains the ssrBaseUrl it's reinstated with the public base url. This is necessary otherwise download bitstream page doesn't work.

Include guidance for how to test or review your PR.
Unfortunately it is difficult to test this PR. The best would be to deploy it in a production like environment and configure the internal base url property.
This might be done on both Angular and REST side, like in the example below where public base url is https://dspace-rest.org/server and internal base url is http://localhost:8080/server.

Angular: in your config.prod.yml file set the ssrBaseUrl property, e.g :

rest:
  ssl: true
  host: dspace-rest.org
  port: 443
  nameSpace: /server
  ssrBaseUrl: http://localhost:8080/server

REST: in your local.cfg file set the dspace.server.ssr.url property, e.g. :

# Public URL of DSpace backend ('server' webapp). May require a port number if not using standard ports (80 or 443)
# DO NOT end it with '/'.
# This is where REST API and all enabled server modules (OAI-PMH, SWORD, SWORDv2, RDF, etc) will respond.
# NOTE: This URL must be accessible to all DSpace users (should not use 'localhost' in Production)
# and is usually "synced" with the "rest" section in the DSpace User Interface's config.*.yml.
# It corresponds to the URL that you would type into your browser to access the REST API.
dspace.server.url = https://dspace-rest.org/server

# Additional URL of DSpace backend which could be used by DSpace frontend during SSR execution.
# May require a port number if not using standard ports (80 or 443)
# DO NOT end it with '/'.
dspace.server.ssr.url = http://localhost:8080/server

In order to test it locally you could add an alias hostname for localhost ip to be used as public url

Checklist

tdonohue · 2024-09-26T17:00:30Z

@atarix83 : While I realize this is still in "draft", I'm assigning this to @artlowel and I for review. @artlowel , I know you have a lot on your plate, but this seems like a high priority fix that would be good to get your or your team's feedback on.

ybnd

Everything works as expected, but still "leaks" the SSR URL and does double work since the transfer state is ignored

src/modules/app/browser-init.service.ts

ybnd · 2024-10-03T16:13:07Z

src/modules/app/server-init.service.ts

@@ -100,6 +101,14 @@ export class ServerInitService extends InitService {
  }

  private saveAppConfigForCSR(): void {
-    this.transferState.set<AppConfig>(APP_CONFIG_STATE, environment as AppConfig);
+    if (isNotEmpty(environment.rest.ssrBaseUrl) && environment.rest.baseUrl !== environment.rest.ssrBaseUrl) {
+      // Avoid to transfer ssrBaseUrl in order to prevent security issues


I agree about the potential security concern, good idea.
The state transfer JSON will still list the SSR URL. It's a bit more "hidden" but not secure either.

github-actions · 2024-10-08T20:08:16Z

Hi @atarix83,
Conflicts have been detected against the base branch.
Please resolve these conflicts as soon as you can. Thanks!

tdonohue

Thanks @atarix83 ! I gave this a code review today, and have some minor requests for improvement. I haven't had a chance to fully test this yet, but I plan to do so next week.

src/app/core/services/server-hard-redirect.service.ts

src/config/server-config.interface.ts

atarix83 · 2025-01-09T18:22:42Z

@tdonohue @ybnd

I've improved my implementation trying to address your feedback. Here the main changes:

added a new config property to disable transfer state (see here). By default even if the property is enabled when a different SSR base url is set the state is not transferred from server to client application.
added a new config to allow url replacement in the state transferred to the client application. default to false.

tdonohue

@atarix83 : I was able to test this locally today by using temporary public URLs for the frontend & backend. I ran the frontend & backend on different domains, and ran the frontend in production mode (npm run build:prod; npm run serve:ssr).

Overall, the basics of this PR (and the backend PR) work well. However, I've found a few bugs in my testing:

Authentication doesn't work. This might be a side effect of an error I'm seeing on main, but here's what I'm trying.
- If I use these PRs with the dspace.server.ssr.url and rest.ssrBaseUrl settings disabled, then authentication works fine. However, whenever I authenticate, in the SSR logs I see an "doesn't contain the link profiles" error. This seems harmless, but it appears on every login
- If I then enable the dspace.server.ssr.url and rest.ssrBaseUrl settings and point them at http://localhost:8080/, authentication no longer works. After attempting to authenticate, the page hangs and I just see the loading image (on a blank white page). No obvious errors are seen in the logs.
Whenever SSR is triggered, I see a 404 request to an /undefined path. This appears in my browser's DevTools "Network" tab.
- Enable the dspace.server.ssr.url and rest.ssrBaseUrl settings and point them at http://localhost:8080/
- Go to any Item page.
- Click reload in your browser (to trigger SSR). The 404 /undefined path error will appear in your DevTools
Thumbnail images appear to be accessed initially via the private URL.
- Enable the dspace.server.ssr.url and rest.ssrBaseUrl settings and point them at http://localhost:8080/
- Go to an Item page, for an Item that has a thumbnail.
- Click reload in your browser (to trigger SSR)
- Look closely at the /content request in your browser's DevTools. It will initially be against the private URL ("http://localhost:8080/"). However, once the page redraws, it will send again to the correct public URL.
- If I add the replaceRestUrl: true setting to my config.prod.yml and try again, then this behavior will no longer occur. It only occurs if replaceRestUrl: false is set.

Overall, this appears to be working. When this feature is enabled, I do visually notice the flash/redraw of the page when transitioning from SSR to CSR. It's much more severe than when this feature is disabled. However, if there's no way to minimize that flash, then we may just need to warn people that the page flash is more severe when this separate REST URL feature is enabled.

I also have a few minor comments inline below on the code. Mostly it's looking good though.

config/config.example.yml

src/config/server-config.interface.ts

github-actions · 2025-01-21T22:37:44Z

Hi @atarix83,
Conflicts have been detected against the base branch.
Please resolve these conflicts as soon as you can. Thanks!

…R execution

github-actions · 2025-01-30T19:42:49Z

Hi @atarix83,
Conflicts have been detected against the base branch.
Please resolve these conflicts as soon as you can. Thanks!

# Conflicts: # config/config.example.yml

tdonohue

@atarix83 : I've retested this today, using your separate REST branch (https://github.com/4Science/DSpace/tree/task/main/DURACOM-288_fix_hal_map) and everything seems to be working now!

Login now succeeds! I can no longer reproduce either of the other bugs that I had seen previously. I've also verified that, when I turn off Javascript, it appears all request are going to http://localhost:8080/ instead of the public URL. I've not noticed any obvious bugs after trying out a new submission, search, browse, etc.

So, I think the fixes you've applied to your branch must have solved the authentication errors. If you wanted to move those over to the REST API PR (DSpace/DSpace#9856) then I can give them a code review there. Thanks!

Overall, I think I'm +1 this PR now. But, I want to give it all one last code review & test once all the code is in these PRs.

atarix83 · 2025-01-31T18:49:43Z

@tdonohue I pushed changes to REST PR, could you please take a look? thanks

github-actions · 2025-02-03T11:11:15Z

Hi @atarix83,
Conflicts have been detected against the base branch.
Please resolve these conflicts as soon as you can. Thanks!

# Conflicts: # src/environments/environment.production.ts # src/environments/environment.test.ts # src/environments/environment.ts

atarix83 · 2025-02-03T14:18:34Z

@pnbecker

I've added the missing code in the config.server.ts (Please mind that only REST_SSRBASEURL is needed)
I gave a test using this PR via environment variable and it worked for me. The ssrBaseUrl is valued despite it is not in the config.prod.yml.

Can i ask how have you set the environment variables during your test? I did using the following commands:

DSPACE_REST_SSRBASEURL='http://dspace.rest.org:8080/server'
export DSPACE_REST_SSRBASEURL

tdonohue

👍 Thanks @atarix83 ! This looks good to me now, and it's working for me. I tested it using localxpose.io (to create a dummy public URL), and verified that all functionality works from the User Interface. This includes testing authentication, submission, search, sitemaps, SSR, etc.

I don't have any further feedback. But, I'd still appreciate it if @pnbecker could test this in a "production-like" environment. It's always possible that testing via localxpose.io would miss something that could be caught in a production-like environment.

pnbecker · 2025-02-04T00:19:50Z

@atarix83 @tdonohue I updated the code and gave it another test. I still have the issue, that when I login to DSpace and reload the page in my browser, I'm getting logged out. Everything else works fine, but reloading the page should not log me out.

pnbecker · 2025-02-04T00:25:29Z

I have a setup here, when I remove the ssr base url from the configuration I get a 500 as angular is not allowed to access the official url of the rest api, while my browser can access it. When I login, the dsAuth cookie is created. It is valid for 24 hours. When I reload, the cookie is being removed.

@atarix83 would it be helpful to gain access to my test installation? Do you have a static IPv4 address?

pnbecker · 2025-02-04T01:52:02Z

Actually in Safari I do see the dsAuthInfo cookie until I refresh. In Chrome and Firefox I never see that cookie. In all three browser after refreshing the page, I'm logged out.

tdonohue · 2025-02-04T17:32:30Z

@pnbecker : @atarix83 just created dspace-8_x branches of this PR (and the backend one), so that you can try it out on 8.x instead of pre-9.0:

@atarix83 posted this to Slack:

here the branches for dspace-8_x
angular https://github.com/4Science/dspace-angular/tree/task/dspace-8_x/DURACOM-288
REST https://github.com/4Science/DSpace/tree/task/dspace-8_x/DURACOM-288

When you have a chance, could you test this instead using the 8.x version? It might help us temporarily work around the issues you've hit on main, and ensure this code is working for the upcoming 8.1 release.

grenierdev · 2025-02-05T18:45:17Z

@tdonohue Sorry to jump in.

I'm trying to accomplish the same configuration and I found a way to test everything in a "production-like" with Docker. Docker offer some similarities with a "production-like" environment : containers can access each other internally and only what is exposed can be access by the host with localhost:4000.

It almost work. Seems like dspace-angular is initially using the SSR endpoint http://dpsace:8080/server but after I visit the main page, it use the public endpoint http://localhost:8080/server.

2025-02-05 12:20:17 {"message":"No _links section found at http://localhost:8080/server/api","timestamp":"2025-02-05T17:20:17.402Z","type":"err","process_id":7,"app_name":"dspace-ui"}

Steps to reproduce

Start containers

docker-compose -f docker-compose.yml -p d8 up -d

docker-compose.yml

#
# The contents of this file are subject to the license and copyright
# detailed in the LICENSE and NOTICE files at the root of the source
# tree and available online at
#
# http://www.dspace.org/license/
#

# Docker Compose for running the DSpace backend for testing/development
# This is based heavily on the docker-compose.yml that is available in the DSpace/DSpace
# (Backend) at:
# https://github.com/DSpace/DSpace/blob/main/docker-compose.yml
networks:
  dspacenet:
    ipam:
      config:
        # Define a custom subnet for our DSpace network, so that we can easily trust requests from host to container.
        # If you customize this value, be sure to customize the 'proxies.trusted.ipranges' env variable below.
        - subnet: 172.23.0.0/16
services:
  # DSpace (backend) webapp container
  dspace:
    container_name: dspace
    environment:
      # Below syntax may look odd, but it is how to override dspace.cfg settings via env variables.
      # See https://github.com/DSpace/DSpace/blob/main/dspace/config/config-definition.xml
      # __P__ => "." (e.g. dspace__P__dir => dspace.dir)
      # __D__ => "-" (e.g. google__D__metadata => google-metadata)
      # dspace.dir, dspace.server.url, dspace.ui.url and dspace.name
      dspace__P__dir: /dspace
      # Uncomment to set a non-default value for dspace.server.url or dspace.ui.url
      dspace__P__server__P__url: http://localhost:8080/server
      dspace__P__server__P__ssr__P__url: http://dspace:8080/server
      dspace__P__ui__P__url: http://localhost:4000
      dspace__P__name: 'ONICSE'
      # db.url: Ensure we are using the 'dspacedb' image for our database
      db__P__url: 'jdbc:postgresql://dspacedb:5432/dspace'
      # solr.server: Ensure we are using the 'dspacesolr' image for Solr
      solr__P__server: http://dspacesolr:8983/solr
      # proxies.trusted.ipranges: This setting is required for a REST API running in Docker to trust requests 
      # from the host machine. This IP range MUST correspond to the 'dspacenet' subnet defined above.
      proxies__P__trusted__P__ipranges: '172.23.0'
      LOGGING_CONFIG: /dspace/config/log4j2-container.xml
    image: "${DOCKER_REGISTRY:-docker.io}/${DOCKER_OWNER:-dspace}/dspace:${DSPACE_VER:-dspace-8_x}"
    depends_on:
    - dspacedb
    networks:
      - dspacenet
    ports:
    - published: 8080
      target: 8080
    stdin_open: true
    tty: true
    volumes:
    # Keep DSpace assetstore directory between reboots
    - assetstore:/dspace/assetstore
    # Ensure that the database is ready BEFORE starting tomcat
    # 1. While a TCP connection to dspacedb port 5432 is not available, continue to sleep
    # 2. Then, run database migration to init database tables
    # 3. Finally, start DSpace
    entrypoint:
    - /bin/bash
    - '-c'
    - |
      while (!</dev/tcp/dspacedb/5432) > /dev/null 2>&1; do sleep 1; done;
      /dspace/bin/dspace database migrate
      java -jar /dspace/webapps/server-boot.jar --dspace.dir=/dspace
  # DSpace database container    
  dspacedb:
    container_name: dspacedb
    # Uses a custom Postgres image with pgcrypto installed
    image: "${DOCKER_REGISTRY:-docker.io}/${DOCKER_OWNER:-dspace}/dspace-postgres-pgcrypto:${DSPACE_VER:-latest}"
    environment:
      PGDATA: /pgdata
      POSTGRES_PASSWORD: dspace
    networks:
      - dspacenet
    ports:
    - published: 5432
      target: 5432
    stdin_open: true
    tty: true
    volumes:
    # Keep Postgres data directory between reboots
    - pgdata:/pgdata
  # DSpace Solr container  
  dspacesolr:
    container_name: dspacesolr
    image: "${DOCKER_REGISTRY:-docker.io}/${DOCKER_OWNER:-dspace}/dspace-solr:${DSPACE_VER:-latest}"
    networks:
      - dspacenet
    ports:
    - published: 8983
      target: 8983
    stdin_open: true
    tty: true
    working_dir: /var/solr/data
    volumes:
    # Keep Solr data directory between reboots
    - solr_data:/var/solr/data
    # Initialize all DSpace Solr cores using the mounted local configsets (see above), then start Solr
    # * First, run precreate-core to create the core (if it doesn't yet exist). If exists already, this is a no-op
    # * Second, copy configsets to this core:
    #   Updates to Solr configs require the container to be rebuilt/restarted:
    #   `docker compose -p d7 -f docker/docker-compose.yml -f docker/docker-compose-rest.yml up -d --build dspacesolr`
    entrypoint:
    - /bin/bash
    - '-c'
    - |
      init-var-solr
      precreate-core authority /opt/solr/server/solr/configsets/authority
      cp -r /opt/solr/server/solr/configsets/authority/* authority
      precreate-core oai /opt/solr/server/solr/configsets/oai
      cp -r /opt/solr/server/solr/configsets/oai/* oai
      precreate-core search /opt/solr/server/solr/configsets/search
      cp -r /opt/solr/server/solr/configsets/search/* search
      precreate-core statistics /opt/solr/server/solr/configsets/statistics
      cp -r /opt/solr/server/solr/configsets/statistics/* statistics
      precreate-core qaevent /opt/solr/server/solr/configsets/qaevent
      cp -r /opt/solr/server/solr/configsets/qaevent/* qaevent
      precreate-core suggestion /opt/solr/server/solr/configsets/suggestion
      cp -r /opt/solr/server/solr/configsets/suggestion/* suggestion
      exec solr -f
  dspace-angular:
    container_name: dspace-angular
    environment:
      DSPACE_UI_SSL: 'false'
      DSPACE_UI_HOST: dspace-angular
      DSPACE_UI_PORT: 4000
      DSPACE_UI_NAMESPACE: /
      DSPACE_REST_SSL: 'false'
      DSPACE_REST_HOST: localhost
      DSPACE_REST_PORT: 8080
      DSPACE_REST_NAMESPACE: /server
      DSPACE_REST_SSRBASEURL: 'http://dspace:8080/server'
    image: "${DOCKER_REGISTRY:-docker.io}/${DOCKER_OWNER:-dspace}/dspace-angular:${DSPACE_VER:-dspace-8_x-dist}"
    # build:
    #   context: ./dspace-angular
    #   dockerfile: Dockerfile.dist
    networks:
      - dspacenet
    ports:
    - published: 4000
      target: 4000
    - published: 9876
      target: 9876
    stdin_open: true
    tty: true
volumes:
  assetstore:
  pgdata:
  solr_data:

Visit http://localhost:4000

What is happening

In the Chrome DevTool, I can confirm that the rest API uses the public endpoint http://localhost:8080. But after the initial load of the app, the dspace-angular container complains that No _links section found at http://localhost:8080/server/api. It seems like it doesn't use the SSR endpoint dspace:8080.

tdonohue · 2025-02-05T20:14:34Z

@grenierdev : If it fails immediately (after initial load), that sounds like a possible misconfiguration, or maybe you forgot to rebuild either the frontend or backend images using this PR or DSpace/DSpace#9856 ? Or maybe Docker's network settings are somehow blocking the requests?

I'm not able to reproduce that immediate failure in all my testing of these two PRs while using https://localxpose.io/ . When using LocalXPose, I'm able to create a temporary public URL for the dspace.server.url while keeping dspace.server.ssr.url set to http://localhost:8080/server When I do that, these PRs work well, and I've not noticed any change in behavior for DSpace. (I'm able to login, submit, search, etc)

That said, I'll admit, I haven't tried setting these params via environment variables (though that would be odd if they only worked if set directly in configs and not via environment variables) or tried this sort of Docker approach.

I'll see if I can find time to try out the Docker approach. While I agree it hypothetically should work, I'm a bit worried that Docker networking (which can sometimes be tricky) could be getting in the way here.

pnbecker · 2025-02-05T22:20:20Z

I tested the backport to DSpace 8 of this PR in a production environment. There were two URLs to access the backend: one was accessible only from my browser, the other one from the frontend. The one accessible from my browser filtered the access based on the connecting ip address, the other one was routed via a private IP address space which my browser had no access to. The frontend was able to access the backend only via the private ip.

I was able to login, to submit a new Item, to load thumbnails and files with JavaScript switched off, and to load the sitemap. I was not able to search and browse without JavaScript, which is not a surprise after we merged the PR to limit SSR to certain paths and to exclude search and browse from ssr.

👍 I did not review the code, I just tested it.

grenierdev · 2025-02-06T15:45:10Z

@tdonohue I had the impression that the branch dspace-8_x was this PR. Sorry for my confusion.

I used the branches of both PR in Docker and everything worked. Even with the environment variables.

The frontend is accessible on http://localhost:4000, the API is on http://localhost:8080 and accessible within the containers (internal network of docker) with http://dspace:8080.

Great work!

tdonohue · 2025-02-06T16:07:08Z

Merging with +2 approvals (and an additional approval from @grenierdev as well, thanks!). Thanks again @atarix83 !

tdonohue · 2025-02-06T16:09:18Z

@atarix83 : As discussed in today's meeting, this will need to be ported manually to dspace-7_x. Please let me know when you have a backport PR completed.

github-actions bot assigned atarix83 Sep 26, 2024

tdonohue added high priority performance / caching Related to performance, caching or embedded objects labels Sep 26, 2024

tdonohue requested review from artlowel and tdonohue September 26, 2024 17:00

tdonohue changed the title ~~[DURACOM-288] Provide a setting to use a different REST url during SS…~~ Provide a setting to use a different REST url during SSR execution Sep 26, 2024

atarix83 mentioned this pull request Sep 26, 2024

Provide a setting to use a different REST url during SSR execution DSpace/DSpace#9856

Merged

10 tasks

atarix83 marked this pull request as ready for review September 26, 2024 18:05

artlowel requested review from ybnd and removed request for artlowel September 27, 2024 07:46

ybnd suggested changes Oct 3, 2024

View reviewed changes

github-actions bot added the merge conflict label Oct 8, 2024

github-actions bot removed the merge conflict label Nov 7, 2024

tdonohue requested a review from ybnd November 15, 2024 22:03

tdonohue requested changes Nov 15, 2024

View reviewed changes

src/app/core/services/server-hard-redirect.service.ts Show resolved Hide resolved

src/config/server-config.interface.ts Show resolved Hide resolved

src/config/server-config.interface.ts Show resolved Hide resolved

atarix83 requested a review from tdonohue January 9, 2025 18:22

tdonohue requested changes Jan 14, 2025

View reviewed changes

github-actions bot added the merge conflict label Jan 21, 2025

tdonohue requested a review from pnbecker January 23, 2025 15:24

tdonohue mentioned this pull request Jan 27, 2025

(Discussion) High CPU usage in DSpace frontend related to Angular Server Side Rendering (SSR) #3110

Open

github-actions bot removed the merge conflict label Jan 28, 2025

atarix83 and others added 5 commits January 29, 2025 19:54

[DURACOM-288] Provide a setting to use a different REST url during SS…

ec9a1e2

…R execution

[DURACOM-288] Additional test for thumbnail component

587e154

Add configuration to toggle replace/transfer

a7276b8

[DURACOM-288] Refactoring configuration to transfer state

cfba84c

[DURACOM-288] Add missing settings to config.example.yml

45ee56f

[DURACOM-288] Change properties description

04e5f59

github-actions bot added the merge conflict label Jan 30, 2025

Merge branch 'main' into task/main/DURACOM-288

bf2d12a

# Conflicts: # config/config.example.yml

github-actions bot removed the merge conflict label Jan 30, 2025

tdonohue reviewed Jan 30, 2025

View reviewed changes

[DURACOM-288] Add convention SSR REST environment variable

ac3e87d

github-actions bot added the merge conflict label Feb 3, 2025

Merge branch 'main' into task/main/DURACOM-288

7acf793

# Conflicts: # src/environments/environment.production.ts # src/environments/environment.test.ts # src/environments/environment.ts

github-actions bot removed the merge conflict label Feb 3, 2025

atarix83 requested a review from tdonohue February 3, 2025 20:54

tdonohue approved these changes Feb 3, 2025

View reviewed changes

tdonohue added this to the 9.0 milestone Feb 3, 2025

atarix83 mentioned this pull request Feb 4, 2025

[Port dspace-8_x] Provide a setting to use a different REST url during SSR execution #3953

Merged

12 tasks

tdonohue merged commit 3d6af1f into DSpace:main Feb 6, 2025
15 checks passed

This was referenced Feb 6, 2025

[Port dspace-7_x] Provide a setting to use a different REST url during SSR execution #3962

Merged

New setting for different REST url during SSR produce mixed HTTP/HTTPS endpoints DSpace/DSpace#10380

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Provide a setting to use a different REST url during SSR execution #3358

Provide a setting to use a different REST url during SSR execution #3358

atarix83 commented Sep 26, 2024 •

edited

Loading

tdonohue commented Sep 26, 2024

ybnd left a comment

ybnd Oct 3, 2024

github-actions bot commented Oct 8, 2024

tdonohue left a comment

atarix83 commented Jan 9, 2025

tdonohue left a comment

github-actions bot commented Jan 21, 2025

github-actions bot commented Jan 30, 2025

tdonohue left a comment •

edited

Loading

atarix83 commented Jan 31, 2025

github-actions bot commented Feb 3, 2025

atarix83 commented Feb 3, 2025

tdonohue left a comment

pnbecker commented Feb 4, 2025

pnbecker commented Feb 4, 2025

pnbecker commented Feb 4, 2025

tdonohue commented Feb 4, 2025

grenierdev commented Feb 5, 2025

tdonohue commented Feb 5, 2025

pnbecker commented Feb 5, 2025

grenierdev commented Feb 6, 2025

tdonohue commented Feb 6, 2025

tdonohue commented Feb 6, 2025

Provide a setting to use a different REST url during SSR execution #3358

Provide a setting to use a different REST url during SSR execution #3358

Conversation

atarix83 commented Sep 26, 2024 • edited Loading

References

Description

Instructions for Reviewers

Checklist

tdonohue commented Sep 26, 2024

ybnd left a comment

Choose a reason for hiding this comment

ybnd Oct 3, 2024

Choose a reason for hiding this comment

github-actions bot commented Oct 8, 2024

tdonohue left a comment

Choose a reason for hiding this comment

atarix83 commented Jan 9, 2025

tdonohue left a comment

Choose a reason for hiding this comment

github-actions bot commented Jan 21, 2025

github-actions bot commented Jan 30, 2025

tdonohue left a comment • edited Loading

Choose a reason for hiding this comment

atarix83 commented Jan 31, 2025

github-actions bot commented Feb 3, 2025

atarix83 commented Feb 3, 2025

tdonohue left a comment

Choose a reason for hiding this comment

pnbecker commented Feb 4, 2025

pnbecker commented Feb 4, 2025

pnbecker commented Feb 4, 2025

tdonohue commented Feb 4, 2025

grenierdev commented Feb 5, 2025

Steps to reproduce

What is happening

tdonohue commented Feb 5, 2025

pnbecker commented Feb 5, 2025

grenierdev commented Feb 6, 2025

tdonohue commented Feb 6, 2025

tdonohue commented Feb 6, 2025

atarix83 commented Sep 26, 2024 •

edited

Loading

tdonohue left a comment •

edited

Loading