-
1. Re: allowedSWFdomains.txt and allowedHTMLdomains.txt files
CarphuntinGod Feb 9, 2010 8:57 PM (in response to CarphuntinGod)I'll jump in quick and say I misread, or didn't read the swf file closely enough. I
now see that it says it only applies if the swfs are called from a web page. So I quick ran my test again... using an html that calls the swf. Well, still wasn't stopped.
dang it.
-
2. Re: allowedSWFdomains.txt and allowedHTMLdomains.txt files
T-Hawk (DELT) Feb 10, 2010 6:45 AM (in response to CarphuntinGod)We modified the files in the same way and although we didn't test as you did, our reason for changing the file was different. Someone was bouncing live streams off our server, and altering this file now rejects all of those bounces. So it seems like it works for us, FMIS 3.5.3.
However, we had a side effect where it blocked our encoder from connecting to the box. So our vod stuff streams properly, our live stuff doesn't work at all any more.
-
3. Re: allowedSWFdomains.txt and allowedHTMLdomains.txt files
CarphuntinGod Feb 10, 2010 7:40 AM (in response to T-Hawk (DELT))Talking to someone else, on the live encoding side, I'm likely to restrict live encoders via ip, and then have our remote encoders vpn to our campus. If the server honors the IP restriction, we should be good to go, and unauthorized incoming streams should be killed
-
4. Re: allowedSWFdomains.txt and allowedHTMLdomains.txt files
Janaki Lakshmikanthan Feb 10, 2010 9:43 PM (in response to CarphuntinGod)You can restrict the clients based on the IP using C++ Authorization Plug-in. Pls refer the "plug-in dev" document that comes with the FMS installation.
Regards,
Janaki L
-
5. Re: allowedSWFdomains.txt and allowedHTMLdomains.txt files
SE_0208 Feb 10, 2010 10:19 PM (in response to T-Hawk (DELT))Hi One question here : when you tried .html from your computer, did you try it as standalone html or .html file which was hosted on some web server. Because if I am not wrong .html does not classify to be web page by default until unless its hosted on web server.
Can you try this and let us know about the result.
-
6. Re: allowedSWFdomains.txt and allowedHTMLdomains.txt files
T-Hawk (DELT) Feb 11, 2010 4:24 AM (in response to SE_0208)I didn't actually try this. That was the original poster.
I found that setting up allowed domains in these files did work as expected, however, it blocks our encoder from publishing live feeds. Which doesn't make sense because it is in the allowable domains. Either way, we have tried a few of the fixes as published on the forums to allow the FMLE to publish to the FMIS server without checking the allowable domains, however, that didn't work.
We installed the authorization adaptor as recommended by Janaki. We set up a username and password or our encoders and tested it. We were prompted for a username and password, but once we brought down the domain restrictions, the pirates just started bouncing stuff off the server again...getting around the password some how.
So, now we are looking at the Access plugin in order to detect live publishing attempts, and reject all not coming from our server. However, the API doesn't seem to show any functions for detecting what the user is actually trying to do (we don't want to block viewers). Anyone have any insight into that?
Thanks
-
7. Re: allowedSWFdomains.txt and allowedHTMLdomains.txt files
T-Hawk (DELT) Feb 12, 2010 8:13 AM (in response to T-Hawk (DELT))I think we found a suitable solution to our problem. We edited main.asc to add an if/then block to set write access to the server.
if(p_client.ip == '{our IP Address}'){ trace('We are all good: ' + p_client.writeAccess); } else{ p_client.writeAccess = ""; }So if they come from anywhere other then our IP, they can't publish. This doesn't reject the connection however, so they can still send stuff too our server...but it just doesn't go anywhere. If we could detect what they were trying to do before we accepted the connection, we would be able to reject the connect outright. Although, I haven't figured that out yet.
People should be able to modify that to block out ranges or domains as well. I made this change in the application.onConnect = function( p_client, p_autoSenseBW ) function call.
I will note however, that much hair was pulled until we realized that main.far overrode main.asc. Once we renamed main.far to main.farther, our main.asc code started working, and we were able to block. Just an fyi to save you time if you go this route. If you are doing more then simply streaming from your FMIS server (and most of you probably are) this is probably not a great solution.
-
8. Re: allowedSWFdomains.txt and allowedHTMLdomains.txt files
CarphuntinGod Feb 12, 2010 8:22 AM (in response to T-Hawk (DELT))we've been doing a lot more looking in to things.
First thing we've clarified is that the live and vod stuff we've been touching won't affect most of our live or static streams. Why? Because we're still set up old school. We've got vhosts/apps each with their own main.asc, etc.
So, next, we did something similar to attempt to stop publishes (we're looking at doing something like you did with ips where we need our live streams to work...but for the bulk of our stuff, we're probably going to add a command like this to the main.asc's (which appears to work against publish commands).
// stop illegal uploaders
application.onPublish = function(p_client, stream ) {
application.disconnect(p_client);
}
What still concerns me, though, is I never find a publish command for the stream being routed through us.
I'm trying to examine the connects to see how much outbound traffic there is.... but I can see that sometimes there's a connect for 20 minutes or more...which leads me to belive they're getting something.
-
9. Re: allowedSWFdomains.txt and allowedHTMLdomains.txt files
T-Hawk (DELT) Feb 12, 2010 9:33 AM (in response to CarphuntinGod)That was some helpful code. I've modified it to suit our needs like this:
// stop illegal uploaders application.onPublish = function(p_client, stream ) { trace('Someones trying to publish' + p_client.ip); if(p_client.ip == '{our IP Address}'){ } else{ trace('Disconnected Pirate'); application.disconnect(p_client); } }You should be able to do something there with referrers, domains or IP ranges to suit your needs. We are going to be rolling this out to our production servers tomorrow, so if this doesn't stop our pirates, I'll let you know.
-
10. Re: allowedSWFdomains.txt and allowedHTMLdomains.txt files
CarphuntinGod Feb 12, 2010 9:37 AM (in response to CarphuntinGod)Updating.... in reviewing the logs, and from rereading another response... I'm really thinking a lot of what we're seeing in our logs are false-positives. People connecting, and waiting for a live stream defined in some web page to come.... even though it's no longer being bounced through us.
My biggest concern with all of this still is, is there any way a stream can be sent to us, and back out to viewers without a publish comment appearing in the logs.
-
11. Re: allowedSWFdomains.txt and allowedHTMLdomains.txt files
T-Hawk (DELT) Feb 12, 2010 9:43 AM (in response to CarphuntinGod)My biggest concern with all of this still is, is there any way a stream can be sent to us, and back out to viewers without a publish comment appearing in the logs.
I'm hoping not. We will be watching the FMS logs, but also the access logs. We analyize our logs with awstats, so we can see if there are streams taking up any significant portion of our bandwidth. I suspect after this, they won't be able to publish or get any data from our streams.
Another step we took is renamed our live app....so currently no one knows where it is. That might delay their re-attempts for a while. But I suspect by monitoring the bandwidth and viewer logs, we will catch if they are still getting stuff through or not. And I'm hoping not.



