You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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:
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.
The text was updated successfully, but these errors were encountered: