Design Approach

Key Requirements

Let's define our requirements.

1. Specific pages cannot be accessed without first clicking a button that indicates an acceptance of terms
2. Those pages may be Webflow static pages, folder, or collection pages
3. No sign-up enrolment process, or password entry is required
4. If someone were to try to access the secure content link directly, e.g. it's shared in a forum or by email, they must accept the terms too in order to view it
5. Search engines do not index and make the content available in SERPS ( search results pages ).
6. Work on Webflow-hosted sites.

The Lowdown

Webflow only offers two security options-

• Password-protected pages & folders
• Memberships, a new user system, in BETA

There is no option to do server-side code, so options are limited.

The Design Approach

The best approach we've found is to to build this capability on top of Webflow's existing password-based login model.

This is accomplished by redesigning the login page so that it contains the user agreement and acceptance button, and hides the regular password form.

Using custom code, clicking that button automatically fills in the hidden password and submits to authenticate the user.

The advantages are;

• Fully Webflow hosted, for ease of updates
• Users cannot access the page without going through the accept page
• No easy way to guess / hack the password, and the password field is hidden.I'd still add a no-hacking clause to the user agreement though as a legal SoP
• Google won't access your secured pages
• You can secure static pages, collection pages, or folders

Disadvantages;

• You can only have one login page, thus your login will always be this button-click. You can't have this feature, and also a different folder that uses a regular password login.
• You can have multiple secured assets, e.g. a folder, a page, a collection page, but the user will have to click the button for each of those individually. They'll be asked again.
• Internally, you will want to have the exact same secret password for all of those assets, or your script gets more complex for little reason.
• Logout realistically happens at the end of the "Session" which to some browsers means when the whole browser ( not just the tab, or the site ) is closed.
• No possibility of a logout button, because the cookies are httponly. We cannot delete them with script.

It's a pretty good approach for the right situations, and our clients have found it ideal for their set-up - but consider that logout requirement carefully.

Yours might have different legal requirements.

Hit me up if you need a programmer to built this out for you.