Troubleshooting and Frequently Asked Questions

Here are some of the frequently asked questions and typical troubleshooting techniques for paywall and control feature set

Q1: Hot-linking protection does not work. Stream is always accessible for viewing.

There may be only few reasons for that.

Check "Geo and IP-based restrictions" section of your WMSAuth rule. Viewers from countries and IP ranges, those are included in the allowed list, are permitted to view streams, which the rule is applied to, regardless of signature. Please, refer to the Q6 and Q7 questions on this page for more information about geo-restriction scenarios.
Check the "Time tolerance" parameter of your WMSAuth rule. It means maximum time range that is allowed for web server and media server to be unsynchronized. It should be used when you can't arrange these times to match perfectly. If the "Time tolerance" value exceeds the time difference between web server and media server, then it actually prolongs the signature expiration time. We recommend to set up correct time for all of your servers and specify the "Time tolerance" value in the range of 60-90 seconds.

Q2: Hot-linking protection does not work. Stream is always blocked.

This means the setting is not complete yet. Hot-linking protection depends on 4 parameters. Together, they are TIPS — Time, IP, Password, Stream. Let's check what is missing.

Stream is available
1. First, make a testing web page which would contain only the URL signature code and a player to check the signed URL.
2. Now disable WMSAuth protection just to check if the original stream is playing. This can be done by editing the name of the stream in WMSAuth rule. Just change the name to something else, like "live" to "live_wmsauth_disabled", and save settings.
3. Still does not play? Please make sure the stream is available.
4. Plays fine? Enable WMSAuth protection back.
Password is valid
1. Check the key which is used in URL signature code and in WMSAuth rule — it must be the same.
2. If you use PHP language for signatures, make sure your key does not have dollar sign ($) as it's a reserved character there.
Time is correct
1. Check media server time — it must be correctly set to current time within its time zone. This is applied to both Wowza and Nimble Streamer setup.
2. Check that media server time is the same as web server time. The difference must be less then "Time tolerance" parameter which is set up next to "Password" field in WMSAuth rule.
3. Increase "validminutes" parameter. This parameter means the time when the signed link is still valid for checking.
IP address matches
1. Add the output of visitor's IP address on the test page. In PHP it would be "echo $_SERVER['REMOTE_ADDR'];" Make sure that the output shows your own IP address. If not, you may need to follow this article to get viewer IP address correctly.
  Also check this article for details regarding some proxies usage and restricting session IPs.
2. If still doesn't work, go to "Control -> WMSAuth paywall setup" menu and click on "Server logs" link. Then try playing the media. The logs will show the issues description within several seconds.
3. If you see "cannot find hash match for _IP_" message in the log, where _IP_ is specific IP address, check whether this address is the same as displayed on your web page. If you see any other message, please refer to the Q4 question on this page for explanation.
4. If the displayed address is the same as in the log message, then please refer to "Password is valid" subsection above. If not, then you've faced a rare case, when your ISP dynamically changes user's IP address per each request. Therefore, you can't rely on IP address match for proving viewer's validity and you need to identify and track your viewers on your own. That's what Pay-Per-View framework is designed for. Please read this article for details on implementation.

If something still goes wrong, please feel free to contact us and describe your issue.
Please send us the following:

URL of the testing web page mentioned in item 1 in the above list.
Source code of the web page so we could check it's fine.

Q3: My stream is blocked some time after playback start.

Go to "Nimble -> HTTP origin applications" menu and make sure that stream's application which you protect with WMSAuth signature is not listed there.
If the application is set to be HTTP origin, it doesn't have session ID, so Nimble Streamer keeps checking the connection session on every chunk download. As soon as WMSAuth signature generation time goes beyond "validminutes" parameter which you set in signature code, the connection becomes forbidden. So make sure that you don't have your signature-protected application in HTTP origin settings.

Q4: What do WMSAuth log messages mean?

So, you've navigated to "Control -> WMSAuth paywall setup" menu section and clicked on "Server logs" link.
The most common messages, those you can see are the following:

signature is correct but link expired — viewer has requested protected URL with expired signature. Expiration time is defined by the validminutes parameter. This could be either attempt of repeated usage of link, or protection configuration error. If this behavior isn't expected, please refer to the "Time is correct" section of the Q2 question on this page.
cannot find hash match for _IP_ — viewer has requested protected URL with invalid signature. That could be either attempt to use correctly signed link from different IP address (re-streaming), or protection configuration error. If this behavior isn't expected, please refer to the "IP address matches" section of the Q2 question on this page.
Time, hashvalue or validminues is null for _IP_ — viewer has requested protected URL without signature.
user [_IP_] is in allow list — viewer has requested protected URL and that request was honored regardless of signature, because viewer's address is included in the allowed list.
wmsauth checked link and it's valid — viewer has requested protected URL with correct signature.

Q5: What if WMSPanel becomes inaccessible due to network failure?

No problem, WMSPanel agent still will be able to work. All settings are stored on media server side, including GeoIP database, so the restrictions will apply without interruptions and your assets will be protected regardless of WMSPanel accessibility.

Q6: How do I allow my stream for just one country and forbid for all others?

Say you need people from Antigua and Barbuda watch your live broadcast and hide it from all other countries. To make this, just add the country to allow list, then scroll down to re-publishing protection, check all protocols and enter any non-zero length password. So if someone comes from Antigua, he (or she) will pass the check for allow list and will be allowed to watch the stream. Any guy from, say, Jamaica, will pass the check for country (as Jamaica is neither in allow or deny list) but will fail the check for re-publishing protection.

