Hi,
I tried to use the advanced buddylist 2.0. It works perfectly when both users are online. But I want user A to be able to add user B as a buddy even while B is offline.
So I implement a offline messaging system. i.e., when A requests a addbuddy, it is stored in a db and send to B when B is online. Now the problem is, when B go online and add A as the buddy. I tried to
1. use the client side call SmartFoxClient.sendBuddyPermissionResponse
or
2. use the the server side call _server.addBuddy
Both failed and complained that A is offline and cannot add A.
So is it true that adding buddy can only happen when both A, B are online? If so, can we relax the rule a lot.
Many thanks!
addbuddy while both user are offline
-
mjforever111
- Posts: 6
- Joined: 01 Jan 2008, 15:46
Heya-
While i see the reasoning behind both users needing to be online to stop flood attacks, does this really stop them?
Im assuming when you goto add a buddy, it checks the list of people who are online to see if such a a person exists. If they do, great we add em, if not, we stop right there.
How does that really stop the server from being flooded though. I could still modify a client to barrage the server with addbuddy requests. This wouldn't be to bad with a limited amount of players on, but say you had a couple hundred or more people connected, this would still cause the server to check those couple hundred or more people to see if they match what we are looking for right? Which could put a great deal of undue stress on the server, especially if a couple people were to do it in unison.
Instead, why don't you put a brief time limit between adding buddies? When a buddy request is added, you check the last time one was attempted, not enough time we just stop right there.
I think this would better limit the stress on the server. In addition it would allow you to let people add offline buddies without worrying about malicious attacks as much.
Is this a possibility?
Questions, Comments, Hate Mail?
_-Menser-_
While i see the reasoning behind both users needing to be online to stop flood attacks, does this really stop them?
Im assuming when you goto add a buddy, it checks the list of people who are online to see if such a a person exists. If they do, great we add em, if not, we stop right there.
How does that really stop the server from being flooded though. I could still modify a client to barrage the server with addbuddy requests. This wouldn't be to bad with a limited amount of players on, but say you had a couple hundred or more people connected, this would still cause the server to check those couple hundred or more people to see if they match what we are looking for right? Which could put a great deal of undue stress on the server, especially if a couple people were to do it in unison.
Instead, why don't you put a brief time limit between adding buddies? When a buddy request is added, you check the last time one was attempted, not enough time we just stop right there.
I think this would better limit the stress on the server. In addition it would allow you to let people add offline buddies without worrying about malicious attacks as much.
Is this a possibility?
Questions, Comments, Hate Mail?
_-Menser-_
-
mjforever111
- Posts: 6
- Joined: 01 Jan 2008, 15:46
Menser: we're thinking about adding that feature on the server side only, so the developer can perform his own checks about which off-line user is valid etc...
About the security issue, the problem comes out with the mutualAddBuddy flag turned on. When A adds B, B will have A in his own list automatically.
I would personally prefer another system where the request for an offline add-buddy is stored in a database and the actual operation is done when target buddy comes online the first time after the request.
mjforever111:
The internal db does not contain the valid user names. Those are outside of the control of SmartFoxServer. Developers can implement their own custom login/registration system in any way and the Server knows nothing about it.
The best approach is extend the server-side addBuddy request to also support off-line users. From there the developer can add his own logic to verify the existence of such users or any other validation.
This also eliminates the problems of a modified client sending malicious addBuddy requests
About the security issue, the problem comes out with the mutualAddBuddy flag turned on. When A adds B, B will have A in his own list automatically.
I would personally prefer another system where the request for an offline add-buddy is stored in a database and the actual operation is done when target buddy comes online the first time after the request.
mjforever111:
The internal db does not contain the valid user names. Those are outside of the control of SmartFoxServer. Developers can implement their own custom login/registration system in any way and the Server knows nothing about it.
The best approach is extend the server-side addBuddy request to also support off-line users. From there the developer can add his own logic to verify the existence of such users or any other validation.
This also eliminates the problems of a modified client sending malicious addBuddy requests
-
mjforever111
- Posts: 6
- Joined: 01 Jan 2008, 15:46
Hi Lapo,
THaks for the quick response. As for your suggestion, yes I am trying to process "AddBuddy" event by myself. The problem is, that I guess the friend list is maintained internally in the h2 db. And the system call _server.addBuddy() need to be invoked to add to that..
When I tried to call it, it still rejects the request since the condition of both online is built in the addBuddy() call. Anyway to get around that?
THaks for the quick response. As for your suggestion, yes I am trying to process "AddBuddy" event by myself. The problem is, that I guess the friend list is maintained internally in the h2 db. And the system call _server.addBuddy() need to be invoked to add to that..
When I tried to call it, it still rejects the request since the condition of both online is built in the addBuddy() call. Anyway to get around that?
-
mjforever111
- Posts: 6
- Joined: 01 Jan 2008, 15:46