Oculus entitlement on UE4 is broken by recent Oculus app update

Just to add this feature has been working solidly for months and we've done the sanity check of logging out and in again, restarting computer, trying this on a couple of different systems with a couple of different Oculus accounts and have also verified that the problem starts at the exact moment of the Oculus software update. So far I haven't seen this problem affect anything in my app library so perhaps it is either something that only affects apps under development or something that is a problem with my own developer account. Likely though that Oculus has introduced a bug with their latest software update. Thanks

Additionally attempting the native sample from the Oculus Platform SDK 1.19 I see the following:

tomotor said:

Hi there, 
The latest update of the Oculus app that is automatically updated has introduced a problem for me that has broken the entitlement check and the ability to talk to the Oculus platform for our app we are working on. To reproduce this problem create a new blank app in UE4, go to plugins and check off the Oculus Online Subsystem add the following to the level blueprint:


Add a test app to developer.oculus.com and get the App ID 
Then go to DefaultEngine.ini, add the following

[OnlineSubsystem]

DefaultPlatformService=Oculus

   

[OnlineSubsystemOculus]

bEnabled=true
OculusAppId=(The App ID from above)

Then restart UE4 and run the app in VR preview or selected viewport and see the following in the log:

....

LogOnline: Display: Oculus: FOnlineSubsystemOculus::InitWithWindowsPlatform()

LogOnline: Warning: Oculus: Failed Oculus login. Not currently logged into Oculus.  Make sure Oculus is running and you are entitled to the app.

...

LogOnline: Error: Oculus: Failed the entitlement check: OVR6139226

LogBlueprintUserMessages: [Minimal_Default_C_0] Failure

...

This is with UE4.18.0, but I am seeing this too in 4.15.3 with Oculus 1.14, and this problem is grinding everything to a halt for us.

Thanks

Hello,
I am having the exact same problem here, since the Oculus app update to version 1.20 last week.
Same error codes, same error messages. Also tried, as you did, with a blank project, just setting up oculus app id, turning on the Oculus Online Subsystem, and calling Verify Entitlement. It always return through the Failure delegate.
I would like to add that I've tested with the following Unreal Engine versions: 4.18.0 binary release, 4.18.0 source release (github), and 4.16.3 binary release. All of them have the same results, regardless of the user logged in the Oculus App (entitled to my app or not).

This seriously need to be fixed ASAP, since it is preventing us from continuing any kind of Oculus related work. I imagine many more developers are having the same issue.

I'd like to say this is happening for us as wel with the exact same logs that @toddsdk has. We are running on 4.17 currently (about to update to 4.18). We have setup match making with Oculus to work fine. Now all of a sudden the login call to Oculus always fails.

imperativity said:

@toddsdk

Oddly enough we cannot reproduce this on our end.

Here is some commentary from our integration team:

"it's possible that developers might be mis-remembering and launching their old apps through the release channel, but their machine isn't configured for local development. So when the new version is out, they try opening the project and side-loading and it fails."

This is 100% not a developer issue. Our app is not launched yet and no builds have even been uploaded to any channel. We only created an app to give our Oculus accounts entitlements to develope our game.  No code/app configurations on our side have changed since and Oculus just stopped working.

I would like to add that I tested Oculus on Nov.1st and it was still working. Now its Nov.13th and it's broken, so it must be a very recent issue that broke it

Thanks for looking in to this, Imperativity. I think I figured out the problem here. Entitlement used to run outside of the release channel system. In my organization on developer.oculus.com I could set up admins, developers and test accounts and give any of these an entitlement to the app I am testing by simply checking them off. According to what I have seen in the documentation and what has worked so far this should work. 

With the update though I am not seeing an entitlement until I upload something to the release channel and then add myself or whoever else as a user using their email address from the Manage Builds page and have them click the link on the email accepting the invitation.

So we appear to have found a way through this problem, though the old system was easier and more intuitive, and it didn't seem obvious to anyone that this was the missing step. If there is documentation anywhere spelling this process out I haven't seen it.  

One thing though I want to point out is that the Upload New Alpha page in the Manage Builds section tells you to be sure to implement the entitlement check before you upload anything, but uploading something is a prerequisite step to setting up the entitlement, so I recommend changing the instructions or the process to be more intuitive.

