Forum ‹ BigDB ‹ init player objects

[Peter_Pain]

How do i know i am loading a player object for the first time so i can initialize it?
I tried to check obj == null or obj.property.length == 0 but that don't seem to work.

[dreamora]

define a specific property in it, we have id and password.
then after the user logged in see if playerObject.Contains("id"), if not -> new player and needs initialization
after that call Save on it to ensure its persistent

[Peter_Pain]

i tried this in loadMyPlayerObject callback function and i get "contains is not a function" error

[dreamora]

sure you are accessing the real player object of the Player class you created and not some fictive one?

[Peter_Pain]

it just that i was thinking about the client side.
On the server side can i use it before the player joins a room right after he logs in with quick connect?

[dreamora]

Before he joins a room you have no server side code as you only code distinct rooms
As such no. He joins a room, verifies his existance (the player object loading takes place automatically if the room type is correctly configured) and then goes on.

don't know if you can do it on the client side, for obvious security aspects I thought would NEVER grant access to the playerobjects table for the public connection

[Henrik]

How do i know i am loading a player object for the first time so i can initialize it?
I tried to check obj == null or obj.property.length == 0 but that don't seem to work.

You can't. What you should do is check for properties and create those and save if they're not present.

If you think ahead a bit to the next version of your game where you've added some properties to the PlayerObject, the above checks will catch the case where old players return and need these new properties, but keep their old ones.

[Henrik]

i tried this in loadMyPlayerObject callback function and i get "contains is not a function" error

AS3 is dynamic, so you don't need any methods that take property names like you do in C#, just access the property directly and see if it's there.

Code: Select all

if (obj.username == null) {
    obj.username = "...";
    obj.save();
}

[Henrik]

don't know if you can do it on the client side, for obvious security aspects I thought would NEVER grant access to the playerobjects table for the public connection

No, that's fine. The default security settings for the PlayerObjects table is set such that you can only read and modify the playerobject of the user you connected as.

If you add the various Load access rights, then you can read any playerobject, but you can still only modify your own.

[dreamora]

Which is exactly the reason not to allow it for me.
As you need to have a 'replicable way' to calculate the connectionid, anyone else can modify the client and request any users data for which they know the relevant token. And getting FB IDs or mail addresses and alike is really absolutely trivial. Even more so as Player.IO does only support insecure technologies at the time (.NET and Flash) where decompilation is a trivial task in the majority of cases.

So you can basically get all the user data as long as you know their 'unique identifier' from which the connection id is generated - mail, FB id, ... - and read their password which is pretty surely stored in there too


We do not and will not expose PlayerObjects or anything similar to read from client, only 'common access 0 critical' tables are exposed. The rest is requested and provided by the server which does not take an id as parameter but an internal lookup basing on the users data to ensure that he can't leave his own boundaries.

Would be a different topic if we could control the access of requests or limit it to 'own objects' but that concept doesn't exist and wouldn't make too much sense either for a plentitude of reasons

[Henrik]

As you need to have a 'replicable way' to calculate the connectionid, anyone else can modify the client and request any users data for which they know the relevant token.

Not if you use QuickConnect and disallow regular connects. Then the only way to connect as someone else is by knowing their SimpleUser password, or their Facebook password, or their Kongregate password.

So if you use QuickConnect, it's perfectly safe to allow the client to read PlayerObjects, since each player can only access their own playerobject, and noone else's.

Even more so as Player.IO does only support insecure technologies at the time (.NET and Flash) where decompilation is a trivial task in the majority of cases.

There's no such thing as a secure client technology. You can't ever trust the client, not even if your code is running on locked-down hardware such as an Xbox360 or PS3.

Would be a different topic if we could control the access of requests or limit it to 'own objects' but that concept doesn't exist

That is exactly what the "Full Creator Rights" checkbox does in the BigDB Table setup.

[dreamora]

I don't see how 'full creator rights' are related to 'you can request whatever you know the key off'

But thats good to know that Quick Connect prevents loading any other object from the PlayerObjects table simply by key

[Benjaminsen]

I don't see how 'full creator rights' are related to 'you can request whatever you know the key off'

But thats good to know that Quick Connect prevents loading any other object from the PlayerObjects table simply by key

Full creator rights, means that, if you created the object you can do anything to it. IE you can always modify your PlayerObject, as you would be the user who created it.

Likewise if you make a second table and toggle full creator rights, any object made by a user, can be modified without limitation by that user.