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

Dynamic Tree application's stored API cookie does not necessarily match API logged-in status #78

Open
bcaseyrls opened this issue Oct 26, 2022 · 0 comments

Comments

@bcaseyrls
Copy link
Contributor

Describe the bug
When a user logs into the API through the clientLogin process, we store their user id in a cookie on the app host so that we remember that they've logged in (and under what user id). This is done in LoginManager.saveCookies(), and currently uses the two cookies "WikiTreeAPI_userId" and "WikiTreeAPI_userName". This works in most circumstances to keep the user logged in.

However, if the user's login status at api.wikitree.com is lost (say their cookies were wiped on that hostname) then the LoginManager's cookies are inaccurate. The user will not be logged in, and they won't get content that requires them to be so. But the wt-api-login div will still report the user as logged in and not show the user the button. You're stuck unless you manually clear the WikiTreeAPI_userId cookies.

We need a way to confirm the login status. My thought is a new API function or option for clientLogin. We can POST the user there to do the sign-in. And we can query it from the app with the returned authcode to confirm the sign-in worked. We need a new function, which would run on every page load, to just check "Is this user id (still) signed in?" And if not, we'd clear the local LoginManager cookies and treat the user as not signed in.

I suppose another option might be to query for data that is private and see if we can get it. But I can't think of a way to distinguish between being on the Trusted List of the profile and being the actual user associated with the profile. Being on the TL means the API returns "all" of the data. Or maybe there's another workaround.

I think the most straight-forward thing may be the simple addition to the API to check a login status, much like the authcode exchange.

To Reproduce
Steps to reproduce the behavior:

  1. Go to Dynamic Tree interaction: https://apps.wikitree.com/apps/wikitree-dynamic-tree
  2. If not already, use the "Login at WikiTree API" button to go through clientLogin.
  3. Go to https://api.wikitree.com/api.php?action=getPerson&key=Windsor-1&fields=Id,Name
  4. Clear your cookies on api.wikitree.com (I use a Chrome extension to make this easy)
  5. Return to https://apps.wikitree.com/apps/wikitree-dynamic-tree

The page will still say "Logged into API: WikiTree-ID" and not show the login button. However you will not be able to view any profiles that are privacy restricted, because you are no longer actually logged in at the API.

Expected behavior
We should have a consistent/accurate assessment of the user's API login status.

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

No branches or pull requests

1 participant