We’ve rolled in production this morning a SecureToken setup after testing it in the last few weeks. Just as a sidenote we are including the client IP in the hash generation. In the test everything was alright, however today we encountered a problem from some of our customers. 403 responses seem to be appearing to random customers: random countries, random ISPs. The 403s are received across diferent wowza instances, for all requests that are being done by those users, even after getting a new IP. Practically some users do not have access to any content served by wowza and secured with SecureToken. After trying to isolate the problem we’ve managed to test with two users having problems on a wowza instance, after inspecting the logs it seems that for some weird reason when calculating the SecureToken wowza is swapping the order of the IP and secret. Practically in our wowza logs I get something like the block below:
ModuleCoreSecurity:string hashed: vod/_definst_/mp4:some.mp4?secret&81.196.30.45&letokenendtime=1427456998&letokensource=web&letokenstarttime=1427449798&letokenuserid=0
or
ModuleCoreSecurity:string hashed: vod/_definst_/mp4:some.mp4?secret&86.121.74.34&letokenendtime=1427460222&letokensource=web&letokenstarttime=1427453022&letokenuserid=0
which is clearly wrong, and will always fail, because i calculate the hash with …something.mp4?IPaddr&secret&…. Again this only happens for some users, not all, so my securetokenhash is calculated correctly:
Do you have any idea why that would happen or if we can do anything to fix this problem? Needless to say, it is a bit frustrating to not be able to offer a consistent experience to all our users.