forums.smartfoxserver.com

I want to transmit specific client settings to the server. These are settings bound to the specific user and nothing other clients must be or should be made aware of.
As far as I have understood using user variables and updating them will dispatch an event and broadcast the variable to all users in the same room.
Well this is not what I need.

The only way I have figured out is to use a extension call and set the user variable via api serverside and set fireclientevent to false?

Or is there another way? As the variable must be present on server and client it seems that either set it to hidden or use user property would not work in this case.

Hello.

Well, that's an interesting case

In my opinion, the best option would be to save those settings as user properties and send them, when needed, from an extension response.

This is similiar to what I have thought. Thanks.

I had the same issue.
I thought about this solution but I didn't like it because it created custom code and wasn't as "nice".

What I did is that the client send a random key to the server thru a custom call upon login, then, the server will encrypt the value of the variable that should be visible to only the user with that user key (that both the server and the client know). All users receive the variable but only one of them is capable of decrypting it.

Works great for me.

ps: in addition, when the variable should be made "clear" to both, i just stop encrypting it .
ps2: fwi, i went with blowfish encryption. It's quite strong

Thats a very interesting solution. But of course it creates lots of unnecessary network traffic.

I take it as it would be great to have one additional option vor uservars: Send to user only. With or without event.

Maybe the makers of SFS will consider this.

The purpose of UserVariables is to share user data with all the clients in the same Room. In your case why don't you use a simple Extension request/response?

Bax wrote:The purpose of UserVariables is to share user data with all the clients in the same Room. In your case why don't you use a simple Extension request/response?

I cannot answer for the others, but in my case: i use an observer pattern for the extension/models relationship. It's quite elegant. Adding specific extensions requests to manage specifics models is quite easy, i just prefered the another way.
If you could add another properties to the uservar like owner only or not, that could be nice (and for my particular use case, i'd like to be able to change that setting dynamically as well).

Bax wrote:The purpose of UserVariables is to share user data with all the clients in the same Room. In your case why don't you use a simple Extension request/response?

I would have thought that this is the purpose of RoomVariables you are describing.
So, what is the difference in purpose between UserVariables and RoomVariables that I didn't get?

+1 for for Fraggles idea of encrypting, and in my opinion this would be a valid implementation for the purpose hiding UserVariables to other users, if it is easily pluggable.

And with an Open-Source-Community around SmartFox-Server, maybe this would already be implemented.

Of course it would be even greater, if one could decide that this UserVariable is only shared between Server and the "Owning" User.

The Room Variables contain Room-related data (for example the topic in a chat room, the game type in a game room, etc). The User Variables contain User-related data (for example the user nickname, his score in the current match, his coordinates on a map, etc). They are very different in their purpose.
Also, if you just need to send a client some data that no other client must receive, simply use an extension response.

Yeah bax sure. Nobody said it cannot be done.
But it is something like a missing link, look, you have:

- Custom property on clientside for data that never gets transmitted to the server
- Custom property on serverside, that never gets transmitted to the client
- User variable which updates itself and is visible for every user in the same room
- User variable which is updating itself and is available on server only if it is hidden

So the missing piece for a complete set of possible action is a user property, that synchs automatically between client and server but only for the specific user. That would be great for monitoring client settings and invoke action on the server and vice versa.

Hi again,

I found myself in a situation that would be really simplified if we had thoses "private" user variables.

Do you think it would be possible to add this feature to SFS in a reasonable timeframe ?

Thanks,

Seb

A few comments:

1) as regards the variables encryption idea, it doesn't make sense as a generic all-purpose built-in functionality in the Server.

2) @3slices

- Custom property on clientside for data that never gets transmitted to the server

Well... these are just local variables

- Custom property on serverside, that never gets transmitted to the client

Yes, by default. But you can send them to the client via server side code. This is the point from which your specific needs can take form, via the server side code, as Bax explained.

- User variable which is updating itself and is available on server only if it is hidden

Not exactly. Hidden variables allow you to simply use the same tool (UserVariables) on the server side without having to use other systems like in SFS1.x where you had UserVariables (client/server) and User Properties (server only)

So in the case of private User variables all you have to do is sending them from your Extension code (which adds also the ability to add custom validation, storage etc...) using the API helper functions.
User variables can be easily converted to an SFSArray via the toSFSArray) method, sent to the client and easily rebuilt via the fromSFSArray() method in the client API

hope it helps

Lapo wrote:A few comments:

1) as regards the variables encryption idea, it doesn't make sense as a generic all-purpose built-in functionality in the Server.

2) @3slices

- Custom property on clientside for data that never gets transmitted to the server

Well... these are just local variables

- Custom property on serverside, that never gets transmitted to the client

Yes, by default. But you can send them to the client via server side code. This is the point from which your specific needs can take form, via the server side code, as Bax explained.

- User variable which is updating itself and is available on server only if it is hidden

Not exactly. Hidden variables allow you to simply use the same tool (UserVariables) on the server side without having to use other systems like in SFS1.x where you had UserVariables (client/server) and User Properties (server only)

So in the case of private User variables all you have to do is sending them from your Extension code (which adds also the ability to add custom validation, storage etc...) using the API helper functions.
User variables can be easily converted to an SFSArray via the toSFSArray) method, sent to the client and easily rebuilt via the fromSFSArray() method in the client API

hope it helps

The encryption system is too specific, I agree.

However, I think you didn't quite understood what we mean with the feature request.
Of course we know we can "do it" in other ways, however, we have to maintain the sync between server and client models's properties ourselves, something that UserVariable do for us automatically. Plus we would get the added benefits to get the variable sent only if they change, and we could change the "private" property of the variable and switch it's public / private status easily.

Again, we can do it ourselves, but adding it to the system features would be a nice bonus.

What do you think?

Private user variables would be awesome.
I would consider them as perfect for control client settings as it would be the easiest way to have a variable on sync client and serverside for a particular user.

Thanks for the feedback. I think it makes sense.
For security reasons I think UserVars marked as private should be initiated on the server side. This is in order to avoid bad clients to flood the server with private vars.
Added to the todo list