EDMC needs to re-authenticate every time I switch computers

[Unknown-Zombie]

Please complete the following information:

• Version: 5.4.1+e1354c3
• Game Version: Odyssey
• OS: Windows 10 x64
• OS Locale: US English

Log files

• Debug log from Computer 1 (laptop):
  EDMarketConnector-debug.log
  EDMarketConnector.log
  ^ This log may be useless since this log is from a second run of the program. I re-launched EDSM after the first run (where re-authentication was required). So this log won't show any errors.
• Debug log from Computer 2 (desktop):
  Will upload later today when I get home and have access to this computer.

Describe the bug
Re-authentication with Frontier is always required the first time that EDMC is launched after switching computers.

To Reproduce

1. Launch EDMC on first computer; log in to authenticate with Frontier.
2. Close EDMC on first computer.
3. Launch EDMC on second computer; log in to authenticate with Frontier.
4. Close EDMC on second computer.
5. Launch EDMC on first computer again, have to re-authenticate with Frontier.
6. Re-authentication requested for every first launch when moving between computers.

Expected behavior
I want to move back and forth between computers without having to log in every time.

Additional context
(Cut & paste from our forum conversation about this)

It's a Steam account. I've tried using Frontier login auth and Steam login auth, both require me to re-authenticate when I move between computers.

I do have the journal directory, trade data folder, and visited stars cache folder all synced to OneDrive so that both computers stay accurate on all data.

For reference, in case something about my setup might be causing the problem, these are the synced folders...

• Journal:
  C:\Users\james\Saved Games\Frontier Developments\Elite Dangerous
• Trade data:
  C:\Users\james\AppData\Local\Frontier Developments\Elite Dangerous\2576704
• Visited Stars cache:
  C:\Users\james\AppData\Local\Frontier Developments\Elite Dangerous\2592140

The above are actually symlinks (mklink /d) that point to respective subdirectories inside my OneDrive folder (the folder which actually gets synced).

I'm not sure if having those folders synced (or having them linked to a different location) could be causing problems but figured I'd lay out my setup just in case.

[alterNERDtive]

The above are actually symlinks (mklink /d) that point to respective subdirectories inside my OneDrive folder (the folder which actually gets synced).

Totally random, possibly unrelated heads up: I had a user that synced with Dropbox. And that put a full on lock on the journal each time the game wrote to it (and Dropbox re-synced), leading to … fun interactions with applications trying to read from it.

No idea if it’s related to your issue or if OneDrive even has the same problem, but, you know.

[Athanasius]

About this Journal re-syncing. Have you ever deleted and re-made your Commander with a different name? If so, do any of the Journal files currently in the folder have that prior/other Commander name ? That could be the culprit if the OneDrive file syncing is messing with the 'creation time' timestamps on the files and fooling EDMC into thinking an old Journal is the latest.

Apart from that, relevant part from the -debug log, which definitely picked up a Journal file from yesterday as the latest:

