Which one did you use?
Makes sense. Spending a little time in it showed some awesome flexibility but would certainly get up there in costā¦far outweighing the value for my use-case.
What no-code service did you choose?
I would love to hear more about your thoughts on this. Have you read this mentioned somewhere?
1 Like
Itās what they say here:
Although this has been up for ages so not sure how their dev is progressing.
1 Like
Ah, gotcha @jasondarkā¦ it looked as if you were referring to Webflow specifically, not MemberStack. It would be surprising to me if Webflow was specifically creating such a feature.
Have a look at the last comment in this thread where the Webflow CEO hinted at something coming in the next couple of quarters.
More specifically, this part:
So THAT is super interesting @jasondark and to be honest, very surprising. Itās hard to really read into what that means or if theyāll even complete it, but interesting none-the-less. I had been following that thread but as of late, stopped. It was devolving a bit too much for me 
Yep Iām guessing that initially itās going to be something to do with e-commerce user accounts but we will see.
Hey Jason,
I have made a basic firebase chat and I want users to sign in with memberstack and chat with my firebase chat.
Only problem I am facing is:
User authentication is required with firebase
Is it possible to let people sign in with memberstack on webflow and then chat with my firebase chat.
Please get back to me ASAP itās really urgent.
I hope you understand.
Not directly as unauthenticated or anonymous users canāt write securely to the Firebase Firestore. You might be able to set up a back end process that creates your Memberstack users as Firebase users too, then maintain a reference between them somewhere. Then in the app authenticate the user with Firebase behind the scenes. Memberstack is a paid service so maybe ask them.
2 Likes
Right now based on your @jasondark videos, Iāve set up the basic login/logout. So, THANK YOU.
Next, Iāve created a Firestore ādocumentā with the same auto-generated user.uid created by Firebase at signup and have stored a few custom fields.
I was able to successfully pull in this document dynamically using their documentation with some āauthā additions to set the userID. (Code may need some cleaning since Iām not a js expert).
<script>
firebase.auth().onAuthStateChanged(function(user) {
if (user) {
var userID = user.uid;
}
else {
// No user is signed in.
}
var docRef = db.collection("users").doc(userID);
docRef.get().then(function(doc) {
if (doc.exists) {
console.log("Document data:", doc.data());
}
else {
// doc.data() will be undefined in this case
console.log("No such document!");
}
})
.catch(function(error) {
console.log("Error getting document:", error);
});
});
</script>
With these pulling in documents and their fields - I should be able to add the values to elements for displaying to customers in their dashboard.
Next, I am trying to look at how to create custom claims with the intention of hiding/showing links and allowing/disallowing access to specific pages based on the claim (e.g. redirect if does/does not match claim).
Hopefully, this info helps someone else.
If anyone has any input regarding this, feel free to interject!
Cheers
I have tried Memberstack and found it a reliable option for payment gateway without the use of code. It is easy to integrate Memberstack for webflow projects. With Memberstakc you wouldnāt have to end the stripe via email because it can make these procedures for login users.
On the contrary, Google Firebase is also a good option especially if you want a self-hosted and secure backend. However, it is not enough good for iOS testing and projects and in this regard, you can see alternates from here. Withal, if you want to use it with Webflow integration then I would like to go with Memberstack. By the way, I also heard a lot about Memberspace.
Memberstack 1.0 certainly came with limitations.
I know this because before I was a team member, I was actually a user of the product.
But weāre in 2.0 now, and our product has come a long way.
Still, I totally hear the concerns raised in this thread.
I want to help shed some light on our product, how it stacks up against Firebaseā¦
and what to expect when using both of these products in Webflow.
Hopefully this will help anyone else who lands on this thread to make an informed decision.
#TLDR
In Webflow, there are ways to circumvent protected pages - but Memberstack data stored directly on members is 100% secure.
If you store member data in a CMS and map it to elements on a CMS template - that data is NOT secure.
If youāre using Memberstackās API to dynamically inject member data on the page (which is best practice) - then that data is ONLY accessible to the logged in member (whether JavaScript is enabled or not).
Comparing Memberstack & Firebase
First itās important to note that Memberstack & Firebase are meant to solve different types of problems.
Firebase is a backend as a service - they have way more features.
Memberstack is a user management service - with the added benefit a deep integration with Stripe.
Key differences between Memberstack & Firebase:
- Memberstack couples auth and payments together in a single API
- Firebase couples auth and database together in a single API
- Firebase is expected to be used in web applications
- Memberstack is expected to be used in Webflow
- Memberstack is low code friendly
- Firebase is more advanced and requires more technical knowledge
Key similarities:
- both offer client side JavaScript libraries
- both offer node.js libraries for server side authentication and admin CRUD functionality
Additionally we have Webflow AND React libraries built on top of our JavaScript library
Now, when it comes to using auth (in the context of Webflow),
Firebase & Memberstack are going to operate in almost the same way.
Meaning - our client libraries work similarly & and we effectively offer same level security.
In Webflow, there are ways to circumvent protected pages - but data stored directly on members is 100% secure.
This means that actual member data is inaccessible to anyone who doesnāt have a valid session. We verify member JWT tokens on our own servers every time a request made through any of client side libraries (including Webflow).
Firebase handles this pretty much the same way.
Which means, The problem isnāt the tool, its the environment.
More specifically how these environments are designed to work.
The challenges with static site builders
Typically, auth is implemented in web-applications.
In earlier years, web applications coupled the client & server together.
The developer had access to the client and server and full control over the authentication process from backend to front-end.
In modern day web-applications, the client can be āde-coupledā from the server.
Now, most client apps are built with Single Page Application frameworks like React or Vue. These new frameworks are dynamic & reactive by nature; they respond immediately to changes in state (like authentication status) - making it easier to control what content ends up on the DOM (and what to render when JS is disabled).
These frameworks also make it easier to integrate with serverless technology like Firebase cloud functions or AWS Lambdas to perform server side authentication.
Webflow offers neither of these capabilities.
Itās a tool designed for building websites, not web-apps.
So that means everything is static.
All of your content (even css āhiddenā content") is already pre-rendered on the DOM.
Anyone who is console/dev tools savvy can bypass āgatedā pages, turn off JS and see the content. @jeandcc successfully demonstrated this earlier.
So the real question you need to ask yourself is:
Do I care more about protecting data? Or protecting pages?
Because having pages exposed is technically not that problematic if the pages donāt contain any user specific data.
In @jeandccās second example, it would appear that he āunlockedā a protected memberās page. But If you look carefully at the URL @jeandcc navigated to in his script, youāll see that its a generic URL.
It doesnāt have a dynamic path like āmysite.com/{protected-route}/{memberstack-id}ā
In V1, Memberstack was only capable of showing user data on member specific pages (aka CMS collection pages)
Which means, @jeandcc accessed a āprotected pageā but he didnāt access real member data.
It was simply placeholder data on a CMS template page for member dashboards.
Our API would only populate that page with actual member data if and ONLY if that member was actually logged in.
Hopefully that context helps clear things up!
The final thing Iāll add is thisā¦
If you do care about protecting pages AND data, then you can look into:
- Adding a Cloudflare worker to your Webflow site that authenticates a user (using Memberstack or Firebase admin libraries) at the edge (before the page loads).
- Using single page application frameworks like React or Vue that give you more control over the frontend
4 Likes
For some reason I got a notification about this thread so went for a read. What a trip down memory lane, this comment of mine was from over 2 years ago and still nothing is released. Interesting.
That was really helpful, thanks! Good suggestions about extra security measures, and while I was fairly confident that hacking through to a gated content page couldnāt expose data stored on a member, it was nice to hear it straight from the horseās mouth!