Skip to main content
Participant
January 25, 2007
Question

How can I restrict one stream per user?

  • January 25, 2007
  • 4 replies
  • 791 views
Hello!
I have made a mp3-streamer in flash. Users must log on to a web page in order to access my player. If one user logs in once it's all OK. The problem occurs if a user "share" his account with multiple others and log in twice (or n-times). Now I have no control on how many users that can log onto the system.
I'm looking for a solution where for instance the first one who logs in gets to play the stream, and all others that log into the same account are refused access to streaming. I'm not a back-end programmer, so I hope this is something that can be solved using FMS. Is there a known working solution to this problem or some features on FMS that can lock streaming to the first user.
I've tried sending in the username, however if user#1 stops the stream user #2 is able to take over the stream, so now user # 1 is refused the stream.

Trond

    This topic has been closed for replies.

    4 replies

    January 31, 2007
    When it comes to challenges like this, I like to handle load balancing at the application level.

    What I do is build a "gatekeeper" FMS application that maintains a list of active application instances, and uses the FMS admin API to monitor the state of each application instance.

    When a client connects, they first connect to the gatekeeper (passing the target instance name asa variable in the connect() constructor), and the gatekeeper checks for a match in the list. If there's a match, it means the instance is already active, and the gatekeeper can act accordingly (by either rejecting the new connection, or killing the target instance). If there is no match, the gatekeeper adds the new instance to its list and returns a success response, and the client then connects to the target instance.

    Since you're load balancing, you can have the gatekeeper monitor available connections/bandwidth on each server. That way, the gatekepper can logically assign new sessions to the server with the least traffic.

    Read up on the Admin API... there's lots of great stuff you can do with it.
    Inspiring
    January 26, 2007
    well Jay Charles your last post is an intresting concept think I will work on something similar myself.
    January 26, 2007
    quote:

    Originally posted by: calmchess333
    well Jay Charles your last post is an intresting concept think I will work on something similar myself.


    It's an important one too, as it goes far beyond managing the activities of your authorized users. Lots of people make the assumption that if the protect the client app, they've protected the server app, and that's not the case. I really think that should be in great big bold letters on page one of the docs, or at very least addressed in the sample applications. FMS has zero built in security against application abuse and bandwidth leeching, and it's up to the programmer to protect their own apps. You'd be amazed how many people deploy apps with no main.asc, or main.asc files that do nothing but load components.

    Inspiring
    January 25, 2007
    you could also have your login written in php and have it check for multiple user sessions and if it finds one then it says name already in use and doesn't allow the user to login ......after a successful login then they are redirected to the flash page....this is how I do it and works very well.
    January 25, 2007
    quote:

    Originally posted by: calmchess333
    you could also have your login written in php and have it check for multiple user sessions and if it finds one then it says name already in use and doesn't allow the user to login ......after a successful login then they are redirected to the flash page....this is how I do it and works very well.


    You could, but I get the feeling that the OP's FMS app is not secured from abuse. If that's the case, it might be better to address things from the FMS side, so the user can be authenticated there. Even if the user session resides on the PHP server, I think it's a good idea to authenticate the user when connecting to FMS (to prevent people from circumventing the PHP application altogether and just connecting up to the FMS app)
    Participant
    January 26, 2007
    Hello again and thank you for your input.
    I am able to produce semi-advanced stuff on FMS, however, I think I'm struggling with the total concept here.
    Let me explain a bit more, I think I was a bit brief due to some frustration on my first post there.
    Optimally the application would do this.
    1) Player sends a ticket (SHA or something)
    2)FMS runs a remote call and verifies the ticket <-This is the problem
    3a) User already online? (Hmm forgot to turn off your player?) ..disconnect connection and give new connection to same user
    3b) Not online = just give a new connection to the user.

    This should guarantee that one user gets one stream, and if he forgets to turn it off somewhere he can "reconnect" from another place, and if he lends his login to someone he gets bitch-slapped whenever someone hijacks his stream. All good!

    It all fails at point2. I have no Idea how to connect to such a service. Only saw some vague rumors of FMS supporting Webservices way back. Don't know anything more of it. That might have fixed my problem if I had such a service to call and knew how to do it. :)
    Maybe I'm over-complicating things here? Thats why I need some help on how to do this. We've at least ruled out that FMS have built in functionality like this

    Trond
    January 25, 2007
    There isn't any built in functionality for this, you'll need to program it yourself in your server side actionscript.

    Assuming the flash client (the .swf) is provided with a unique identifier for the user (so it can be passed to the FMS app). you can do this fairly easily with an array or a shared object. The idea here is to have the FMS app maintain a list of connected clients, and check that list each time a client connects (to make sure the user isn't already logged in).

    Before I start typing a long-winded code example, are you already familiar with server side actionscript? We'll need to work with a shared object and the application class.