Of course it can. We can give it it's own OAuth client id.
You need to implement the OAuth 2.0 PKCE flow with OpenID connect (https://oauth.net/2/pkce/).
It will require you to use a webview and hijack the redirect - which is what we started doing in the java client 1.5.0 RC1.
Our new OAuth service implements the auto-discovery feature (all data available at https://hydra.faforever.com/.well-known/openid-configuration).
How to do it in Python? I have no clue.
"Nerds have a really complicated relationship with change: Change is awesome when WE'RE the ones doing it. As soon as change is coming from outside of us it becomes untrustworthy and it threatens what we think of is the familiar."
– Benno Rice
Oh, I see. It will kill the offline mod, which is one of the most advantageous features (and I am lazy, of course).
But will the current working authentication method work in the future (the one that the Java client 1.4.7 uses)?
And what about the test server? It sends "invalid" to my "hello" commands, and there are no login parameters in the Java client 1.5.0 RC2. Is it suspended forever?
As a note I do not believe the test server is in a functional state currently due to some changes we have been experimenting with on it.
And I believe ideally the current auth method would be depreciated but I am not sure on removal and what not. First we have to get the new method ironed out.
You also need to make sure you’re sending it your uid as generated by the faf-uid binary in the hello command
I'm sure i'm sending uid, it worked like week or two ago, but now you'll get the error in the Java client (1.4.7, for example), too.
But will the current working authentication method work in the future (the one that the Java client 1.4.7 uses)?
No. It will be removed once all FAF services are migrated to the new version. This will probably take a very long time, but I wouldn't put any app to the old solution anymore just because it seems easier.
"Nerds have a really complicated relationship with change: Change is awesome when WE'RE the ones doing it. As soon as change is coming from outside of us it becomes untrustworthy and it threatens what we think of is the familiar."
– Benno Rice
@didvul said in API access for legacy client:
I'm sure i'm sending uid, it worked like week or two ago, but now you'll get the error in the Java client (1.4.7, for example), too.
I am not sure what error you are talking about. I haven't gotten any reports about failure to login.
OK, understood. Thank you for your responses.
@brutus5000 said in API access for legacy client:
... but I wouldn't put any app to the old solution anymore just because it seems easier.
Anyway for python client this solution would be new.
@sheikah said in API access for legacy client:
I am not sure what error you are talking about. I haven't gotten any reports about failure to login.
Probably because no one tried to login to the test server. (You've already told that it is not functional right now, so it was to Askaholic who had skipped your message apparently)
@didvul my comment was unrelated to Sheikahs. Since you haven’t posted anything specific about what you are doing we can only guess, and I wanted to mention the uid thing because it is a common mistake that people make when trying to implement authentication with our lobby server.
@brutus5000 said in API access for legacy client:
Of course it can. We can give it it's own OAuth client id.
Could you give legacy client its own client_id and client_secret to access the API like the Java client 1.4.7 does?