Skip to main content
A
Anonymous
August 30, 2011
Question

Best way to reject a 'publish' event?

  • August 30, 2011
  • 1 reply
  • 835 views

For our applications, end-users publish streams from a desktop flash player built into our web app.  The names for the streams they publish are given to the flash app by the web app and have various bits of information encoded into the stream name that our FMS server-side action script interprets.  For example:

    * A globally unique identifier for the stream

    * The identifier of the downstream server to which the FMS should reflect the stream

    * etc.

One of the things we'd like to do is add some authentication information to the stream name (for example, a timestamp for when the stream name becomes invalid and an md5 hash of the stream name and a server-side secret).  Ideally, I'd like to be able to then "authorize" these stream in the application onPublish() event handler and reject the publish if the stream name is determined to be invalid.  However, it seems like most of the authentication/authorization hooks are focused at connection and not at publish.  Is it possible to reject a publish?  For example, should I call application.disconnect() or something?

    This topic has been closed for replies.

    1 reply

    calmchessplayer
    calmchessplayer
    Inspiring
    August 30, 2011

    you can definately do this probably with a simple if statement  on the server side that says if true then record if false then do nothing. You are telling it to record from the server side aren't you? If you doing this from the client side then you could still use an if statement but could be more easily bypassed unless you are strongly encrypting the .swf even then encryption would only provide a deterrant. malicious users are always finding new ways around encryption algorithims.

    A
    Anonymous
    August 30, 2011

    No, this isn't about recording on the FMS.  Basically, we're concerned about a number of different scenarios:

       1. Someone using our FMS server to get free distribution of their own live FMS streams (while we foot the bill for the Amazon EC2 bandwidth).

       2. Denial of service attacks against our service from people publishing streams to us that trigger our application behavior (which includes a interval that runs for every stream, an RTMP stream that is pushed to a Wowza box where it is recorded and eventually uploaded to Amazon S3, and pushing to Akamai for widespread viewability).

       3. Streams published with the same name as a previous stream (and thereby replacing our archived content on S3 for the previous stream -- another sort of griefing/DoS attack).

    I'm confident that the security mechanisms we've put in place can validate a stream to make sure that it is "allowed" to publish.  If we just conditioned our application logic on that, it would take care of cases #2 and #3, but not #1 (e.g., we might not send the stream down to our Wowza box for recording and transmission to Akamai, but it would still be available on the FMS itself, I believe).

    I finally did find another reference that suggested that you can use application.disconnect() from within application.onPublish() to 'reject' a publish, which should provide sufficient protection for us.

    calmchessplayer
    calmchessplayer
    Inspiring
    August 31, 2011

    well use if statments for the part of the code that is controlling the methods whether that be pressing a button starting a stream connecting whatever.

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices