[Red5] How to ban a single user, using only red5-serverside-logic ?
Tyler Kocheran
rfkrocktk at gmail.com
Wed Apr 8 11:14:21 PDT 2009
Really? That's freaking rad. Will it be integrated with some sort of
database/persistence layer, or is it just a log that Mina writes to disk?
Oh, and are there any plans for upgrading Red5 to use Spring 3? (Probably
not in the future :P but does it break backwards compatibility?)
On Wed, Apr 8, 2009 at 11:09 AM, Mondain <mondain at gmail.com> wrote:
> Just an fyi, Mina 2 has a really cool IP blacklisting feature.. I'm sure
> some will find it quite handy.
> Paul
>
>
> On Wed, Apr 8, 2009 at 10:48 AM, Tyler Kocheran <rfkrocktk at gmail.com>wrote:
>
>> We're just messin' around, no worries, my friend :)
>>
>>
>> On Wed, Apr 8, 2009 at 10:37 AM, Marc Jost <marc.jost at belponline.ch>wrote:
>>
>>> Never ment to be a smart ass on this one O_o Just wanted to say how I
>>> did it.
>>>
>>> Dominick Accattato schrieb:
>>>
>>> or... lmao
>>>
>>> On Wed, Apr 8, 2009 at 1:12 PM, Tyler Kocheran <rfkrocktk at gmail.com>wrote:
>>>
>>>> Or you could set up a persistence layer, store the client ids as well as
>>>> their IP addresses, use some AOP to intercept some calls with Spring
>>>> injecting necessary beans and properties and such, and keep a persistent log
>>>> of who has ever been online...
>>>>
>>>> :)
>>>>
>>>> On Wed, Apr 8, 2009 at 10:03 AM, Marc Jost <marc.jost at belponline.ch><marc.jost at belponline.ch>wrote:
>>>>
>>>>> or you could just store the username as attribute on the connection
>>>>>
>>>>> Dominick Accattato schrieb:
>>>>>
>>>>> you should use the clientId as the key which you should be able to
>>>>> get from the IConnection.
>>>>>
>>>>> On Wed, Apr 8, 2009 at 12:04 PM, Mathias Menrath <
>>>>> MenrathMathias at t-online.de> wrote:
>>>>>
>>>>>> Yeah, Dominick and Tyler, i'll have to say thanks for your hint with
>>>>>> the HashMap to store the logged-in users and their connections (type
>>>>>> IConnection).
>>>>>> This is working indeed. I created a ConcurrentHashMap on the
>>>>>> server-side, and stored all the usernames with the corresponding
>>>>>> connection-objects.
>>>>>> Then i my serverside-method, that gets called by the admin when he
>>>>>> is selecting a user in the list and pressing the "BAN USER"-Button, i just
>>>>>> used
>>>>>> this little amount of java-code, to invoke the clientside-Method
>>>>>> "youGotBanned" on the appropriate user, which throws an Alert-Message and
>>>>>> executes
>>>>>> the logout()-Method.
>>>>>> However, since i had to use the entrys "username"(string) as Key and
>>>>>> "conn"(Iconnection) as Value (username is always unique, otherwise users
>>>>>> cannot log in!) to get the user-specific-Connection (as shown below),
>>>>>> i had the problem of removing the right pair of entrys from the hashMap when
>>>>>> the user logs out, because the given red5-serverside method
>>>>>> "DISCONNECT" only accepts IConnection and IScope as parameters.
>>>>>> So i had to find a way how to get the Key of my HashMap (which is the
>>>>>> username) when i only know the Value (which is the Connection).
>>>>>> The solution i found for this problem seems to be quite simple: I just
>>>>>> need to loop over an Iterator-object, that contains all the key-entrys of my
>>>>>> HashMap, and during the loop-process, i look for the corresponding
>>>>>> connection-object of the current key-entry, and then compare this connection
>>>>>> with the one that i get as a parameter from "DISCONNECT", and finally
>>>>>> remove the right entry from my HashMap.
>>>>>> I pasted the two serverside-methods below. Take a look if you're
>>>>>> interested.
>>>>>> Thanks again.
>>>>>>
>>>>>> Mathias
>>>>>>
>>>>>>
>>>>>> private
>>>>>> ConcurrentHashMap<String,IConnection> usernameConnectionMap;
>>>>>> ...
>>>>>>
>>>>>> ...
>>>>>> public
>>>>>> String getUserToBan(String selectedUsername) {
>>>>>> IConnection userConn =
>>>>>> usernameConnectionMap.get(selectedUsername);
>>>>>> ServiceUtils.*invokeOnConnection*(userConn,
>>>>>> "youGotBanned", * new* Object[] { username });
>>>>>> * log*.debug(selectedUsername+" has been banned!");
>>>>>> String resultMessage =
>>>>>> "You have successfully banned the selected user!"; * return*resultMessage;
>>>>>> }
>>>>>> ...
>>>>>>
>>>>>> @Override
>>>>>> *public* *void* disconnect(IConnection conn, IScope scope) {
>>>>>> // Get the previously stored username. String uid =
>>>>>> conn.getClient().getId();
>>>>>> // Unregister user. clientMgr
>>>>>> .removeClient(scope, uid);
>>>>>> Iterator<String> it = (
>>>>>> usernameConnectionMap.keySet()).iterator(); * while*(it.hasNext())
>>>>>> {
>>>>>> String key = it.next().toString();
>>>>>> IConnection value =
>>>>>> usernameConnectionMap.get(key); * if*(value.equals(conn))
>>>>>> {
>>>>>> usernameConnectionMap.remove(key); * log*
>>>>>> .debug("User "+key+" has been removed successfully from serverside
>>>>>> hash map"); }
>>>>>> }
>>>>>>
>>>>>> if
>>>>>> (!it.hasNext()) {
>>>>>> clientMgr = *null*; usernameConnectionMap = *null*; *
>>>>>> log*.debug("objects 'ClientManager' and 'ConcurrentHashMap'
>>>>>> deleted!"); }
>>>>>>
>>>>>> // Call original method of parent class. * super*.disconnect(conn,
>>>>>> scope); }
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>> *From:* Dominick Accattato <daccattato at gmail.com>
>>>>>> *To:* red5 at osflash.org
>>>>>> *Sent:* Tuesday, April 07, 2009 2:59 AM
>>>>>> *Subject:* Re: [Red5] How to ban a single user,using only
>>>>>> red5-serverside-logic ?
>>>>>>
>>>>>> Tyler is 100% correct. In fact the concurrent package was added in
>>>>>> Tiger Java 1.5 and should be used in place of the non-concurrent
>>>>>> equivalents. Thanks for pointing that out Tyler. In fact we use the
>>>>>> concurrent package here at IR5 as well ;).
>>>>>>
>>>>>> Dominick Accattato
>>>>>> CTO & Senior Engineer
>>>>>> www.infrared5.com
>>>>>> 315.717.2818
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 6, 2009 at 5:32 PM, Tyler Kocheran <rfkrocktk at gmail.com>wrote:
>>>>>>
>>>>>>> If you are directly using a MultiThreadedApplicationAdapter, you may
>>>>>>> or may not want to use a java.util.ConcurrentHashMap to avoid any
>>>>>>> thread-sync errors :) Either way, both HashMap and ConcurrentHashMap both
>>>>>>> implement Map, so implementation shouldn't really matter. If you're having
>>>>>>> weird issues with using a regular HashMap, use a ConcurrentHashMap. Just
>>>>>>> tips, of course :}
>>>>>>>
>>>>>>> On Mon, Apr 6, 2009 at 1:07 PM, Dominick Accattato <
>>>>>>> daccattato at gmail.com> wrote:
>>>>>>>
>>>>>>>> Anyways, you should store your clientId's along with their
>>>>>>>> connections in a HashMap so that you can later grab the offending
>>>>>>>> individual.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> And do this, knowing the time, that now it is high time to awake out
>>>>>>> of sleep;
>>>>>>> for now our salvation is nearer than when we first believed.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Red5 mailing list
>>>>>>> Red5 at osflash.org
>>>>>>> http://osflash.org/mailman/listinfo/red5_osflash.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Dominick Accattato, CTO
>>>>>> Infrared5 Inc.
>>>>>> www.infrared5.com
>>>>>>
>>>>>> ------------------------------
>>>>>> _______________________________________________
>>>>>> Red5 mailing list
>>>>>> Red5 at osflash.org
>>>>>> http://osflash.org/mailman/listinfo/red5_osflash.org
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Red5 mailing list
>>>>>> Red5 at osflash.org
>>>>>> http://osflash.org/mailman/listinfo/red5_osflash.org
>>>>>>
>>>>>>
>>>>> ------------------------------
>>>>> _______________________________________________
>>>>> Red5 mailing listRed5 at osflash.orghttp://osflash.org/mailman/listinfo/red5_osflash.org
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Red5 mailing list
>>>>> Red5 at osflash.org
>>>>> http://osflash.org/mailman/listinfo/red5_osflash.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> And do this, knowing the time, that now it is high time to awake out of
>>>> sleep;
>>>> for now our salvation is nearer than when we first believed.
>>>>
>>>> _______________________________________________
>>>> Red5 mailing list
>>>> Red5 at osflash.org
>>>> http://osflash.org/mailman/listinfo/red5_osflash.org
>>>>
>>>>
>>> ------------------------------
>>> _______________________________________________
>>> Red5 mailing listRed5 at osflash.orghttp://osflash.org/mailman/listinfo/red5_osflash.org
>>>
>>>
>>> _______________________________________________
>>> Red5 mailing list
>>> Red5 at osflash.org
>>> http://osflash.org/mailman/listinfo/red5_osflash.org
>>>
>>>
>>
>>
>> --
>> And do this, knowing the time, that now it is high time to awake out of
>> sleep;
>> for now our salvation is nearer than when we first believed.
>>
>> _______________________________________________
>> Red5 mailing list
>> Red5 at osflash.org
>> http://osflash.org/mailman/listinfo/red5_osflash.org
>>
>>
>
>
> --
> http://gregoire.org/
> http://osflash.org/red5
>
> _______________________________________________
> Red5 mailing list
> Red5 at osflash.org
> http://osflash.org/mailman/listinfo/red5_osflash.org
>
>
--
And do this, knowing the time, that now it is high time to awake out of
sleep;
for now our salvation is nearer than when we first believed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://osflash.org/pipermail/red5_osflash.org/attachments/20090408/f572141d/attachment-0001.html>
More information about the Red5
mailing list