Q7: How do I allow my stream for just one country and enable hot-linking protection for it?

This is an extension of previous question. When you add a country to allow list in some WMSAuth rule, the restriction framework does not process hot-linking limitation. It's because "allowed" means "it is not limited". So to cover that case you need to go to geo-restriction section then select "All countries" from the drop-down list then add it to deny list. After that exclude the countries which you'd like to allow and add a hot-link protection password into password field. The workflow would be as follows: a viewer from allowed country will pass the check against deny list and then will be checked against media URL signature. You may exclude any number of countries from deny list to make their hot-link protection.

Q8: How to allow receiving of origin stream for edge servers and forbid for all other viewers?

You need to create dedicated WMSAuth rule. Add IP addresses of your edge servers to the allow list. Then specify a strong enough password. Stream will be allowed only for edges.

Q9: I need to allow connections from my edge servers in specific region but deny all other viewers' connections.

This is a more difficult case then Q8, it's when you've set up edge servers in some country and set up load balancing, but you want to make sure that your viewers from some region or country do not occasionally connect to your origin server. This origin server may handle end-users connections and provide signal for edges.
Another case is when you want to open your streams to specific people only.
Solution is simple. Go to your WMSauth rule, add required country to Deny list and then use "Add or manage custom IP ranges " link to define the IP range of servers or people that need special permissions.
Once the IP ranges are defined, you can go back to WMSAuth rule page, add IP range to Allow list and then check "Allow list has priority over Deny list" checkbox.
By default, Deny list has a priority over Allow list. So clicking on this checkbox you'll do what you need.

Q10: How to prevent files from downloading while streaming VOD?

To prevent files from downloading just set a password in WMSAuth rule for progressive download.

Q11: Some abusers can open my protected link directly via Kodi, SimpleTV, Targa.me, etc. What can I do?

Most likely, you have public web page, which is used by one of the mentioned applications to retrieve correct media URL from it. Please, read this article , to learn basic approach in acting against such applications. Sample code can be found in our github repository.

Q12: How can I make unique signature for specific stream?

Nimble Streamer is capable of creating stream-based signature to make it unique for any application or stream name.

Q13: Are there any examples of building WMSPAuth paywall solutions?

All code samples can be found in WMSPanel github account at hotlinking protection samples and API samples repositories.
Also, please read The Paranoid’s Guide to Internet Video Streaming to see the real-life example of pay-per-view integration.

Q14: Is connections count and bandwidth limit applied to all servers in WMSAuth group?

The limitations are applied to each server separately. So if you need 6000 simultaneous connections for 3 servers, you need to add those 3 servers into the group and specify 2000 connections limit in the rule.

Q15: Dispersa cannot check protected streams.

Dispersa stream monitoring uses distributed checkpoints so you need to make those checkpoint servers to be able to access streams. You should add checkpoints into allow list so WMSAuth rules would be ignored for their requests.

Q16: How to protect my media URL from copying without front-end source code modifications?

For robust protection we recommend to use Hot-linking protection and domain locking. If using media signature is not necessary for you, but you want to restrict the ability to view your media from other domains — there is simplified Domain Lock method.

Q17: How do I protect my streams if I use CloudFlare or other proxy?

Read this article to see code snippet for CloudFlare case and also use this article to learn more about working with reverse proxies.

Q18: How can I see raw pay-per-view data which comes from my servers?

The debugging handler and interface allows receiving data from servers and viewing results via your browser. Use it to see what requests will come from your server instances to your own handler.

Q19: I block users via pay-per-view but they re-connect after some time.

PPV handler returns blocked IDs on every call. When Nimble Streamer gets new PPV handler response, it clears previously blocked IDs list and makes new block according to new data. So if you have some ID in first response from handler and do not include it in all further responses, this ID will not be blocked. So the resolution would be to keep all blocked IDs in all of your responses during streaming event.

Q20: How can I use WMSAuth-protected streams from Android or iOS mobile apps?

We do not recommend embedding signature generation code into the mobile app directly.
Instead, you can create a web application which will generate URLs with signatures according to WMSAuth algorithm and provide those URLs to your app. Your mobile app will send some REST request with its IP (if necessary) and necessary streams names, and authorize on web app side according to your own business logic. Then the web app generates the signed links and sends them to your mobile app for playback.

Q21: When accessing from Android browser I get "Cannot find hash match" in Nimble logs.

This probably means Data Saver was turned on for Android device. In this case browser accesses the player page through caching proxy, and you get signature for proxy IP instead. To obtain real client's IP you should use X_FORWARDED_FOR header, as described in this article.

Q22: How can I restrict embedding my player into 3rd-party website via iframe?

You can set these headers (in this example, via PHP) to allow embedding on the same domain only:
header("X-Frame-Options: sameorigin"); header("Content-Security-Policy: frame-ancestors 'self');
or these headers to allow particular domains:
header("X-Frame-Options: allow-from https://yourdomain.com/"); header("Content-Security-Policy: frame-ancestors http://yourdomain.com/");
Since "allow-from" isn't supported in Chrome and frame-ancestors aren't supported in IE/, you should have both headers to make browser handle at least one of them.
Also please read this and this articles on MDN website.