Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug 435. Login redirects and running under different hostnames #454

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

MytsV
Copy link
Contributor

@MytsV MytsV commented Aug 12, 2024

Seemingly fix #435

I tested the changes by using a different hostname for referring to the local deployment. I managed to turn
image
into
image

It works for all the use cases of middleware redirects. I believe that might be the fix for the issue.

@@ -15,7 +15,7 @@ export default function Page() {
}
const didQuery = async (query: string, type: DIDType) => {
const request: any = {
url: new URL(`${process.env.NEXT_PUBLIC_WEBUI_HOST}/api/feature/list-dids`),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change refers to making deployments more flexible and accessible through any hostname. All the places where the hostname was specified through an environmental variable are reviewed.

@MytsV
Copy link
Contributor Author

MytsV commented Aug 12, 2024

Regarding the second change, I made sure every feature still works locally for me

@MytsV MytsV requested a review from maany August 12, 2024 17:43
@maany
Copy link
Member

maany commented Aug 14, 2024

@MytsV, the root cause of our client side routing troubles is the cache of the NextJS client side router.

Setting window.location.href to redirect to a new page forces the page to completely reload thereby opting out of the client side router of NextJS, and also resetting its cache.

There are certain performance and security nuances with the NextJS router that would be nice for us to leverage. In Next14 and 15, the staleTime is controllable and 0, respectively out of the box. I'd probably give the client side router another shot before completely changing how we do client side routing. :)

If everything fails with the framework, your solution is definitely a fix :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Redirect to public webui URL after login
2 participants