[Red5] Re : Quick Question: Client vs Connection

Wed Feb 4 00:46:46 PST 2009

Hello,

I'm facing the same issue as the one explained: I would like to have a single connection or a single IClientID for one client, in order to have only 1 login page and many applications behind with a connection at the beginning of each one. 
I tried with cookies as you explained before, in a php page:
(using easyPHP and Apache) Login.php => I created my cookie. If it works, I redirect to the http://Red5Server-IP:5080/MyApp.php.
In MyApp.php, I have a php test: if (isset(COOKIE...))... => If I am connected, I'm supposed to go open the application, otherwise, I'm supposed to go to the login page...

Unfortunately, it seems that if I redirect to Red5Server-IP:5080, then PHP in not taken into account.

Could you explain me, please, how I could use some token or the COOKIES for my application?

Thanks,

Etienne.

________________________________
De : Tyler Kocheran <rfkrocktk at gmail.com>
À : red5 at osflash.org
Envoyé le : Mardi, 3 Février 2009, 1h19mn 30s
Objet : Re: [Red5] Quick Question: Client vs Connection

True. I'm just spitballing with this thread, because of my original assumptions anyway :)
But I can stomach the current API :P

On Mon, Feb 2, 2009 at 4:01 PM, Andy Shaules <bowljoman at hotmail.com> wrote:

heh, I didnt ever use the appJoin override, but I still think that handling like that floats up into the 'tyler' as in your own portion of the applications api and whether you allow multi connections from whatever source with a particular authentication token/session.

Until flash player handles netconnections in the same session manner, its not a good idead imho.

What I think would be workable is some attribut that is accesable in red5 which will determine the client source and client flash-instance. In which case, we would have the arch you describe. 'this' playerInstance with array attribute of netconnections.

Honestly, I have no idea what the intentions of the 'connection' and 'client' on red5. It may well be that is the intention... that each instance of the IClient will equate to the player from which all I connection's arise.

To me really, the IConnection is the interface to the channel, and the IClient is my first level of access to the connected entities aboard the S.S. Andy  

----- Original Message ----- 
From: Tyler Kocheran 
To: red5 at osflash.org 
Sent: Monday, February 02, 2009 3:27 PM
Subject: Re: [Red5] Quick Question: Client vs Connection

Connections would still be treated as separate, that's not the issue. appConnect and roomConnect would still be dispatched on every new NetConnection.connect, but appJoin would only be triggered once. This way, you could tell if a truly unique Flash Player instance is connecting to your application, not just a netconnection. 

On Mon, Feb 2, 2009 at 3:17 PM, Walter Tak <walter at waltertak.com> wrote:

Well what if you have some app that wants to make multiple connections at once, for some reason ? 

Currently you can drop any new connections (on the serverside) if you think they're duplicates.

I often test my apps by starting multiple swf's in my browser. Wouldn't be a good idea if Red5 would see them all as one client and not triggering events like appJoin.

Unless I'm missing the point.
Oh, for sure! I know I could create a SharedObject to work around that, but I'm more talking about an automatic serverside scenario. I just think that the notion of an IClient should be representing one running instance of Flash Player connected to Red5 via one or more IConnection (NetConnection) implementations. Currently, whenever a connection is made to Red5, the appJoin(IClient client, IScope scope) method is fired, which is kind of weird, since if the client has already connected to the server, it gets called as many times as a conection is opened. 

What would be more effective in my mind would be to fire appJoin and roomJoin only once: upon a unique client connecting to the app/scope and not when any subsequent connection is made to the server. Does that make sense? 

I assumed that this was already so, but I did a little digging and I found out that appJoin is called upon every connection attempt to the server. 

On Mon, Feb 2, 2009 at 12:11 PM, Walter Tak <walter at waltertak.com> wrote:

You can generate a unique ID , store it in a (Flash) local shared object and read that object (from the disk of the user) each time your 'application' starts.
Cookies in browsers work as well, but are prone to deletion by ad/malware-scanners , can be blocked by paranoid users that don't allow all cookies or can be defeated if the user starts the application with as well Internet Explorer and Firefox simultaneous.

Yes, users can empty those 'local shared objects' (Flash) but only in theory. In the real world you can track users until the end of days or until they install a new version of the Flash player. For the average identification of a single client it's enough.

Anyway you should/could/might want to provide the user a token once they logged in on a backend server, pass that token to Flash, let Flash pass the token to the server (Red5) ; have Red5 validate the token against the backend and the user access or not. Once a token has been used it should be flagged so the user has to revalidate (get a new one) on the backend. If the user still has a proper session (like a php-session) then you could re-validate him automatically, give out a new token and let him reconnect with his client application (Flash/Flex) to your shiny Red5-server.

You can make this as complicated as you like.
 Walter

Doesn't Flash Player provide a unique id for the computer on which it's installed? I thought I heard something about that a while back...

On Mon, Feb 2, 2009 at 9:27 AM, Michael Eckhoff <mreckhof at gmail.com> wrote:

... Proxy, NAT, terminal server, browser instance.  I wouldn't be for trying to track anything by ip. 

Michael
_______________________________________________
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

________________________________
No virus found in this incoming message.
Checked by AVG. 
Version: 7.5.552 / Virus Database: 270.10.16/1930 - Release Date: 02-02-09 07:51

_______________________________________________
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 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.

      __________________________________________________________________________________________________
Ne pleurez pas si votre Webmail ferme ! Récupérez votre historique sur Yahoo! Mail ! http://fr.docs.yahoo.com/mail/transfert_mails.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://osflash.org/pipermail/red5_osflash.org/attachments/20090204/f79f6429/attachment-0001.html>