We've integrated login & register feature in Hubspot CMS using this g.com/_hcms/mem/login and session is working properly and getting all the data in CMS template.
We are using request_contact.is_logged_in to check the same but this is not working in blogs. Sometimes it's working sometime not. Also, not able to get the contact properties as well. Same sometime it works sometime now. Also, date parameters like now() not working in blog templates.
@BPatel1 totally fair question and yeah, you’re right to be cautious if you’re dealing with paid or gated content.
So here’s how it works: even though blog pages are heavily cached, HubSpot’s default page restriction feature (the one you apply via the content settings UI) still works because it runs at a server level before the page is served.
Basically, it’s a middleware layer that checks the visitor’s membership/session before it hands over the cached HTML. So while you can’t rely on request_contact.is_logged_in inside the template (because that part can get cached), the restriction logic itself is enforced outside the template — and that's why protected blog pages can’t be accessed by someone who’s not logged in, even if the page is cached.
That part’s secure. So yeah — if you're actually using HubSpot's native membership restrictions (via the "Access control" setting on blog posts or listings), you’re good. The caching doesn't compromise that — just the ability to personalize content within the page.
In your case, since this is paid content, I’d stick with server-side membership enforcement and skip the client-side JS tricks unless it’s for non-sensitive personalization like “Hi [name]”.
@BPatel1 totally fair question and yeah, you’re right to be cautious if you’re dealing with paid or gated content.
So here’s how it works: even though blog pages are heavily cached, HubSpot’s default page restriction feature (the one you apply via the content settings UI) still works because it runs at a server level before the page is served.
Basically, it’s a middleware layer that checks the visitor’s membership/session before it hands over the cached HTML. So while you can’t rely on request_contact.is_logged_in inside the template (because that part can get cached), the restriction logic itself is enforced outside the template — and that's why protected blog pages can’t be accessed by someone who’s not logged in, even if the page is cached.
That part’s secure. So yeah — if you're actually using HubSpot's native membership restrictions (via the "Access control" setting on blog posts or listings), you’re good. The caching doesn't compromise that — just the ability to personalize content within the page.
In your case, since this is paid content, I’d stick with server-side membership enforcement and skip the client-side JS tricks unless it’s for non-sensitive personalization like “Hi [name]”.
What you’re running into is that blog posts and blog listing pages are cached more aggressively than standard CMS pages — which is why things like request_contact.is_logged_in, now(), and contact properties can feel super unreliable on them. Sometimes you hit a fresh version and everything works... and then five minutes later it doesn’t.
Best workaround I’ve seen is to move any login-aware logic to the client side.
Basically, you set up a little serverless function in HubSpot that returns something like { isLoggedIn: true, firstname: 'Sarah' } and then use JavaScript on the blog template to fetch that and adjust what the user sees (show/hide sections, name, etc).
It adds a tiny bit of complexity, but it’s way more reliable than relying on the server to guess who’s logged in on a cached page.
If that’s too heavy right now, you could start with just showing a "manage account" link or something generic and skipping personalization until you're ready to handle it with JS + functions.
But yeah — I’d avoid trying to force login-based content directly into the blog templates. The caching will keep making it inconsistent.