New update causing implementation issues with Plex

Support General Questions
1

Good afternoon, I'm my ISP is a CG-NAT (tmobile home internet), and to expose my plex service I have been using Zrok. I'll use the command zrok share public 32400 --headless --insecure.

It has been working fine/intermittently(probably because of tmhi) so I'll have to restart the service every other day.

However, with the new implementation of the interstitial pages? I appear to be in a predicament where I will now have to give that token to everyone to go through the http page first before it can be accessed on the plex app now? I'm noticing that I cannot access my server now until I do go through the interstitial page to generate the cookie. That isn't realistic for me to do this every time I have to create a new share because of the isp I use being a little funky. I also don't think it is worth it to pay for the service given the instability I already have with it corresponding with my network.

I saw there is a way to remove the interstitial page? I am having trouble locating how to do that on windows, and I believe that may be hidden behind a paid tier?

If I could get insight on this it would be appreciated.

2

Adding an HTTP header of skip_zrok_interstitial set to any value in the requests to your share, or changing the user agent to something with a prefix other than Mozilla/5.0 makes the interstitial go away. For example, if you hit your share with curl, there is no interstitial because the User-Agent header starts with curl.

Upgrading to any paid tier will also make it go away.

We were initially considering adding a $0 paid tier, requiring a credit card to authenticate with the service as another option to get rid of the interstitial. Is that something you would be interested in?

The interstitial is there just as a mechanism to thwart people who sign up for the free tier and use zrok to host phishing sites. We really want to keep a free tier that has access to public shares, but we need some mechanism to prevent phishing attacks using zrok.

3

You could also use a reserved share created using zrok reserve, and then share it using zrok share reserved. That would keep your share token from changing every time. You can restart zrok share reserved as many times as you want, and the share token remains constant.