[Bug] Setting token in url removes/ignores router base path

[timriley-io]

Describe the Bug

When using a token in the url search params, the logic in the ModeRoute component that strips the token out of the url ignores that the application may be served from a path other than /.

I believe location.pathname could be replaced with window.location.pathname to yield the correct result.

Steps to Reproduce

1. Set routerBasename in platform/app/public/config/default.js to /my-viewer
2. yarn dev and open browser to OHIF viewer (http://localhost:3000/my-viewer)
3. Open any study in the Basic Viewer
4. Append &token=123 to the url
5. Url will now be http://localhost:3000/viewer?StudyInstanceUIDs..., note that /my-viewer is no longer present!

The current behavior

When a token is supplied in the url, the page is redirected to a url that ignores the router base path. e.g. http://localhost:3000/my-viewer?token=123 redirects to http://localhost:3000 instead of http://localhost:3000/my-viewer

The expected behavior

When a token is supplied in the url, the application should continue to honour the base path of the router.

OS

macOS 13.4 (m1)

Node version

20.9.0

Browser

Chrome 120.0.6099.216 arm64

[beavermml]

cannot reproduce in 3.8.

my setup is to use /ohif as the routerBaseName

i did

1. open /ohif/dicomjson?url=theurl&token=123
2. ohif will refresh with new URL without token
3. ohif will append auth token on downloading

[timriley-io]

@beavermml - after your step 3, did the url still contain /ohif?

[beavermml]

@beavermml - after your step 3, did the url still contain /ohif?

Yes. The url still the same

[yomarbuzz]

I'm having the same issue, I'm using /ohif RouterBaseName.

[amazy]

Hi,

I'm actually having the same issue on one of our setups.

When we build a custom OHIF Docker image that will be served at /ohif/, we add PUBLIC_URL=/ohif/ before yarn run build and add routerBasename = '/ohif', we can then pass &token=... in the url and everything works fine.

However, when we build the OHIF orthanc plugin, we leave PUBLIC_URL=./ because we actually don't know where OHIF will be served, it will be served at http://localhost:8042/ohif/ if Orthanc is running standalone but, if Orthanc is running behind a reverse proxy, OHIF will be served at something like http://mydomain/orthanc/ohif/. Although we set the routerBasename correctly dynamically when loading the OHIF code, at some point, the url goes up one level when OHIF extracts the token and the remaining part of the OHIF files can not be loaded:

I have just implemented a ugly hack in the orthanc plugin to patch OHIF code on the fly according to @timriley-io suggestion: replace location.pathname by window.location.pathname and it seems to work. However, since I'm not familiar with react and/or react router and OHIF development in general, I'm not confident to submit this patch into OHIF code. Could someone from OHIF have a look at it ?

Thanks !

[sedghi]

hi all, is this an issue that is happening recently or it was there from start?

[sedghi]

I think the solution suggested makes sense, i will create a PR

Thanks!

[amazy]

Hi @sedghi

This is actually here from the start.

Thanks for taking care of the PR !

[sedghi]

We just release the OHIF 3.8, you can find more details here https://ohif.org/release-notes/3p8/ If you still encounter this issue in 3.8, please re-open this.