• Categories
  • Recent
  • Tags
  • Popular
  • Solved
  • Unsolved
  • Users
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (Darkly)
  • No Skin
Collapse
brainCloud Forums

brainCloudAdmin

brainCloud personnel

Private

Posts


    The Unreal Engine Bootcamp Suggests Storing The Secret Key In The Game Files
  • Paul WinterhalderP Paul Winterhalder

    Hi @greggoryaddison ,

    Good question - and it points out some differences (and similarities) with PlayFab.

    Playfab rationalized that they didn't need a client secret because:

    • it wouldn't be secure anyway
    • and they had separate CLIENT vs. SERVER APIs.

    Well - brainCloud actually has the same API separation - in our CLIENT vs. S2S APIs -- but we figure security is all about layering - and so we still require the app secret in the client.

    But note that this app secret is SEPARATE from the secrets that get use for privileged SERVER/S2S API calls. When you declare an external server interface a separate secret is generated just for that interface. And that secret you'd normally keep in a .env file on server... Our Builder API uses a similar concept (also with separate API keys).

    The brainCloud CLIENT APIs are very sandboxed. You can only access info about your player -- you explicitely can't access information about other players. You can also use API Blocking to prevent even those sandboxed calls from being done from the client. And implement sensitive calculations and operations in cloud code scripts that run on the server.

    So - the app secret isn't as sensitive as you'd think.

    That said - there are some best practices to improve things:

    • Store it in a configuration file (not the source itself). That makes it easier to swap builds across dev/staging/prod versions of your app. Add it to .gitignore to ensure it isn't store in your source repo directly.
    • Ideally obfuscate the string in storage - so it's harder [though not impossible] for attackers to read

    So - in summary - the app secret that our client uses is an additional layer of security that Playfab doesn't have. It is still separate from the secrets that the privileged S2S and Builder APIs use - so there's no compromise there.

    I hope that helps to clarify things!

    More info here - https://help.getbraincloud.com/en/articles/14855017-storing-your-app-secret-safely

    Paul.


  • My Dashboard Is Showing Abnormal Numbers For API Usage
  • Paul WinterhalderP Paul Winterhalder

    Hi @greggoryaddison ,

    Send a message into our support chat with your appId and we'll check it out.

    Numbers like these would tend to indicate a low DAU for the app (common in development) - with maybe some background processes that you are debugging. Normally the api counts for those processes would be absorbed across a bunch of Daily Active Users - but since your DAU is low, the API / DAU is going to look very high.

    Anyway - send us you appId and we'll take a look.

    Paul.


  • missing features
  • johnhJ johnh

    Dear @dbgtdbz2 ,

    About your feature request #2. "Required item conditions for virtual and bundle items"

    Question 1:
    For your feature request, do the prerequisite requirements need to apply in the case that the item is included in a Cash Offer (or Cash Bundle Offer that this item might be within)?

    Question 1b:
    If YES that means a Cash Purchase attempt by the player could be denied by brainCloud due to the player not having the required Item. Is that appropriate?

    Question 2
    In the case that an item attempts to be awarded to the user by way of a Quest, level up, or gameplay mechanic, if the player does not have the prerequisite items, what should happen?

    Thanks,
    JH


  • missing features
  • J JasonL

    Thanks for the suggestions, we will look into it...


  • Does LeaderboardService.RemovePlayerScore revert rewards?
  • J JasonL

    Q1: The removed player is completely excluded from reward calculation, so if the deletion happens before the job runs, that player is never iterated over and receives no rank or rewards.
    Q2: Yes, the modified score will be used. The job always reads live state. Note that whether the score actually gets modified depends on the leaderboard type (e.g., for the LOW_VALUE type, only updates if the new score is less than the existing)
    Q3: No backfilling, the next joiner goes to the latest instance, not the freed spot in ^2. No loop over earlier instances (^1, ^2) ever happens. The next joiner goes to ^3 (or ^4 if ^3 is full). The freed spot in ^2 stays empty permanently.


  • Does LeaderboardService.RemovePlayerScore revert rewards?
  • J JasonL

    No, RemovePlayerScore() does NOT handle reward reversals. You need to handle that manually. Also note that if the leaderboard is configured for a tournament, it will throw an exception and refuse to remove the score. Call LeaveTournament() for a tournament-based leaderboard, but it does not reverse rewards either.


  • NewUser detection issue
  • J JasonL

    The aggregation that counts new users is not real time, it runs at hourly granularity, so there can be a delay before the stats reflect the actual number of users. At the time of checking again, the numbers had updated as follows
    image.png


  • Request for Granular Migration Options in Deployment (Excluding DivisionSetIds)
  • Greg MouldsG Greg Moulds

    Hi @noah ,

    This support has already been added to the Builder API. The new options can be specified when importing app configuration data OR when deploying an app.

    When importing app configuration data, there is a new optional 'preserveDivisionSetConfigsOverride' parameter that can be specified. If not specified, it will default to whatever the value is for 'preserveLeaderboardTournamentConfigs'.

    When deploying from one app to another, there is a new optional 'divisionSetConfigOverrides' parameter that can be specified in the 'options.meta.excludes' section. If not specified, it will default to whatever the value is for 'leaderboardsTournaments'.

    I will endeavour to get our Builder API docs updated with these new parameters. Let us know if you encounter any issues using them.

    Thanks!
    Greg


  • Inquiry Regarding Tournament Reset Schedules and Early Season Termination
  • Paul WinterhalderP Paul Winterhalder

    @moondory77 - why would you need/want to update a tournament in progress?

    We consider the tournament to be a contract between the player and the game dev. You enter this tournament. You have <X> hours to compete. And you can win <Y> in prizes.

    Changing the rules half-way through the tournament seems unfair? You are changing the duration? The prizes? These are both things that the player did not agree to.

    Anyway - that was the assumption of the system - and it's why once a tournament is started any changes you make to the tournament get queued up for the NEXT tournament cycle, not the current one.

    That said - divisions are even more complicated - as even if we wanted to there would be potentially thousands of records to update to make the change.

    I need to better understand your use case to consider this request.

    Paul.

Member List

R Roger Masse
Paul WinterhalderP Paul Winterhalder
C Claire Raby
C Corey Clarke
Mark DouthwrightM Mark Douthwright
A adamg
bitAlexiB bitAlexi
Hoar JoanneH Hoar Joanne
johnhJ johnh
V Vasanthan Rajendran
C Cody Melvin
Scott SimpsonS Scott Simpson
R Rick McMullin
Pierre ProulxP Pierre Proulx
Michael CostaM Michael Costa
N Nick Haidar
Franco LagoF Franco Lago
J JasonL
Greg MouldsG Greg Moulds
H Holly Leung
  • Login

  • Login or register to search.
  • First post
    Last post
0
  • Categories
  • Recent
  • Tags
  • Popular
  • Solved
  • Unsolved
  • Users