I usally do this: - client connect to the server and verify server is alive - in client show login form - on login click send parameter to a server side function ( there you have to validate the login with the policy you prefer, get data from source you prefer ) - can't log return a message to the client simply with return statesman ( may be you can define a value object to declare a result class and use Remote alias to cast it with amf ) - if can login return the message update the list of connected clients and send it to every client in the same scope. Pay attenction because the list you store in the scope attribute is visible only for that scope ( obviously ) then send the list to every clients so they can update their state.
If you keep you policy logic in the server tier maybe it's more difficult to break ; Hope helpful Matteo Lanzi > -----Messaggio originale----- > Da: [email protected] [mailto:[email protected]] Per conto > di tom > Inviato: lunedì 9 febbraio 2009 20.30 > A: [email protected] > Oggetto: [osflash] red5 client login strategy > > hi, im running (locally) a vide/chat flex3 app. to finalize the > structure i would like to know what the best strategy is in terms of > user:login > the way it works right now for me: > > 1) user netconnection.connect with userdata / params > 2) appConnect performs a primary check with params > 3) appConnect set ClientID via Service invoke Client method > 4) roomConnect performs a 2nd user-data-check (against the mysql-db) > 5) user enters roomJoin > > > >> my question is now: WHEN and where is the best place to send back the user > list / update a SO? > > any ideas? > > thx tom > > > -- > sip:[email protected] > > _______________________________________________ > osflash mailing list > [email protected] > http://osflash.org/mailman/listinfo/osflash_osflash.org _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
