Skip to main content
A
amn
Known Participant
May 13, 2010
Question

How to deny RTMP clients any access to server shared objects, without borking live streaming?

  • May 13, 2010
  • 2 replies
  • 4308 views

It's kind of strange, and the documentation is very vague.

I have a server side shared object I wish to protect from any peeking by RTMP clients, much less altering, and I have done the following in my Application.onConnect function:

client.writeAccess = "";

client.readAccess = "";

I am sure this denies clients access to the shared objects.

The problem is, it makes live streaming impossible - server writes:

"Write access denied for stream *****.
Read access denied for stream *****."

... and clients attempting to play any live publishing stream get a NetStream.Play.Failed while publishing a live stream raises an event with NetStream.Record.NoAccess, even though I am not recording anything at all.

My question is fairly obvious and simple: how to deny clients any read access to some/all shared objects yet keep live streaming working?

Is it possible at all?

Thanks.

    This topic has been closed for replies.

    2 replies

    A
    Anonymous
    May 13, 2010

    Hi,

    You can give read and write access to you streams directory, in this way, client can access the streams but not the shared object

    client.readAccess = "streams/<instance1>;streams/<instance2>";

    client.writeAccess="streams/<instance1>;streams/<instance2>";

    In this way now your clients will be able to read and write to streams, but as Shared objects will be in another directory they will not access shared objects.

    Thanks,

    Abhishek

    A
    Anonymous
    May 13, 2010

    @Abhishek, that's not entirely correct.

    If we assign the following:

    client.writeAccess="streams/someinstance";

    the client can still write to a sharedobject as long as the name of the so includes the streams/someinstance path, for example:

    streams/someinstance/somesharedobject

    A
    amnAuthor
    Known Participant
    May 13, 2010

    Well, this is something else - here you have a client that creates (and thus owns) a shared object. It doesn't matter much to the server, apart from space being used. It's hardly a security concern. As long as a client does not have access to the more sensitive server owned shared object(s), it's all good.

    Besides, one can simply deny write access to the directory where one is supposed to "store" live streams, since these are not stored anyway. In fact, the "writeAccess" looks like a misnomer when applied to live streams - it affects these, yet they are not saved anywhere, and should thus be made to work independent of "writeAccess" flag. If anything, there should be a new property called something like "allowPublishing", which could take precedence and apply to any publishing stream.

    A
    Anonymous
    May 13, 2010

    Hmm... good one. If you're primarily concerned about prevent write access to shared objects the server is managing, you could use a path for the live streams, and then allow write access only on that path. For example, if you publish your live stream to:

    live/mylivestream

    ...you could do...

    client.writeAccess("live");

    Of course, that wouldn't prevent a client from creating a shared object inside of "live" and writing to it.

    If you want to prevent SO writes entirely while still allowing stream publishing, I suspect you'll need to use a C++ plugin (or pehaps someone smarter than me has a better solution that I'm not thinking of)

    A
    amnAuthor
    Known Participant
    May 13, 2010

    Actually you are right on about prepending live streams with something like "live/" - that would accomplish exactly what I need, since the access control system is obviously not as sophisticated to even distinguish between shared objects and streams. Another weird thing is that our streams are live so there is nothing actually recorded anywhere, but oh well...

    Thanks.

    By the way, what is the longest possible length of a stream name?

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