2022-08-09 12:48:07.571 UTC - INFO - 12472:3636:3636 monitor.EDLogs.start:256: Start Journal File: "C:\Users\james\Saved Games\Frontier Developments\Elite Dangerous\Journal.2022-08-08T215936.01.log"
2022-08-09 12:48:07.587 UTC - DEBUG - 12472:3636:3636 monitor.EDLogs.start:259: Starting Journal worker thread...
2022-08-09 12:48:07.587 UTC - DEBUG - 12472:10712:10712 monitor.EDLogs.worker:369: Starting on logfile "C:\Users\james\Saved Games\Frontier Developments\Elite Dangerous\Journal.2022-08-08T215936.01.log"
2022-08-09 12:48:07.587 UTC - DEBUG - 12472:3636:3636 monitor.EDLogs.start:263: Done
2022-08-09 12:48:07.587 UTC - DEBUG - 12472:3636:3636 monitor.EDLogs.start:265: Done.
2022-08-09 12:48:08.514 UTC - DEBUG - 12472:10712:10712 monitor.EDLogs.worker:395: Now at end of latest file.
2022-08-09 12:48:08.514 UTC - DEBUG - 12472:10712:10712 monitor.EDLogs.worker:436: Entering loop...
2022-08-09 12:48:08.548 UTC - DEBUG - 12472:3636:3636 companion.Session.login:678: changed account or retrying login during auth
2022-08-09 12:48:08.548 UTC - DEBUG - 12472:3636:3636 companion.Auth.refresh:323: Trying for "Unknown Zombie"
2022-08-09 12:48:08.548 UTC - DEBUG - 12472:3636:3636 companion.Auth.refresh:327: Cmdrs: ['Unknown Zombie']
2022-08-09 12:48:08.548 UTC - DEBUG - 12472:3636:3636 companion.Auth.refresh:330: idx = 0
2022-08-09 12:48:08.548 UTC - DEBUG - 12472:3636:3636 companion.Auth.refresh:335: We have a refresh token for that idx
2022-08-09 12:48:08.548 UTC - DEBUG - 12472:3636:3636 companion.Auth.refresh:342: Attempting refresh with Frontier...
2022-08-09 12:48:12.140 UTC - ERROR - 12472:3636:3636 companion.Auth.refresh:359: Frontier CAPI Auth: Can't refresh token for "Unknown Zombie"
2022-08-09 12:48:12.140 UTC - DEBUG - 12472:3636:3636 companion.Auth.dump:532: Frontier CAPI Auth: failed with `r` False: <Response [401]>
2022-08-09 12:48:12.140 UTC - INFO - 12472:3636:3636 companion.Auth.refresh:371: Frontier CAPI Auth: New authorization request
2022-08-09 12:48:12.140 UTC - INFO - 12472:3636:3636 companion.Auth.refresh:377: Trying auth from scratch for Commander "Unknown Zombie"
2022-08-09 12:48:12.341 UTC - DEBUG - 12472:3636:3636 companion.Session.login:694: We do NOT have an access_token
2022-08-09 12:48:12.425 UTC - DEBUG - 12472:10492:10492 plugins.edsm.worker:654: Got "events to discard" list, commencing queue consumption...
2022-08-09 12:48:50.960 UTC - DEBUG - 12472:7892:7892 protocol.WindowsProtocolHandler.worker:313: Message starts with edmc://auth
2022-08-09 12:48:50.960 UTC - DEBUG - 12472:7892:7892 protocol.GenericProtocolHandler.event:54: event_generate("<<CompanionAuthEvent>>")
2022-08-09 12:48:50.960 UTC - DEBUG - 12472:3636:3636 companion.Session.auth_callback:702: Handling auth callback
2022-08-09 12:48:50.960 UTC - DEBUG - 12472:3636:3636 companion.Session.auth_callback:709: Trying authorize with payload from handler
2022-08-09 12:48:50.975 UTC - DEBUG - 12472:3636:3636 companion.Auth.authorize:397: Checking oAuth authorization callback
2022-08-09 12:48:50.975 UTC - DEBUG - 12472:3636:3636 companion.Auth.authorize:418: Got code, posting it back...
2022-08-09 12:48:52.128 UTC - INFO - 12472:3636:3636 companion.Auth.authorize:470: Frontier CAPI Auth: New token for "Unknown Zombie"
2022-08-09 12:48:52.131 UTC - DEBUG - 12472:3636:3636 companion.Session.start_frontier_auth:642: Starting session

So, indeed the initial attempt to use the Refresh Token failed, with the Frontier servers returning a 401 HTTP status, which is 'Unauthorized'.

What I'd like you to do now is check the registry key Computer\HKEY_CURRENT_USER\SOFTWARE\Marginal\EDMarketConnector\fdev_apikeys but do not paste the value here (it's literally a key to accessing CAPI for your account). It should be roughly of the form:

abc17364-f26b-4f70-da87-0b90f80f22a3

Please confirm whether yours looks roughly like that.

Either way then:

1. Exit EDMarketConnector.exe
2. Delete only the key fdev_apikeys.
3. Re-run EDMarketConnector.exe, it will definitely ask you to auth again now.
4. See if you have further issues in the future

Obviously in your case you'll need to perform those steps on both computers to ensure the Registry fdev_apikeys isn't holding some old stale value, and then gets re-created properly. There's a chance that any Anti-Virus software could have started blocking changing the value of that key, but then you'd literally have to re-auth on every run of the program, not only when you've just switched after a sync of Journals from the other computer.

[Unknown-Zombie]

The above are actually symlinks (mklink /d) that point to respective subdirectories inside my OneDrive folder (the folder which actually gets synced).

Totally random, possibly unrelated heads up: I had a user that synced with Dropbox. And that put a full on lock on the journal each time the game wrote to it (and Dropbox re-synced), leading to … fun interactions with applications trying to read from it.

No idea if it’s related to your issue or if OneDrive even has the same problem, but, you know.

I always suspend OneDrive while playing the game (or any other game that constantly updates synced files) and then turn it back on once playtime is over. Because I have run into issues like the one you advise about above with several games.

[Unknown-Zombie]

About this Journal re-syncing. Have you ever deleted and re-made your Commander with a different name? If so, do any of the Journal files currently in the folder have that prior/other Commander name ? That could be the culprit if the OneDrive file syncing is messing with the 'creation time' timestamps on the files and fooling EDMC into thinking an old Journal is the latest.

I've never renamed or deleted my commander.

