We are developing our service using BrainCloud's S2S capabilities. The client-side application does not include the BrainCloud SDK. This is because we already have our own authentication system. When creating users via S2S, we use the "External Auth Create" method and subsequently handle operations based on the profileId. Therefore, to maintain a structure where existing user information is updated through the client's login process, the server must directly call the client authentication dispatcher API. In the S2S setup, there is an issue where authentication calls can only be used to issue sessions via the s2sdispatcher. Consequently, the server is manually invoking authentication using the client-side API. I consider this flow to be abnormal. After all, even though the integration is S2S-based, the client login API still needs to be called once. However, the issue is that without calling the client authentication, there is no way within the S2S setup to update the last login time and certain other information you mentioned. I believe this is a common issue that can arise when adopting and using Brain Cloud within an existing system, much like in our case. In summary, the user has created an external account in BrainCloud via the server using sysCreateUserExternalAuth. We issue a token to the user based on our internal authentication system, signing it using the BrainCloudProfileId. Consequently, authentication via the BrainCloud client is no longer required. However, without client-side authentication, there is no mechanism to update information. We need to find a solution to address this gap.

The fix for this has been deployed... (a couple weeks ago actually - apologies for the lagging notice!)

@JasonL It works! Thank you!

Thank you! That was a huge help.

Is there no solution for this issue? Sending PDFs via email is very inconvenient. I would appreciate it if you could raise its priority.

We've deployed the patch for this. Apologies for the delay!

Case 14697

Awesome. Thanks for confirming @lee-jong-gun !

Cool - glad you found it!

Thank you!

Hi @jongdae.won , brainCloud 6.0.1 has been deployed. The Campaign Analytics feature - as well as the APIs for updating the campaign and scenario JSON, are now live! Paul.

Thanks for letting us know and your own solutions! We'll see if we can patch this into the JsonFx library we're using for future versions of brainCloud to avoid these edge cases.

Created case 14475

Hi, Apologies for the slow response. We don't have any calls that could directly handle a "file" of profileIds. We do have a few "toBatch" calls that are callable from S2S though - so you could probably have an offboard system make those calls - and call braincloud to send the notifications in batches. Where are these profileIds coming from? An offboard analytics system of some sort? To answer your questions: We are planning a revamp of our notifications system and it's APIs. I'll add this conversation so that it will be considered as we're planning that. As mentioned above, using one of the "Batch" calls would make the most sense - and keep your API counts reasonable There's an API call to call the SendRichPushNotificationWithParams, plus a second api call for the sending the push notification itself. So that would be <numReceivers> x 2 for API costs. Less if called from within a script. But the *Batch() calls would be Substitutions and custom metadata/custom data - the current APIs don't - so you'd probably need to handle those client side. Are the substitutions highly personal - like player's name? I hope that helps to clarify things, Paul.

Hi @moondory77 , We hear you - and are looking to see what options we can provide. The thing to understand is that there are a lot of dependencies between metadata in the brainCloud system - and our deployment mechanisms work hard to ensure the integrity of the data that gets pushed. Even more importantly - it works to prevent user data from being corrupted by a mis-match of data during deployments - which is why apps are very temporarily disabled during a deployment. These deployments normally take well under a minute and aren't much more troublesome than a common wifi interruption for clients [depends upon the client implementation though]... (note - the deployment may seem like it takes longer on the web - as there is a lot of data dependency checking to do - but all of that is done BEFORE we disable the app... which happens just for the actually data migration activity itself). If you contact us via the support chat with your appId and the time you last did a deployment - we can take a look to see if your deployment times are above normal. Also - we are working to provide a separate custom entity deployment mechanism - similar to what has been done for item management. Paul.

Unfortunately, our notification templating system is very simple and currently only supports simple text notifications. It does not currently push a template id. We do have plans to revamp the system on our "to-do" list - but it has not been scheduled yet. We recommend folks use the "raw" template calls - they give devs the most control over what gets sent to the various notification systems. Paul.

Hi, API calls triggered by the backend DO count towards API usage -- so using the API Explorer to make calls do get counted as API calls. So - if you use API explorer to trigger a user batch job that then runs scripts on all of your users - yes, yes that does get counted as API calls. Also - uploads of files to and from the portal do get counted in the file transfer costs. Other normal portal operations - like viewing users, viewing logs, editing scripts, etc - do NOT get charged in API counts. So to clarify - using the API explorer to view a leaderboard is going to add an API count - but using the leaderboard viewer at App > Global > Leaderboards > Leaderboards does not! To be honest - in general - usaging of the portal is negligible. You won't really notice the usage added by what you're doing in the API explorer or working through the portal. It's only if you use the API Explorer to kick off a large job that API counts would be noticable <-- as you'd expect! I hope that helps! Paul.

Hello @Paul-Winterhalder I apologize for the repeated questions, but I am following up on this again because our live service experiences a temporary outage every time we attempt to deploy only data to our production environment. Even when the operation is strictly intended to deploy only customEntities, as shown in the payload below, the temporary "App is disabled" state still occurs: { ... "allowLiveUpdate": true, "components": { "meta": true, "scripts": false, "files": false, "customEntities": true, "legacyFiles": false }, "options": { "meta": { "excludes": { "itemCatalog": true, "productPricing": false, "pushCertificates": true, "integrations": true, "myServers": true, "lobbies": true, "leaderboardsTournaments": true, "independentLeaderboards": true, "divisionSetConfigsOverride": true, "migratableGlobalEntities": true, "migratableCustomEntities": false, "selfServiceBranding": true } } } } We would like to know the exact scope of deployment conditions where the "App is disabled" state does not occur. While we understand that it might not be possible to prevent the disabled state across all deployment processes, we would like to at least define and narrow down the conditions. We are hoping there is a way to migrate at least customEntities between environments without triggering the app disabled state. It would be even better if there were a way to specify and migrate each collection individually.