Problem with the ruby script for external authenitification

[Former Community Member]

Hello,



I encounter an issue with the ruby script provided with the
cocomo sdk.

I followed the RDoc documentation and I write a method
getAuthenticationToken to generate the authentitication token
needed to pass to Flex. Of course, I replaced the account
information and the shared secret.

quote:

---

require 'lib/rtc/cocomo'



def getSession()

am = Cocomo::AccountManager.new("
http://connectnow.acrobat.com/sdkaccount")

am.login(
accountowner,
accountpassword)

am.getSession(roomName)

end



def getAuthenticationToken(name)

session = getSession()

secret = "
account-shared-secret"

session.getAuthenticationToken(secret,"bob","x-bob",50)

end

---

The authentication works well, but the new user descriptor
created doesn't correspond to the username "bob" and the userID
"x-bob", instead I got new user descriptor with my own account
incremented.



It's just like everything I set in
"session.getAuthenticationToken(secret,"bob","x-bob",50)" wasn't
taken into consideration. I set autopromoteUser to false in the
DevConsole and tried again, but nothing changed.



In my Flex Code, I use the AS version to ConnectSession :

quote:

---

[Bindable]

private var auth:AdobeHSAuthenticator = new
AdobeHSAuthenticator();



[Bindable]

private var connectSession:ConnectSession = new
ConnectSession();



[Bindable]

private var collectionNode:CollectionNode = new
CollectionNode();



private function connectCocomo():void

{

//Authentification

auth.authenticationKey = customer.cocomoAuthKey;



//Création de la session

connectSession.roomURL = "
http://connectnow.acrobat.com/sdkaccount/room"

connectSession.authenticator = auth;

connectSession.login();



//Connection au collectionNode

collectionNode.sharedID = "navigationLien";

collectionNode.connectSession = connectSession;

collectionNode.subscribe();


collectionNode.addEventListener(CollectionNodeEvent.SYNCHRONIZATION_CHANGE,onSynchronizationChange);


collectionNode.addEventListener(CollectionNodeEvent.ITEM_RECEIVE,onItemReceive);



//On register les classes complexes

MessageItem.registerBodyClass(Lien);



} // ** fin fonction connectCocomo

---

Does anyone has a clue about fixing this issue ?



Thx



Bobby

[Former Community Member]

Sorry, I restarted my computer this morning without changing
anything and it works well now...

Maybe some cache issues...



So problem solved !

[Raff_]

One thing that I think is incorrect, and I should explain it
better in the documentation is that assuming you wanted to use your
getAuthenticationToken method to get a token for two different
users in the same session, your code would actually get two
different sessions (every time you call getSession() you'll get a
new one) the second invalidating the first.



I am still debating of how the API should work. The original
idea was that you call call Cocomo only once to get a session for a
room, then you get tokens for your users using the same session
(and I wanted to purposely limit the number of requests to Cocomo
and made the API so that if you call getSession multiple time you
invalidate the old session and get a new one)



This was assuming you could save the result of
AccountManager.getSession() somewhere in your application server
and that you were able to recall it every time a new user wanted to
connect to the room.



My idea was that you could cache the information in some
application-level cache but unless your cache is "persistent" (or
you store the session in your database) there is always the chance
that your cache gets invalidated and now your only option is to
call getSession again and start from scratch.



So, I am seriously thinking for next version to change
getSession so that always returns you the same session token for
the duration of a "meeting" (and there is an explicit API to
invalidate the session if you really need to - otherwise the
session gets invalidate when Cocomo thinks the meeting has ended.

[Former Community Member]

Thanks for your reply.



I was considering to store the session.secret attribute in a
database to avoid querying Cocomo each time.



However I was wondering how would I know when the session I
store would be invalidated by Cocomo.



I'm concerned about this point because I'm working on a
project using the multiple group fonctionnality of cocomo, and I
was thinking of using the same session.secret for all those users.
Those users may log in at different time, and may let the room
empty for a while.



What is your policy about the session key validity ?

[Raff_]

The session becomes invalid once the room "closes".



The room closes after no users are in the room for a
specified amount of time (that I never remember, I think it's 5
minutes :)



If you can control when user exit your room (i.e. if they
report back to your server that they are exiting) you can keep
track of when the session may become invalid (and if you think the
session has been invalidated because you think a user enters the
room after a certain amount of time the room has been empty) you
can call getSession() again and get a valid session.

[Former Community Member]

As I understand it, the only way to monitor people leaving
the room is to use cocomo with Flex App instance in a navigator.



If every users leave the room in closing their navigator, I
would never receive a notification from cocomo telling me no one is
in a room anymore.



I don't see how I could manage in rubyOnRails to monitor a
users leaving a room when they close their navigator.



Do you have any clue ?

[Raff_]

you are right that trying to figure out when a user closes a
browser windows instead of using the "logout" button of an
application is next to impossible :(



So here are a few options:



- with the current implementation one way to know if a
session secret is valid is to let the client find out. I mean, you
generate a user authentication token using the stored session
secret, you pass it to the client, the client tries to connect to a
room and if the authentication fails it calls you back and you get
a new session secret and use it to generate a new authentication
token.

(or, with the current implementation, you get a session
secret and just use it forever, since I kind of forgot to
invalidate the session when a meeting ends :)

- with the next iteration of the server side software I have
"fixed" the session invalidation, but I also changed the behavior
of AccountManager.getSession so that it will return the same
session secret for the same meeting session. With that version you
could potentially retrieve the session secret for every user
request (sigh ):

- with the following iteration of the server side software I
am thinking of implementing a "time to live" for the session secret
that will guarantee you that the object will be valid for the
duration of the TTL. After that you should call getSession again
that will return either the same secret with an updated TTL (if the
meeting was still running) or a new secret for a new meeting
session