1 Reply Latest reply on Mar 9, 2010 11:49 PM by Michael Thornburgh

    Can I restrict logins through Stratus

    GoodNewsJim Level 1

              Hello, I wrote P2P applications in C/C++, and one nice thing you could do with your peer IP lookup server(What stratus does) is to not give up peer IP addresses unless the user logs on.


      So flow would be like this:


      1) Client connects to Server

      2) Server requests login

      3) If Client does not have credentials, he does not get the peer lists


      Is there some way to use Stratus that it would have a login/password sequence to do this?


      I have a work around where I make a "master peer", and the clients need to authenticate through it, or they would not be able to communicate on the network... But the problem with this is that it is easily hacked, and someone could enter the network with a "cloned master peer".  And then hacked versions of the game could communicate with the "cloned master peer" and then authenticate into the network.   Another hack to work around it would be to have an "authenticate hack" that saves the state of the game after authenticated.  I plan on charging a monthly fee for my video game, so if it gets hacked, I lose all my revenue.


      Instead of making a "master peer" that can be hacked in several ways, can I restrict them from getting a Stratus update unless they have login/password?


      I mean I could even have a server check before they get to the Stratus server with login/password authentication, but that could be hacked too.

        • 1. Re: Can I restrict logins through Stratus
          Michael Thornburgh Adobe Employee

          reminder: Stratus is a free beta service and is for experimental, development, non-commercial use only.


          Stratus does three things: 1) accepts connections (with a valid developer key) and records the IP address(es) and UDP port(s) associated with the connecting peerID; 2) answers lookup requests from anywhere/anyone by translating peerIDs to the recorded addresses/ports and by forwarding an introduction to the requested peerID for UDP hole punching; 3) automatically bootstraps RTMFP groups that have the "server channel" enabled.


          there is no way to use Stratus such that it would have the login/password credential flow you describe.  Stratus doesn't know anything about the semantics of any application that uses it nor of application-specific credentials or identities.  it just knows about peerIDs and network addresses.


          peerIDs are cryptographically pseudorandom, unguessable and unforgeable.  you must know the peerID to communicate with that peer.  it is up to your application logic to guard and/or disseminate the peerIDs as appropriate.


          you can leverage the unforgeable property of peerIDs to allow your centralized application server to arbitrate/authenticate bidirectional communications under your application's centralized control.  your central server would be asked by peerA for a counterpart.  the server would return to peerA, for example, peerB and a secret nonce to be used as the stream name for the NetStream.play().  when peerB sees the onPeerConnect() callback, it can say "ok", but will not be publishing a stream name that's the same as the secret nonce.  peerB then queries the central server for what to do about an incoming connection from peerA.  if it's allowed, the server will return the secret nonce and peerB can say NetStream.publish(secretNonce).  if it gets a "not allowed", peerB can just do NetStream.close() on the unconnectedPeerStream for peerA.  the decision over what's "allowed" or "not allowed" is up to your application logic, and presumably will involve some kind of logging-in.