How it works
A plain-language look at how Sami B2B Lock, Password Protect enforces your locks on the storefront.
You don't need to understand any of this to use Sami B2B Lock, Password Protect — enabling the app embed once is all the setup the app needs. But if you're curious what's actually happening when a shopper hits a locked page, or you're trying to reason about why a lock is or isn't showing, this page walks through it.
The app embed runs on every storefront page
Sami B2B Lock, Password Protect is delivered to your storefront through a Shopify theme app extension embed, listed in your theme editor as Sami Lock. Once that embed is turned on for a theme, a small script from the app runs on every page a visitor loads on your storefront — the home page, product pages, collection pages, blog posts, your cart, and so on.
That script doesn't do anything on most pages. Its first job on every page load is to check whether the page matches any lock you've set up at all — and for the vast majority of page views on most stores, the answer is no, so the script gets out of the way and the page renders normally.
Figuring out which lock applies
When the current page does match a lock — because it's the exact product, collection, page, blog article, or URL you locked, or because you've locked your whole website — the app moves on to checking your access rules for that lock.
This check happens directly in the visitor's browser, using information the app already has access to as part of running on your storefront: whether the visitor is logged in, what's in their cart, which language and country they're browsing from, and so on. Most access rules — logged-in status, customer tags, cart contents, date ranges, storefront language — can be checked immediately with that information, without waiting on anything else.
A few rule types need to look something up before they can answer yes or no:
Location matches the visitor's country, which the app determines with a public IP-lookup service rather than reading it off the visitor's account — so a VPN or proxy can change what country is detected.
Cart conditions (products, variants, quantity, or subtotal) are re-checked whenever the cart changes, since a visitor can add or remove items after the page first loads.
Purchased items and Order quantity look at the signed-in customer's past orders to decide whether they've bought the right thing before, or ordered enough times.
Once every rule in at least one access key comes back satisfied, the app treats the visitor as unlocked and lets the content show normally (subject to whatever lock behavior you've configured, like hiding a price or redirecting). If no access key is fully satisfied, the app applies the lock — showing a lock screen, hiding a price or Add to cart button, or redirecting, depending on how you set it up.
Checkout locks work differently
Everything above describes how locks on your website — products, collections, pages, blogs, URLs, and your whole storefront — are enforced. A checkout lock is enforced differently: instead of relying on a script running in the visitor's browser, it's enforced by Shopify's own checkout validation, using the conditions you set up in the app's checkout rule builder. That means a locked checkout condition can't be bypassed by disabling JavaScript or otherwise working around client-side code the way a purely visual lock theoretically could — Shopify itself refuses to let the order complete until the condition is met.
Because checkout enforcement is separate from the website-lock mechanism above, turning on the app embed is still required for your website locks, but it has no bearing on whether your checkout lock is active — that's controlled entirely by the rules you save in the checkout lock's builder in the app.
One setup step, nothing to edit in your theme
Because the app embed handles all of this itself, there's no theme code for you to write or maintain. You don't add snippets to templates, edit Liquid files, or maintain a list of locked pages in your theme — everything lives in the app, and the embed reads your current lock configuration every time a page loads. Enabling the app embed once is the only setup this requires; after that, creating, editing, or removing locks in the app takes effect on your storefront automatically, with nothing further to enable in your theme.
Related docs
Last updated
Was this helpful?