Why do I have to sign-in to FamilySearch multiple times?

LegacyUser

Paul said: Again I run the risk of exposing my ignorance of "computer-related" matters by bringing this issue here, but here goes!

If I'm timed-out during the day, signing back through one of the tabs I left open lets me continue using the other pages. So why, if I crash out of Chrome (like today when I went shopping) and open, say, the four "Recently closed" tabs, do I then have to sign back in four times? To me, I would have thought signing back to one page would then allow me to reload the other three without signing in again (3 times) to access each one.

Would be grateful for any response - however rude (to me) you might choose to be!

(Thinking about it, I assume the difference in behaviour relates to the latter action involving closing my browser.)

LegacyUser

Paul said: Possibly a separate problem but I am getting a "Invalid Oauth2 Request - Oauth2 error: unable to authenticate client" message at each attempt to sign in. Believe I have seen this in the past, though not recently.

LegacyUser

Paul said: Found a workaround for this (aren't I clever?). I clicked the Back arrow whilst on the error message page, then I clicked on Reload. My first sign-in attempt produced nothing, but repeating the action took me straight back to the page I'd left earlier today.

Have repeated this procedure to successfully return to the other three pages I'd had open in separate tabs (before I shut down and went out).

Whilst the whole necessary procedure is baffling (to me), I especially don't get why it needs two attempts before I actually get signed in (i.e. username and password inputted, press enter: nothing - repeat this and sign-in successful).

LegacyUser

Mara Afuvai Isumu said: Hi Paul, If you had four different tabs opened, it means you opened four different links to access records from the same website, while you were logged on.
Hope this helps.

LegacyUser

Justin Masters said: I believe your session should have been preserved when you restarted Chrome and preserved your tabs.

HOWEVER, you should check your privacy settings to see if you have it set to clear your cookies (more specifically session cookies) and cached data when you exit Chrome.

That would surely cause a problem with you being "logged out". You essentially look like someone trying to get into someone else's session.

LegacyUser

Paul said: No, I delete cookies manually, but thanks for responses.

LegacyUser

Tom Huber said: Chrome (and Firefox) open individual sessions for each tab. That means that each session has its own set of cookies. If you have two or more FS tabs open, the timeout cookie impacts only that tab when you reload it. Each tab will have to be reloaded following the situation you have described.

It is part and parcel of the particular browser.

LegacyUser

Paul said: Thanks for confirming it is browser-related, Tom.

LegacyUser

Justin Masters said: Are you sure about that Tom?

I log in with one tab and any subsequent tabs adopt that session cookie. Likewise, if one tab (that I happen to be on) hits a limit on my login session (2 weeks for instance, or 20 minutes after I have no activity), ALL of my tabs get the same treatment regarding my need to log in again.

LegacyUser

Logan Allred said: There are different types of cookies, and some cookies are treated this way. But the sign-in cookie that we set in FamilySearch should be shared across multiple tabs and windows in the same browser (unless you are using Private or Incognito tabs).

LegacyUser

Logan Allred said: "unable to authenticate client" errors should very rarely happen unless your computer time gets way out of date with current time. If this happens regularly, let us know so we an investigate.

As to why sometimes you have to sign in on all tabs or just one, that depends on how or when the tabs are reloaded or refreshed. If your browser or tabs crash and your session has expired, if all 4 tabs reload at the same time, none of them will have a session and they will all go to the login screen. Technically once you sign in on one of the tabs, the shared cookie is now set, and you can then hit the "Back" button on the other tabs and they should take you from the login screen back to the page you were viewing, and now they will have a session and work. But we don't have a way to automatically take you from the sign-in screen to your previous page once the sign-in screen has been shown on a different tab.
It is kind of annoying, but that's just how browsers and cookies work.

If however, your session is still active or you have the "2 week" option set, then we can automatically refresh your session and sign you in on all the tabs at the same time when they reload/refresh.

I suppose that we could check when you reload the sign in screen if you suddenly have a session you didn't before. I will ask and see if that is a possibility, but it probably won't be a high priority fix. But it would require you to sign in on one tab, and then manually reload or refresh the other tabs. Still kind of a hidden workflow that most won't intuitively know how to do, but could save those that know about and work with lots of tabs a bit of time.

LegacyUser

Tom Huber said: I misspoke, the crash restore is what I should have said. The tabs are pre-existing to the reload and thus, also have to be reloaded.

The crossover works only during live sessions, not those interrupted by the computer crash. It is entirely possible that some network connections could cause the same problem. I am sitting on a very flaky private network that crashes my laptop's network adapter system, causing me to have to reboot the system to recapture the adapter. I've tried several different things, but the problem remains subject to a reboot.

LegacyUser

Logan Allred said: And that is why when your session expires and you have multiple tabs open, you can just sign in on one and the others continue to work. They were never reloaded or refreshed while the session was expired so they didn't go to the sign-in page, and by the time you click on a link or do some work on the other tabs, the shared cookie has already been updated so they use the new shared cookie and work fine.
But if your session expired, and you clicked a link or refreshed all of your tabs, then they would all go to the sign-in page until you signed in on one. But since you are only working in a single tab at a time, once that tab is fixed, they all get fixed together. I hope that makes sense.

LegacyUser

Justin Masters said: Have you tried an ipconfig /release and a following ipconfig /renew in a dos window?

LegacyUser

Justin Masters said: Logan, can you take a look at the thread at https://getsatisfaction.com/familysea...

There's a reference I put in there for a token that appears when you copy a link found in a source attachment. I was just wondering if that's indadvertently disclosing a personal session/access token or a source access/location token (ie, like on a sharepoint type of site, or database).

Search for the word "token" and look at the link there.

LegacyUser

Logan Allred said: Can I ask how you got that URL? Your comment says you copied it from the source page, but I don't see anywhere that URL is linked to from that page.

If you right-click or ctrl-click the image and say "View Image" or "Open Image in a new tab", or "Copy Image Location" or "Copy Image Address" (depending on your browser), you will get that URL that you posted. But that is not a good URL to share or link to for a variety of reasons, especially because that it is a low-quality thumbnail and not the high quality original image, but also that URL is temporary and internal and will likely change/break in the future.

The correct URL to share/link is the link underneath the image that says: "View the original document". That link is permanent and is guaranteed to always work (it starts with "ark:", which means it's a permanent archival link).

If we ever provide a link to that internal URL in the UI on the page, that is bug that needs to be fixed.

Now the token itself, that is only available to you in your browser, and it only works for a limited time. Everyone viewing that page gets a separate temporary token in that internal URL. So it is fine for it to be available to you in your browser, but it should never be shared. We can't really stop the browser from putting in the right-click or ctrl-click menu very well, but we should never link to it from our UI.

So sharing that link could be a security problem for you for a little while, but that token will expire and then that token is useless. But always use the links we provide in the UI, or the URL in the browser when sharing records and images.

LegacyUser

Justin Masters said: Logan, I got the URL by right clicking the image. I happened to notice the token portion embedded in the URL, and I was concerned, so I sanitized 4 digits with 0000 before posting it.

Well, the token (as far as it being only visible in my browser) came with the right click, even though you can mouse over it and get a ark link.

I noticed a 3rd party company that connects to you guys also "carries" a token around with me on all the URL's, and so I have to be careful in sharing links there as well.

What's the expiration time on that token? And does it stay "alive" with continued activity? Such a short time could be pretty bad if someone were to change my email address and password and take over the account.

LegacyUser

Justin Masters said: I've always thought passing tokens in the URL was a bad idea too.. wasn't that used back before session cookies became prevalent on (I think) get statements?

LegacyUser

Logan Allred said: Currently the expiration is 1 hour of inactivity. It is immediately expired if you click Sign Out. It can last a maximum of 24 hours, but rarely lasts that long. Those policies can change, and have in the past.

We avoid putting tokens on the URLs in every case that we can. Unfortunately, the way that browsers handle images makes that one case where sometimes we need to do that, but we try and not expose those in a way that is easy to discover. A recent update changed how we get to these images, so having the token available via a right/ctrl-click is a new situation where that is perhaps too easily available now. I will bring it up with our teams and see if they feel we need to obfuscate the token in the URL better or change how we show those images slightly. Thanks for bringing it to our attention.

LegacyUser

Justin Masters said: You're welcome.. have a good night!

LegacyUser

Paul said: As I have confirmed, my issue just relates to what happens after I close my browser. When I log back in (to Chrome) is when I experience the problem, whether or not I have deleted cookies.

Just one point to add, when I have multiple tabs open (without closing my browser) there now seems to be a behaviour not noticed in the past. When I switch to another Family Tree tab (after logging back in on one of the pages), the click of the mouse produces nothing, except a quick flash / jumping of the screen. I have to click again to be able to continue work on the page in that tab. Maybe it has always behaved that way, but I only noticed this over the last 2 to 3 months.

LegacyUser

Stewart Millar said: I have heard of this issue before - but I have never experienced it . . . I quite regularly will have up to or over 20 tabs open - most in FS and will be engaged in tracing/reconciling some line of research spread over several days or weeks.

I use Firefox . . . if I leave the PC for a few hours - or - overnight I put the PC in sleep mode . . . the next time I come to use the PC - or after a longer gap (multiple days) . . . I simply refresh any one of the FS tabs and I am back in business with all the FS tabs.

LegacyUser

Paul said: Thanks, Stewart. Have just acquired a new computer and haven't loaded Firefox yet, so will have to test how things work for me in a different browser.

LegacyUser

Paul said: Logan

Thank you very much for your comments. Somehow I have missed reading them until just now. Will have to try the possible workarounds to see if I can save myself having to make multiple sign-ins to the pages I had been viewing the day before.