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

crash at startup, unable to log in #948

Closed
punkerich opened this issue Nov 18, 2018 · 31 comments
Closed

crash at startup, unable to log in #948

punkerich opened this issue Nov 18, 2018 · 31 comments

Comments

@punkerich
Copy link

EDDI version in which issue found

3.1.0

Steps to reproduce

After an Win 10 update today, EDDI crashed at startup.
Found credentials.json to be the culprit.
Deleted and started anew, requested varification code didn't seem to work.
It says 'unable to login' all the time. When reentering password and clicking next,
nothing at all happens.
After closing and reopening EDDI, it crashes again.

EDDI log:

eddi.log

I'm not exactly sure If EDDI automatically requests a new VC when entering of the first one fails.
It's a pain to test, bc sometimes it takes up to 1.5h until the code arrives.

@Tkael
Copy link
Member

Tkael commented Nov 18, 2018

At least at the moment, the API appears to be functional.

untitled
When you enter an incorrect username or password, you should see "Username or password incorrect"
When you enter an incorrect code, you should see "Confirmation code incorrect or expired"

Try making of your complete config files by copying %APPDATA%/EDDI to another location. Then delete %APPDATA%/EDDI and attempt to restart EDDI. Is it still unstable?

@punkerich
Copy link
Author

punkerich commented Nov 18, 2018

I started with a fresh %APPDATA%/EDDI folder, as soon as i copied back the credentials json as per troubleshooting, eddi won't start anymore, see log file above. when deleting the credentials.json starting again i enter my email + pw, wait for the verification code (...) and enter it. after that i get: grafik
entering the pw in that window and clicking next does nothing.
closing will have eddi crash on next startup.

Tried again with absolutely naked %APPDATA%/EDDI, getting exactly the same.

@punkerich punkerich reopened this Nov 18, 2018
@Tkael
Copy link
Member

Tkael commented Nov 19, 2018

Hmm. Unfortunately, that's the least helpful version of the message that EDDI could write at this stage. It tells me that some exception is occurring during the login to the Companion API, but not really anything else, and as the message states it is normally something like a temporary connectivity issue with the Frontier server.

I'm going to need you to try again, but this time before entering your verification code I'd like you to please turn debug mode on.
After it crashes, retrieve the log file. It should be free of personal data like your Frontier credentials, but go ahead and check (using a find function) to make sure. Redact personal data as required. Then attach the debug log to this issue and let's see if it can shed any more light on what's going on.

@punkerich
Copy link
Author

punkerich commented Nov 19, 2018

By 'after it crashes', do you mean after entering the code, or after entering pw the second time, closing and trying to open next time? What i find strange is that, for example, EDMC didn't need to verify again. It still works the same like before the update... There seems to be something different in EDDI regarding the authentication...

edit: It's insane. Already waiting for a full two hours for FD to send a key... Anyone got C-64 to spare?

@punkerich
Copy link
Author

punkerich commented Nov 19, 2018

Some suggestions: leave a hint in EDDI setting verbose logging needs a restart of EDDI.
It says a log will be placed on the desktop, wrote into the usual loc. in APPDATA instead.

Somebody really hates me. Always getting the 'something went really wrong' when trying to upload the file here. So, the probably most interesting line here in plain:

2018-11-19T22:21:25 [Debug] CompanionAppService:GetResponse Response is {"m_HttpResponseHeaders":["Pragma","Strict-Transport-Security","Vary","X-UA-Compatible","Connection","Content-Length","Cache-Control","Content-Type","Date","Expires","Set-Cookie","Server"],"m_Uri":"https://companion.orerve.net/user/confirm","m_Certificate":null,"m_Version":{"Major":1,"Minor":1,"Build":-1,"Revision":-1,"MajorRevision":-1,"MinorRevision":-1},"m_StatusCode":200,"m_ContentLength":1376,"m_Verb":"POST","m_StatusDescription":"OK","m_MediaType":null}

edit: sent the full file via pm in ED forum.

@Tkael
Copy link
Member

Tkael commented Nov 20, 2018

  1. Verbose logging does not require a restart of EDDI. It's effective immediately.
  2. Placing a log on the desktop occurs when you click the Report an Issue button. I agree this should be clarified.

I'm going to go through the authentication procedure on my PC again so that I can compare results to your logs.

@punkerich
Copy link
Author

1.: strange, i activated verbose before entering the code, checked the log directly after. no changes.
so i restarted eddi and entered the code again, log was written then...

@Tkael
Copy link
Member

Tkael commented Nov 20, 2018

Ok. The response to your companion code is a little different from what we expect to see... there should a Location key in the response and it's missing. The status message should be Found, not OK.
To make sure we're on the same page, this was not using the original credentials.json you identified as bad? This is re-entering your credentials from the beginning?

The authentication process requires us to send a couple of cookies to Frontier with your code. These cookies are generated from the data the server sends in response to your username and password and the data needed to generate them is stored in %appdata%/EDDI/credentials.json.

The login works for me and I'm not aware of anyone else reporting this issue. It could be an issue with your specific account and the tokens that Frontier is generating and sending. Have you tried

  1. Logging in to EDDI via a different PC?
  2. (If you have multiple accounts) Signing in with a different account?

@punkerich
Copy link
Author

This was using a fresh credentials.json (deleted the file before).
I don't have multiple accounts, but will try from a diff. pc.

@punkerich
Copy link
Author

Can there be a thing with the generation of these cookies? As in they'd need to be overwritten but can't? Can i look these up?

@Tkael
Copy link
Member

Tkael commented Nov 20, 2018

