Statamic 2 already had some sweet, sweet content protection capabilities. But what if I told you (insert tired meme of Laurence Fishburne in tiny sunglasses) things can get a little spicier in v3?
Now that Statamic is built as a Laravel package, it follows more Laravel patterns. For example, in v3 if you really wanna crank the Scoville dial (how far can I stretch this already-weak analogy?), you can easily add your own custom driver to protect your content from all the gnolls coming for your tasty pages. (Do you think I could turn creator of the weakest of analogies into a lucrative career?)
On the other hand, if you just want to put some giardiniera on your tacos (I’m not so sure about your taste in tacos…), you can use one of the built-in drivers. For a top-secret project I’m working on now for one of our clients (🤫 don’t tell anyone I told you, but it’s TikTok for teenyboppers), we needed to just throw up (not like this, though 🤮) some site-wide protection without any user accounts or anything.
We know that it’s easy to feel lost or to be misled by development firms who see your problems as opportunities for profit. That’s why we put together a buyer’s guide to hiring a software development firm. It’s designed to help innovation leaders evaluate potential technology partners. Before you start searching for your next custom app development services provider, read this guide.
How do?
The simplest option is to:
- Open up config/statamic/protect.php (didn’t Medium once allow you to use backticks to create inline code elements?),
- Set the default (hey! it worked this time?) key to 'password', and
- Configure the allowed passwords in schemes.password.allowed.
I prefer a more flexible option, though. For one thing, I don’t want to enter a password to view the app’s front end in my development environment. We may not want that in our UAT environment either. Environment, environment, environment. Yes, environment. Big ol’ hint as to how I took care of this requirement. …I used the .env.
If you want to configure this per-environment as well, you’ll first need to update config/statamic/protect.php (REDRUM!!!!). Here’s what the relevant bits of mine look like now:
config/statamic/protect.php
In case you’re not a PHP developer, that explode() function on line 9 just converts a string into an array of strings (the setting expects an array of valid passwords). It’s like JavaScript’s String.prototype.split() method but in PHP.
.env
If you want/need an explanation of the .env, just check out the comments. I like to leave inline docs for otherwise-undocumented environment variables in .env.example in case anyone else working on the app in the future doesn’t know what they do. I also like to name environment variables as UPPERSNAKECASED versions of the key-path you’d use to access a configuration setting in Laravel code. For example, if I wanted to check which content protection scheme is set in the config, I’d use config('statamic.protect.default'). In this case, that seems a little weird, but I promise the pattern comes in handy for other use cases, and following patterns reduces decision fatigue.
Anyway, to learn more about protecting your content in Statamic, read this or check out Highland more. We're a top rated web development company in Chicago that can help you build a top-notch Laravel application.
