Password Protect Pages, not based on email?
Is there a way to set up Pages so that they're password protected by an actual password you can set.
Right now have the access rules set up but they're a little confusing, and they won't send an email every time if you got one recently. Noticed theres a bit of an overlap with the previous code not working any longer and it not wanting to send another email.
Used to just having staging protected by an htaccess passwd I could give clients to preview their staging. Is something similar possible or is the emailed PIN the only option?
If the emailed PIN is the only option for this, what is the correct way to order the rules?
1. Deny rule set to Everyone as the top spot
2. Allow rule that has the PIN option and the emails both set to include as second spot?
8 Replies
nd they won't send an email every time if you got one recently.You can increase the application session length, if you're talking about getting logged out too much. You should always get an email though, although it may be worth keeping in mind it'll just silently do nothing if you enter the wrong email.
Deny rule set to Everyone as the top spotYou don't need this, if the rule is Allow, they need to match one of the includes. You don't need to specifically select PIN either, you can configure the providers to use under The Authentication tab of your application, or if you just have Email Pin, that's the only one anyway.
TLDR: You just need an Emails allowed include rule, or you can configure an Access Group that allows a set of emails and include that.
If the emailed PIN is the only option for this, what is the correct way to order the rules?It's not the only option for it. You can configure identity providers like Google or Github, for free, and sign in via one of those. It makes it easier and still secure. However, if you need a password, Access doesn't support it, but a community member has built an example, using function middleware, that allows you to do it, although it is going to be less secure: https://discord.com/channels/595317990191398933/783765338692386886/1129283281486090341
yeah I'll stick with PIN since its mostly to stop staging sites from getting crawled and only allowing us and the clients to see them
so with no rules it'll block all traffic? then just add an allow with the emails?
Well you can't have no include rules, you could have include: Everyone though, they need to meet one of the include rules (they're logical ORs between each other), and all policies must include at least one include rule:
https://developers.cloudflare.com/cloudflare-one/policies/access/#rule-types
Access policies · Cloudflare Zero Trust docs
Cloudflare Access determines who can reach your application by applying the Access policies you configure.
ideally we're trying to figure out how to do like..
clientsite.ourstagingsiteurl.com - latest commit on
staging branch <- PIN protect
random-branches.clients.ourstaginsiteurl.com - for random branches <- PIN protect
clientsite.com - latest master commit, no PIN
awesome
okay cool this should work in a way
trying to convince everyone this is viable for us and then start doing more SPAs and less... wordpress 😂Good luck!
Yea, you can use wildcards in application paths: https://developers.cloudflare.com/cloudflare-one/policies/access/app-paths/
Something like a application for
*.ourstagingsiteurl.com would match clientsite.ourstagingsiteurl.com but not ourstagingsiteurl.com. And you can configure mutiple domains in the same application, i.e add *.clients.ourstaginsiteurl.com to the same, or a new application, and you just wouldn't have any access policy on clientsite.comApplication paths · Cloudflare Zero Trust docs
Application paths define the URLs protected by an Access policy. When adding a self-hosted web application to Access, you can choose to protect the …
it automatically names preview branch deploys correct? that can't be configured to match the branch name?
really appreciate the tips, just getting started with this after quitting netlify lol
You get a preview for the git hash:
i.e
https://46622ba2.<snip>.pages.dev
and if the branch it is pushed on is not main (and you're using the Git integration, otherwise things get more complex), it would also be reachable on the branch name, i.e
https://test.<snip>.pages.dev
https://developers.cloudflare.com/pages/platform/preview-deployments/#preview-aliases
You can point Custom Domains at specific branches by adding them as normal custom domains, and then changing the created cname target to that githash/branch
https://developers.cloudflare.com/pages/how-to/custom-branch-aliases/#add-a-custom-domain-to-a-branch
(You also have to be using CF DNS to point Custom Domains at specific branches)ohhhh perfect
whaaaaaat they're atomic so you can visit one for every commit
got everything set up perfectly! appreciate you!