The journal files in that folder date all the way back to my first launch of the game in November 2016. Something I did in 2019 changed all the older journal files' modified times (to 2019), but anything since then has proper timestamps.

What I'd like you to do now is check the registry key Computer\HKEY_CURRENT_USER\SOFTWARE\Marginal\EDMarketConnector\fdev_apikeys but do not paste the value here (it's literally a key to accessing CAPI for your account). It should be roughly of the form:

abc17364-f26b-4f70-da87-0b90f80f22a3

Please confirm whether yours looks roughly like that.

Yes I have an alphanumeric key there, formatted 8-4-4-4-12

Either way then:

1. Exit EDMarketConnector.exe

2. Delete _only_ the key `fdev_apikeys`.

3. Re-run EDMarketConnector.exe, it will definitely ask you to auth again now.

4. See if you have further issues in the future

I will perform that now on my laptop, and on my desktop later in the day once I get home. Then, I'll report back with results.

[Unknown-Zombie]

if the OneDrive file syncing is messing with the 'creation time' timestamps on the files and fooling EDMC into thinking an old Journal is the latest.

Actually, this got me curious and I looked closer at the files and OneDrive is doing some weird stuff with creation times. Only the modified times are properly preserved.

When a remote file which does not exist on the system is synced, it is given a current timestamp for file creation, and file modified time is the only field being properly synced.

The file on the left was created on this laptop yesterday during play. The file on the right was created remotely on a desktop later in the day yesterday during play. The creation date on the file on the right has a creation time of the time that OneDrive downloaded the file to this laptop today and not a creation time of when the original file was created on the desktop, last night.

This might, conceivably, cause issues if EDMC is looking at creation date instead of modification date, and if OneDrive were to sync multiple new journal entry files created on a different machine, and it did not download/create them in the proper chronological order in which they were originally created.

I'm not sure that this is causing the reported issue, but thought it was worth pointing out what I dug up in case it could be useful to know in some capacity.

[Athanasius]

Well, if you only ever:

1. Perform the sync.
2. Start EDMC
3. Start the game

Then the last step will cause a new Journal file and things will go OK from then on.

Also, yes, given the "only ever one commander name" in this scenario there shouldn't be any way for the syncing to be causing this auth issue. One commander means EDMC only stores/retrieves one fdev_apikeys value.

[Unknown-Zombie]

Ok I got home and messed around a bit with the laptop and desktop side-by-side.

Deleting fdev_apikeys did not resolve the issue. Deleting this registry entry on both machines and then launching EDMC did not alter behavior. EDMC would require authentication every time it was first launched on opposing machines (not counting the first expected login after deleting registry keys, of course).

What I did notice is that every time EDMC launches, whether authentication is required or not, and even when launched on the same computer, the fdev_apikeys registry entry changes.

Cut/pasting the value of this registry entry between computers would allowed EDMC to launch without having to re-authenticate. But because the value changes every time the program is launched, unless the value is cut/pasted every time computers are switched then re-authentication is still necessary.

[Athanasius]

What I did notice is that every time EDMC launches, whether authentication is required or not, and even when launched on the same computer, the fdev_apikeys registry entry changes.

That's expected, because every time that Refresh Token is used in order to get a new Access Token it also returns a new Refresh Token, and invalidates that old Refresh Token, so the new one must be stored for future use.

Cut/pasting the value of this registry entry between computers would allowed EDMC to launch without having to re-authenticate. But because the value changes every time the program is launched, unless the value is cut/pasted every time computers are switched then re-authentication is still necessary.

Now I'm wondering if this is, in fact, just expected behaviour on Frontier's part. If they're seeing the same combination of:

1. EDMC's CLIENT_ID
2. Frontier/Steam/whatever account

and always storing only the one Refresh Token for that tuple, then that will precisely cause what you're seeing. The only solution would, indeed, be to find a way to automate syncing that registry key between the computers.

It does occur to me now that I've never tested precisely this scenario. I'm either using other software, with a different Client ID, or else testing with a different (Frontier, Steam, EGS) account.

Other than the registry syncing the only thing I can suggest is that you attempt using Steam authentication on one and Frontier authentication on the other. Maybe that will be enough to cause Frontier to consider them different.

[Athanasius]

Yup, I've just tested this myself, running a second EDMC instance as another user, but against the same account. Authorizing in that, and restarting the original EDMC instance, has invalidated the 'original' Refresh Token.

So you'll have to sync that Registry entry as well in your use case.

I feel an additional Wiki:Troubleshooting section coming on ....

[Athanasius]

Now documented at https://github.com/EDCD/EDMarketConnector/wiki/Troubleshooting#i-sync-journals-between-two-or-more-computers-and-have-to-re-auth-on-each-switch