Possibly caching with a bad cookie? You can try clearing system cookies (via either Internet Explorer or your default browser, I'm not sure which), but I'm not confident that it'll have any effect.

@punkerich
Copy link
Author

Will check those cookies when i'm home in the eve. On the other hand, i got a small convertible Laptop running win 10 also, will try to install EDDI standalone on there. I assume authentication should work even without Elite or VA installed? No other gaming rigs at hand...

@Tkael
Copy link
Member

Tkael commented Nov 20, 2018

Sounds like a plan. FYI, there's a bit of an issue with fresh installs expecting a folder to already be present at %appdata%/EDDI prior to the first run. Create that folder before installing and you shouldn't run into any issues.

@Tkael
Copy link
Member

Tkael commented Nov 20, 2018

And yes, authentication does not require Elite or VA to be installed.

@punkerich
Copy link
Author

Aye, already saw the other issue.
Besides, i already opened a ticket at FD support, referencing this issue.
I don't hold my breath, but with a bit of luck they provide a hint on what to look at funny to solve this.
I'd outright refuse to play again without (a fully functioning) EDDI.
It's that important for me ;-)

@punkerich
Copy link
Author

oh, oh... getting the exact same error on the laptop... that's not good at all...

@Tkael
Copy link
Member

Tkael commented Nov 21, 2018

I'm sorry to hear that, and curious to hear what FDev support might have to say. They may be able to reset something on their end?

@punkerich
Copy link
Author

Now in contact with FD support, had to clarify some things on behalf of 'As I am not sure what you mean by "there should be a Location key in the response and it's missing'.

I don't want to be disrespectful by any means, but one question still stands: why is it (seemingly) just EDDI that needs to re-evaluate, not e.g. EDMC? Do they handle the machine-ID maybe different in like generate one, once, and perma-use that even if changes would occur? I will test activating EDMC, too, on the laptop when i'm home again. If that works flawlessly, wouldn't that mean it's something with EDDI in how it's processed? Maybe it's a local thing, like different return strings depending on country or somesuch?

Looks a bit like options running out on my side... sigh. I'd so love to be able to get deeper into scripting...
and i feel really bad for wasting so much time on your end, i really do.

@punkerich
Copy link
Author

EDMC authenticated flawlessly on the laptop. So, maybe FD really have different formats of replys to the process, and a submitted 'OK' indeed is, well, ok? Either this, or the request for the code is different.
Maybe really a 'slight' adjustment to the verification process is needed to make it work again...

@punkerich
Copy link
Author

punkerich commented Nov 21, 2018

This came just now in from FD:

Thank you for getting back to us.
This is something you may need to raise with the folks over at EDDI. This is a new system
that they are using so there may be issues. You can reach out to them here:
https//github.com/EDCD/EDDI
I hope this helps, however, if there is anything else we can do, then please reach out to
us.

So, they mention a 'new system', dunno what could've changed?

edit: EDDI seems to request a new code everytime when the process isn't finished, and you open it up ending on the api tab while EDDI is asking for the code. any chance to stop that?

@Tkael
Copy link
Member

Tkael commented Nov 22, 2018

FDev have been working on a new authentication system but the EDCD community has identified some issues and FDev is reworking their implementation. We haven't yet begun to transition over to their new system. We're still using the old system, essentially unchanged since before we took over management of the code. Frustratingly, documentation for that system is nill and since I can neither replicate what you are seeing nor reference any documentation I'm flying blind.

EDDI is recognizing that the authentication process is incomplete and trying to complete the process. Using the Reset button or deleting credentials.json should stop EDDI from re-requesting a new code each time you launch EDDI.

@Tkael
Copy link
Member

Tkael commented Nov 22, 2018

We're waiting for FDev to get back to us...
untitled

@punkerich
Copy link
Author

Thanks Tkael, i'll just wait it out, then. If you need me to test something hit me up here or in the forum.

@punkerich
Copy link
Author

Is there any news on this? Tried today with 3.3.0-b1, i don't even get to the 'enter vf code' window anymore. after entering mail+pw, clicking next, i directly get the message 'unable to log in', the eddi.log shows this:
2018-12-12T19:32:30 [Warning] CompanionAppService:GetResponse Failed to obtain response, error code ProtocolError

@Hoodathunk
Copy link
Contributor

Hoodathunk commented Dec 12, 2018

@punkerich everybody (not just EDDI) is down hard. FDEV included the new authenication process in 3.3, without any documentation on how to implement it. Even if we did, its broke and unusable.

It's bad right now.

@punkerich
Copy link
Author

punkerich commented Dec 13, 2018

Well, normal FD behavior, aye. XD
Just asking bc i haven't seen similar issues popping in for EDDI.
I'm happily playing a different game atm, just waiting out the usual patches of ED and 3rd party tools after a big update. I get it must be frustrating for you devs giving up on your free time to solve this...

edit: just seen the first similar posts, so it's not just me. what i can't wrap my head around is why i had these issues so early when others didn't... well, we'll see how it goes.

@Tkael
Copy link
Member

Tkael commented Dec 15, 2018

If this issue is related to trying to obtain data about a star system that isn't known to our legacy server, it may have been fixed in the latest beta.

@punkerich
Copy link
Author

@Tkael Sure you meant to post it here? Not sure what the authentication process should have to do with obtaining system data...?

@Tkael
Copy link
Member

Tkael commented Dec 15, 2018

Not directly, but indirectly it might trigger something. Worth a try in any case.

@FireSammy
Copy link

FireSammy commented Jan 1, 2019

Haven't been able to API connect since early december (cant remember exactly when i noticed this problem). EDDI still seems to work quite well, but of course, some variables will not work.

@Tkael
Copy link
Member

Tkael commented Feb 3, 2019

I'm assuming that this issue is resolved at this point. Please let me know if it's still an issue.

@Tkael Tkael closed this as completed Feb 3, 2019
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

4 participants