Also in developer.oculus.com in the Settings section under Members, if you Manage Apps for a user it says "Please select the apps which tomotor is entitled to as a developer" and the checkboxes there don't actually give an entitlement.

 It would be convenient too to be able to check off users and test users that you have added to your organization in the section where you add users to the Alpha channel. I haven't tried, but I'm not sure if its going to be possible to give an entitlement to test users as oculus makes up email addresses for them. 

Thanks again

tomotor said:

Thanks for looking in to this, Imperativity. I think I figured out the problem here. Entitlement used to run outside of the release channel system. In my organization on developer.oculus.com I could set up admins, developers and test accounts and give any of these an entitlement to the app I am testing by simply checking them off. According to what I have seen in the documentation and what has worked so far this should work. 

With the update though I am not seeing an entitlement until I upload something to the release channel and then add myself or whoever else as a user using their email address from the Manage Builds page and have them click the link on the email accepting the invitation.

So we appear to have found a way through this problem, though the old system was easier and more intuitive, and it didn't seem obvious to anyone that this was the missing step. If there is documentation anywhere spelling this process out I haven't seen it.  

One thing though I want to point out is that the Upload New Alpha page in the Manage Builds section tells you to be sure to implement the entitlement check before you upload anything, but uploading something is a prerequisite step to setting up the entitlement, so I recommend changing the instructions or the process to be more intuitive.

Also in developer.oculus.com in the Settings section under Members, if you Manage Apps for a user it says "Please select the apps which tomotor is entitled to as a developer" and the checkboxes there don't actually give an entitlement.

 It would be convenient too to be able to check off users and test users that you have added to your organization in the section where you add users to the Alpha channel. I haven't tried, but I'm not sure if its going to be possible to give an entitlement to test users as oculus makes up email addresses for them. 

Thanks again

Does that mean we need to upload a build before we can give entitlements now? Prior to this, we didn't upload any builds and it seems that all our dev accounts were able to get entitlements to use the SDKs. Is it ok if I upload to Alpha channel to get entitlements rather than release channel?

Hi, the release channel includes the alpha channel, so if I have the nomenclature right, the release channel includes the store, beta, RC and alpha channels. I think you can upload to any channel in there or even add a new channel. The upload doesn't have to be the same package you are testing, just needs to be a zip file with an executable in there. I used the native sample application. 

> Does that mean we need to upload a build before we can give entitlements now? 

That's my theory based on what I had to do to get it to work. I'd be interested to hear a confirmation of that from Oculus.

tomotor said:

Hi, the release channel includes the alpha channel, so if I have the nomenclature right, the release channel includes the store, beta, RC and alpha channels. I think you can upload to any channel in there or even add a new channel. The upload doesn't have to be the same package you are testing, just needs to be a zip file with an executable in there. I used the native sample application. 

> Does that mean we need to upload a build before we can give entitlements now? 

That's my theory based on what I had to do to get it to work. I'd be interested to hear a confirmation of that from Oculus.

Thanks so much for your response! I will definitely give this a shot. Hopefully this will fix the problem we are having right now.

Hi this is happening to us too. Just doing a plain 'GetOculusIdentity' using a blueprint and running the game from the editor (PIE) is returing a fail. And we have done the setup in the .ini files that are required.
The same exact setup has worked before.

We are using UE4.17 with Rift on PC.

Could you please clarify if there is a workaround to this as we are just now needing this to function. :P
We do have an older build version of the project uploaded to the 'Alpha' channel but that doesn't seem to help.

Cheers
Fred

UPDATE:  I uploaded a fresh build to the Alpha channel and now it does give me an OculusID but only on the first PIE run. The subsequent runs all fail. I then restart Unreal and again the first go gives me the OculusID and the subsequent PIE runs fails. And so on.

So whilst that still means that we cannot continue to work it might give you some more clues.

Any idea when this should be fixed?

Awesome! :)
Is that something that is being fixed on Oculus' server side or in the Unreal code?
Ie, would I have to update my engine version, to a Github source version, to get the fix?