Inconsistency with Chat and realtime C++/UE4 SDK regarding custom authentication
Options
I was getting photon chat integrated into our UE4 project and had custom authentication setup for a server. Everything worked fine as is.
Once I started integrating the loadbalancing client, it would never call connectreturn() or any of the error callbacks, despite using the exact same custom provider for authentication. The workflow for both chat and real-time seemed identical as far as I could tell from the documentation. Upon further inspection, loadbalancingclient was getting stuck in PeerState::WaitingForCustomAuthenticationNextStepCall while chat wasn't.
Digging further into loadbalancing client, it seemed if the operationresponse contained a DATA parameter it was expecting a 'next step authentication call'. The documentation makes no mention of this:
Once I started integrating the loadbalancing client, it would never call connectreturn() or any of the error callbacks, despite using the exact same custom provider for authentication. The workflow for both chat and real-time seemed identical as far as I could tell from the documentation. Upon further inspection, loadbalancingclient was getting stuck in PeerState::WaitingForCustomAuthenticationNextStepCall while chat wasn't.
Digging further into loadbalancing client, it seemed if the operationresponse contained a DATA parameter it was expecting a 'next step authentication call'. The documentation makes no mention of this:
This seems to imply any additional data you want to return upon successful authentication you could put into a Data json object (such as usernames, profile stats, etc). The behavior is different if you are using the chat api or the real-time api. Is this working as intended?
Data: JSON object that contains any extra values that should be returned to the client. Please keep in mind that nested arrays or objects are not supported.
0
Comments
-
Hi @onealexleft,
Thank you for pointing this out.
Indeed there is a difference and I will update the documentation accordingly.
Photon Chat does not support Nickname and AuthCookie as those are not implemented (yet?!).
They can be received but skipped/ignored as not used.
I have to test the "Data" part though.Data
is expected whenReturnCode
is 0. Maybe you should returnReturnCode=1
.
My colleague @Kaiserludi will probably have more to say about native SDK part.0 -
On the server-side I only ever return 1, 2, or 3 at the moment for ResultCode. It seems the existence of the data field takes precedence over what the ResultCode is?JohnTube said:Hi @onealexleft,
Data
is expected whenReturnCode
is 0. Maybe you should returnReturnCode=1
.
0 -
I just updated my previous comment.
I'm currently testing this.
I will let you know as soon as I have results.
But what are you asking exactly?
Do you want to receive Data on client or
Do you have chat/realtime client that fails to authenticate?0 -
I was having issues with authentication, but it's all resolved now . At this point, just highlighting a possible inconsistency or unclear documentation with custom auth in the two apis. It tripped me up for a couple of hours as I could authenticate with Chat fine, but real-time didn't work until I removed the 'Data' portion from the response on my server. I decided any auxiliary data post-login could be done via a subsequent request.0
-
I'm interested in knowing why the returned Data caused the authentication failure.
Can you please help us have repro steps?
What type of Data did you try returning? I want to know if the issue is on server side or client side or native SDK related.0 -
sure!
if my server returns this for a real-time app:{ "Nickname": "", "ResultCode": 1, "UserId": 160, "AuthCookie": { "token": "862197b192c0dc5ac6940c30219349cab225945b" }, "Data": { "username": "" } }
The peerstate stays at 7 (waiting for next step)
but if my server responds with this:{ "Nickname": "", "ResultCode": 1, "UserId": 161, "AuthCookie": { "token": "2acba14e4cb1741c8918b8ebf4f66c058edc7157" } }
everything works just fine. If it helps, this is on Photon-Windows-Sdk_v4-1-8-0
this is the C++ for connecting (via ue4):NotificationListener = new ChatListener(); WebListener = new LoadBalancingListener(); FString AppVersion = "1.0"; ChatClient = new ExitGames::Chat::Client(*NotificationListener, *ApplicationID, *AppVersion); ChatClient->setRegion(L"US"); LBClient = new ExitGames::LoadBalancing::Client(*WebListener, *WebRPCID, *AppVersion); IOnlineSubsystem* ion = IOnlineSubsystem::Get(); if (ion) { IOnlineIdentityPtr IdentityInterface = ion->GetIdentityInterface(); FString AuthToken = IdentityInterface->GetAuthToken(0); FString Name = IdentityInterface->GetPlayerNickname(0); UE_LOG(HGLOG, Warning, TEXT("auth token for launching game under %s \n: %s"), *Name, *AuthToken); ExitGames::LoadBalancing::AuthenticationValues WebAuthValues = ExitGames::LoadBalancing::AuthenticationValues(); WebAuthValues.setType(ExitGames::LoadBalancing::CustomAuthenticationType::CUSTOM); WebAuthValues.setParametersWithUsernameAndToken(*Name, *AuthToken); UE_LOG(HGLOG, Warning, TEXT("params %s"), WebAuthValues.getParameters().cstr()); LBClient->connect(WebAuthValues); ChatClient->connect(); }
The UE_Log output for the auth values are placeholder in case you're wondering what those values that are getting sent to the server are (using the OnlineNullSystem for local dev testing):HGLOG: Warning: auth token for launching game under DESKTOP-MTGLVI3-06121AAB48657B82D18E6F84ECD7511A : DummyAuthTicket
0 -
Hi @onealexleft:
Thank you for reporting this.
I had a look at the Client implementation and at the linked auth doc and this is clearly a bug in Realtime.
We will likely need to deploy a fix to the servers + release an update of the client to activate the fix (the server needs to send an additional value that is currently not sent and old clients would just behave as before even with fixed servers, as they don't expect that value yet).
@JohnTube:I want to know if the issue is on server side or client side or native SDK related.
Actually it looks like a bug in the client-server protocol definition for the auth-response.1