Webflow User Accounts vs Memberstack / Wized / Xano

How are “properly” people securing web pages for logged in users?
My goal is that even the static content of a page is not accessible if the user is not logged in.
Is there another way to accomplish this same behavior as #1 if MemberStack, Wized, or Xano are being used to log into a site?

  1. Webflow User accounts - This appears to work because if the user is not logged in, they are redirect and get a 404 error. This leads me to believe that there is server side code preventing redirecting the page i.e. not Client SIde Javascript doing a redirect. Is there anyway to get this to occur when using Wized/Xano or memberstack? Unfortunately I read an earlier post that says that the UserAccount feature is closed and not being developed further and I would want Google Auth and other features as well.
  2. Memberstack - When using memberstack Attributes to ‘secure’ a page, the pages and hidden content are easily accessible without logging into the site. If JavaScript is disabled, the page can be viewed. Some some sites dong redirections using NoScript tag, but this doesn’t prevent the site being read by curl or some other scraper, then the Pay Wall content is easily accessible. At least it was when I tested it on my site and spot checked a few other sites.
  3. Wized - I haven’t tried Wized yet, but if it doesn’t do server side hosting of the pages; I don’t know how it would be achieved otherwize. Hopefully someone else knows as I’m not an web expert.
  4. Alternative Solutions? - Given the entire goal of ‘no code’ is to easily create pages, I was hoping that would extend to scenarios where I wanted pages to be secured properly. The only way I would see it would be to have all the pages have dynamic content; that is, pages only served up if the user has authed against the remote Database in Xano/Wized etc. and the site querying for all the content ‘static’ content.
    Thank you in advance for your replies,
    Cheers, Larry

Hey Larry, you understand the options quite well.
They fall into three classes;

  1. Server-side auth & content gating ( good content security )
  2. Server-side auth, client-side content gating. Content is not directly protected. Can be circumvented.
  3. Server-side auth, data programmatically retrieved from an external DB. ( good content security )

Unfortunately, Webflow User Accounts is the only one in category 1, and doesn’t offer Google OAuth login support.

Memberstack and Wized do offer this, but they’re in category 2 ( less secure ), or category 3 ( much more complex to build and more expensive to host ).

There isn’t an easy path to get everything you want.

However if you have a good tech team, it’s possible to combine those features into one system with a 4th approach;

  1. Server-side auth + server-side content gating via Reverse Proxy ( good content security ).

I’ve built #4 on top of Webflow User Accounts, to add specialized gating support, such as for individual collection items ( your access group can see these courses for free, but cannot access the Premium courses in the same CMS collection ). It adds some complexity to the infrastructure, but gives a huge amount of capability.

I suspect something similar could be built to integrate with Memberstack as well, I just haven’t had the bandwidth to prototype it. The basic idea would be that the RP determines what to deliver, based on the user’s characteristics such as access groups. The challenging piece is getting the user’s identity. In Webflow User Accounts it comes directly from Webflow’s servers, so you can determine it via an HTTP-only cookie.

In Memberstack, those login/logout event communications would be with an external server, so the RP wouldn’t see those cookies. Instead, you’d have to inform it of who is logged in so that it can do its work. I think the best security model would be to have the RP use Memberstack’s API for the user information access, and your site just calls an RP endpoint to inform it of the login/logout events, and the Memberstack UserID. That way it must be a valid existing user account, rather than potentially-fabricated access rights.

1 Like