You can create random page path and exclude it from search. It will have the same security as password.
Sorry, @Bogdan, my brain is a bit slow today — not sure I understand. You're suggesting that we just use a random path, and just exclude it from the sitemap, so that only those who know the path will reach it?
If that is the case, it's not quite as secure as putting a password on a page... Is there a way to actually password-protect a page?
Even something like basic http authentication?
@Bogdan @Igor Couto Would also really like to see this. Basic http authentication / something similar to webflow's basic sitewide password protect feature available on the site dashboard would be great. The use cases are:
1) to show a page to a client without risk of hurting their brand or ours by showing a semi-finished page (potentially with misleading content) that others could see.
2) It avoids problems with image licensing and license bots while still changing out and licensing media pre-launch
3) It allows me to test sites natively on other devices (e.g. a mobile phone) privately prior to launch.
This would be my number one feature request before being able to use webstudio for paid work
but they have not yet made any password-protection as far as I know - which is .... weird 🙂
Thanks Jacob! This is helpful for sure. Could still really use a password protect. Hopefully it's something that can be considered for the roadmap!
but really I find that annoying somehow - dont get me wrong - i like webstudio haha 🙂 so .... but this part for an example - is straigtforward weird - if you can call it that 🙂 - in my opinion
its just a super weird old-school feature to have, password protection with a single password for all users. Ideally it should be a proper auth
Just to be clear: we want to be able to have different, unique passwords for individual pages - not a single, site-wide password for every page.
Yeah, I mean it's a password that gets shared with all users, same one, it's by design not secure
At least for my own case, the limitation here in security is succeeded by simplicity for clients. And the password meets the need to show the general intention that the page is not live.
This is largely for staging sites that are temporarily hosted while under construction so a simple method to hide content that can be provided to a client (or myself) to view the page is useful. (In this instance, it's actually advantageous for them to be able to share the page quickly and simply with colleagues).
We've also used simple passwords to hide "staff area" pages not intended for the general public, but that contain nothing truly confidential - e.g a page of links for the client's staff, where each link takes you to a (proper) 3rd party login page to their benefits provider for example. Because the access is generally cached, this reduces friction for the user from authentication after authentication.
I can 100% appreciate that for sites offering paywalled content and similar, they would need real secure authentication on a specific page etc
@Mike same thing can be achieved by using a secret page url and not linking to that page from other pages
What is being requested is one step beyond that: once the visitor reaches the 'hidden' page — whether intentionally or accidentally — then they should be given a login where they should provide a password.
This is not the same. It is one level "more hidden".
It should be easy to implement with simple HTTP authentication, and be provided as a simple setting on a per-page basis.
You could then extend the functionality further, by allowing developers to dynamically bind to the password setting from a field in their CMS, for example. This would open up a whole lot of functionality, like making creation of 'member pages' and the like a lot easier.
