Login broken when on specific hash-specified view

[bcaseyrls]

Describe the bug If you are not logged into the API and you select a specific view by providing a WikiTree ID and View option then clicking "Go", you are properly sent through the API's clientLogin form. However, when you return to the dynamic tree, the login does not complete. The code that replaces the history state to put the current view (retrieved from cookies) into the URL is, I think, wiping out the auth code required to complete the login process. You can only login if you are at a "clean" tree URL, without #name=WikiTreeID&view=viewID.

To Reproduce Steps to reproduce the behavior:

1. View /wikitree-dynamic-tree/#name=Windsor-1&view=wt-dynamic-tree, or any tree URL with a hash destination.
2. Click "Login at WikiTree API"
3. On return, note not logged in.

Expected behavior The login needs to work even if there is a cookie-stored and state-refreshed default view.

Desktop (please complete the following information):

• OS: OSX
• Browser Chrome, Firefox

[MichalVasut]

Probably my mistake, I'll fix it tonight.

[GeoffRiley]

Confirm it's happening on Linux with Chrome and Firefox too.

[MichalVasut]

okay, IMHO it is backend fault and how i adds the authcode to the url 😄 , check example returned by the server

http://127.0.0.1:5500/#name=Windsor-1&view=wt-dynamic-tree?authcode=___some_auth_code___

Obviously I cannot know how the url is constructed, but I would guess the ?authcode=___some_auth_code___ is just appended at the end of url...

As for url structure...

Source: https://javascript.info/url

I'll try to fix it on client side, but it's imho wrong 😿

Here is nice function for php that could help on backend: https://www.php.net/manual/en/function.parse-url.php

[bcaseyrls]

You could be right here. Let me take a look at the server side of the API's clientLogin function before you try to kludge in a workaround in the tree code.

[MichalVasut]

@bcaseyrls ouch, already created fix 🙃 https://github.com/wikitree/wikitree-dynamic-tree/pull/70

but it's on one place and easily revertible

PLUS there is another small improvement - it stays at the selected profile after login, before it switched to logged in user

If you don't want to fix the server side immediatelly, this one can be deployed and as temporary fix

[bcaseyrls]

The server-side clientLogin code wasn't just appending authcode, but it wasn't properly complete either. This should be fixed now. I've tested it with a variety of URL constructions, with and without query parameters and #hashcode values. The login button works for me now, though as you note the process still loses the starting WikiTree ID (changing to the logged-in user's). In https://github.com/wikitree/wikitree-dynamic-tree/pull/70, you can, I think, remove the work-around.

[GeoffRiley]

Yep, that seems to work now on my instance with the family group sheet selected.