Update - @devsleeper was able to resolve this issue by providing the webhook secret as part of the URL instead of via header parameters.

Correct me if I got that wrong @devsleeper !

Are you grabbing the proxy for another user?

The technique is described here - https://help.getbraincloud.com/en/articles/3631086-how-do-impersonate-a-user-using-the-braincloud-api -- and is commonly used in multiplayer scenarios when attempting to update the stats of other players after a match.

Could that be what is happening?

(Though admittedly it doesn't look like such from your code).

If you message into our support chat system with your appId and profileId (and timeframe for when this last happened) we can check our loggs and see if we can figure out what is happening.

Hi @PJ ,

Your usage of lobbies is exactly why we added the concept of long-lived lobbies. (Admittedly it wasn't part of the original use case - which is probably why some of the documentation doesn't seem to properly reflect that usage <-- we'll review that).

So - needless to say - keep going as you are - and reach out if you hit issues!

Happy coding!

Paul.

Hi @devsleeper - if you contact us through the chat widget we can go through your logs with you and see if we can get to the bottom of this. Thanks.

For what its worth - plenty of apps on brainCloud are using Photon - so I would expect it is possible... (though as you say - our webhooks are a single route each. As @JasonL indicates - you should be able to indicate the different functions via a parameter?)

Hi @PJ ,

Have you seen our RoomServerDevTool? https://github.com/getbraincloud/braincloud-roomserver-devtool

It allows you to setup your local workstation as a remote "Room Server" -- and then you can run and debug the server remotely. Basically brainCloud will attempt to launch a server to your workstation.

Paul.

Hi @immortal-ray-dev ,

I think that line for subscribing to topics wouldn't be necessary to receive the brainCloud push notifications... we send them directly to the users via the device tokens. Try eliminating it...

(We're checking on our end as well - will remove from the example if unnecessary).

Paul.

HI @tlim - the S2S API you are looking for is this:
https://docs.braincloudservers.com/api/capi/user/sysgetuserinfo

I might suggest that you write a cloud code script though - and send the list of profile ids to it. It can use this call to retrieve the info for each of the players - and return just the information that you need in your server.

I hope that helps!

Paul.

Ah - okay - the process of setting your app for push notifications depends a lot on the platform. From a brainCloud API perspective - you need to register the push notification device token with brainCloud. That's done via this method:
https://docs.braincloudservers.com/api/capi/pushnotification/registerpushnotificationdevicetoken

But first - you need to set up push notification services for your app with the the iOS App Store or Google Play store. These tutorials will help:

• iOS - https://docs.braincloudservers.com/learn/portal-tutorials/push-notification-configuration-ios/
• Android - https://docs.braincloudservers.com/learn/portal-tutorials/push-notification-setup-firebase/

I hope that helps!

Paul.

Hi @immortal-ray-dev,

Is your game online or offline? If it's online - it's better to enable RTT - and then receive the events that are sent as players make their turns. You register for the generic event handler to receive those events.
https://docs.braincloudservers.com/api/capi/rtt/registerrtteventcallback

The Push Notification capability is used mostly for cosmetic push notifications - which have the advantage of causing the user to launch back into the app. The brainCloud client doesn't have a handler for those - you'd have to use the platform-specific (i.e. ios vs. android, etc.) to receive those messages.

I hope this helps!

Paul.

Hi Lee,

I've reported this to the devs.

Paul.

Hi @LEE-JONG-GUN,

We've got a new button for you. It will be released next week.

Paul.

Hmm - I'll discuss with the devs to see what can be done to have more "open in another window" options for some convenient use cases like this one.

Hi @francesco-lenolli ,

The ProductService has actually been deprecated.

You should use the AppStore service instead.

I hope that helps!

Paul.

Yup. We as devs often resist change. Hopefully you'll come to appreciate Portal-X as you use it more!

No problem @kamil-preciuk - and keep that feedback coming!

Hi @kamil-preciuk,

Okay - there was definitely a regression on that page -- though it wasn't related to the feature I suspected. Anyway - check it now - it should be much much faster. And thanks for reporting it!

Oh - and everyone else - the Regions and App Store analytics pages are now live. Hopefully they help you to get great insights into your apps!

Cheers!

Paul.

Hmm - thanks for reporting this...

That screen IS seeming slow to me. I'm having the devs check it out. We recently added fetching of the entity size to the preview panes for Global Entities (and others) - and I'm suspecting that code may have crept into the routines that we use to fetch the list of objects? Maybe?

In any event - if you find things slow in Portal-X - definitely report them! A big focus of Portal-X was to have much better performance in dealing with larger apps with larger collections of data, users, etc... and in general I believe we've very much succeeded there.

Paul.

Hi Kamil,

Thanks for the feedback. I do appreciate that as we've worked to standardize the flows - that a few extra steps have been added to some of the usage flows. We'll continue to refine that.

Interesting regarding performance. Where abouts in the world are you located? And what screen are you seeing the loading data on?

D'oh - so sorry you will miss it.

Any thoughts on the features that made you like it so much? We are always looking for ways to make Portal-X better!

Paul.