I have a FMS 3 in on a linux server and I have a ViewCast Niagara Pro II encoder. I can publish to the FMS 3 no problem but how to I limit who can publish to the server, because currently I can use the free Adobe Media Encoder to connect to the server and publish with no authorization which tells me anybody could do the same if they just input the rtmp url and feed name.
thanks
This topic has been closed for replies.
Correct answer
I have read all the post.. even your posts on this subject in the past
I am trying to think of things I can do and I have hit the wall on this one
for sure... I have looked at contacting Adobe but we all know where that will get me honestly I assume the port I publish to is the same port I broadcast on correct.. if the stream published to for example port 1930 and broacast on port 1935 I could block all traffic on 1930 to one ip .. but that is not how it works right!
You have it right... there's just no effective means of preventing unauthorized publishers on streaming server. The port used to connect has has nothing to do with it (any connection over any port has equal rights, so securing a local IP would be fruitless). In your scenario, even if you secure port 1930 on one of the IP's, users could still connect on port 1935 on the other IP. In the end, if you can connect, you can publish.
I feel fairly confident in saying that your options are to upgrade to interactive server, wait for the FMS team to patch the problem, or choose another server technology (although when it comes to no-scripting-required servers for live streaming, I don't know of any truly viable alternatives).
you honestly believe that statement .. it is not something that is broken here.. it is a feature not offered in the product period if you want it you have to pay for it. Nothing to fix here as it is not in the product to fix. If I want to secure my publish the only option is to pay 3 times the money for the 1 option I know everyone would like to see in FMS 3. The only fix for this issue is DOLLARS
A
Anonymous
January 18, 2010
In my experience with the FMS team (over the 7+ years I've been working with FMS/FCS), the FMS engineers typically don't say anything about feature updates unless they are already in the works, or if the statement is qualified by an additional statement indicating the feature is in a beta or prototype and is not guaranteed for release (not sure if that's a rule at Adobe, or just good politics on the part of the engineers).
The fact that Asa openly stated that the team is aware and working on it suggests to me that they are planning for a solution to the problem in a not-too-distant update. Do I know that for a fact? Of course not.... but I have no reason to doubt that there will be a solution before too long. So yeah... I genuinely do believe my previous statement.
Something to consider... FMIS and FMSS use the same binaries. My understanding is that the limitations imposed by the streaming server license are merely rules, so it shouldn't be a huge undertaking to change those rules. It might even be as simple as making changes to the signed live and vod apps that ship with FMS. So, the required functionality is supported by streaming server, it's just not implemented (big difference there in terms of what it would take to fix the problem)
So, for the short term, the only solution is to pony up the cash for an interactive license, but based on Asa's statement, that will change.
I am going to be honest.. ADOBE SUCKS.. why make a product like this and no REAL builtin way of controlling who can publish streams to the FMS and I dont have interactive I have good good FMS ver. 3.1. I can not write scripts with onPubish etc.. I am not a programmer.. ADOBE IF YOU ARE READING THIS you left me high and dry on this for sure and others as I read online... ANYBODY with a monkey brain can highjack my stream if they want WOW!!!
A
Anonymous
January 18, 2010
FWIW, one of the FMS engineers commented in another thread that the FMS team is aware of the problem, and they are working on implementing a solution.
I'm sure the readers of the forum feel your pain, but there's nothing anyone here can do about it (there are a few Adobe insiders that contribute here, but for the most part this is a user end forum). I think you'd be better served by contacting Adobe directly and explaining that the undocumented lack of security has rendered the product useless to you. Perhaps you can get a refund so you can move forward with a different streaming platform (although when it comes to live streams, I can't think of any no-programming-required alternatives)
I have read all the post.. even your posts on this subject in the past
I am trying to think of things I can do and I have hit the wall on this one
for sure... I have looked at contacting Adobe but we all know where that will get me honestly I assume the port I publish to is the same port I broadcast on correct.. if the stream published to for example port 1930 and broacast on port 1935 I could block all traffic on 1930 to one ip .. but that is not how it works right!
That's one good one. Another is using the FMLE authentication plugin. I'm away from the office so I don't have the link, but google that and you should be able to do some auth there. Either that or if you're not doing FMLE pulishing, you can work up an authentication scheme of your own.
We use a Niagra Pro II to encode the video and only offer auth to Providers services and not a FMS auth system... I would love some way of locking the publishing to a set of ips... anybody got any details on how.