API access for legacy client
-
Can the legacy client also have access to API (via OAuth or smth)? If so, how to organise this?
-
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.
-
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.
-
@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_idandclient_secretto access the API like the Java client 1.4.7 does? -
That is the depreciated method that will be getting removed and shouldn't be used. You would need a new oauth client to log into the new user service.
