^.+(youtube.com|facebook.com).*$
Domain block (not URL block) works because the domain is visible (unencrypted) during the TLS session setup between the browser and the server.Strangely enough, URL Block also works for HTTPS pages.
This works here, for example:Code: Select all^.+(youtube.com|facebook.com).*$
I doubt they were able to block files download over an HTTPS connection. Only whole domains and/or IPs.Yes, I am aware of that, but how do the others do it, at train stations, airports ... ? a few weeks ago I set up a WLAN connection at the airport and I couldn't download any files. So there has to be a solution.
I doubt they were able to block files download over an HTTPS connection. Only whole domains and/or IPs.Yes, I am aware of that, but how do the others do it, at train stations, airports ... ? a few weeks ago I set up a WLAN connection at the airport and I couldn't download any files. So there has to be a solution.
With unencrypted HTTP is very easy to block anything you want using a transparent proxy.
The filename and filetype of the download URL is not visible to the L7 matcher!Which I don't understand. HTTPS pages can be blocked with the above regexp, but HTTPS downloads cannot.
Same problem. Squid sees only "CONNECT www.sitename.tld:443" and not the reason for that connection.squid/proxy filtering with the L7 Protocol principle?
You misunderstood me.This is not a problem of MikroTik!
What you want is simply not possible anymore.
You can blame Google and others for migrating everything to https to prevent that people like you look in the traffic.
I don't believe that. Likely only via http and not via https. There is no way a public WLAN system, no matter what manufacturer, can see what you download over https.As I have already mentioned above, I have set up on airport WLAN connection and I could do everything. Only *.exe, *.mp4 ...files, could not be downloaded.
Exactly, therefore the next questionAnd please understand that it will have false positives. Someone not downloading a file but working in a google docs document will be affected just as well.
It had much better change to work in 2011, when it was written. There was more of plaintext http and less encrypted https back then."Also You can start this strategy base on File Extensions , Such as ( mp3 , avi , flv , zip , ... )"
It was possible only for transfers occurring in plaintext. I.e. http, ftp etc.On the page there is a hint, without an example of how to do it:
...
"Also You can start this strategy base on File Extensions , Such as ( mp3 , avi , flv , zip , ... )"
Now the question is, how do you do it?
not 1970k, but "1970k-0" does not work.@Sob, my brain is tired, been fighting with L2 fiber provider all day for poor service, but just so I can follow, I can't see what is wrong in the webfig, it shows 1970k instead of 1970000, which seems to be correct according to my current tired brain?
Without..."-0" it doesn't work for me.Isn't that a limit for the two directions? The 0 is supposed to mean "unlimited" but apparently it is rejected by incorrect validation. You can put a very large number there.