i just enabled membership on a test site and wanted to use the function to enable user account creation ( sign ups) via invitation only which i tested . only problem is that if anyone then decides to share the link or url of the sign up page which is by default (yourwebsite/sign-up ) it allows anyone else to freely create an account without an invitation because while the invitation has got a token you can just type sign-up at the end of the site url and it brings up the sign up page anyway !! is there anyways someone knows to prevent that ?
1 Like
Good observation, I hadn’t noticed that.
I’d recommend posting it in the Membership BETA forum so the Webflow team sees it.
Will do thanks a lot :o)
That seems to be a another forum on circle . any ideas how to join the group?
Yeah, it was part of your Membership BETA invite. Check your email, it will give you the links you need.
Got it thanks for the help
1 Like
Just thinking a bit more about this;
I think that the ability to sign up with a different email than the invitation was sent to is probably important.
Just because you have someone’s email doesn’t mean that’s the one they want to use for logins.
I have more than 10 email addresses.
The scenario I think you’re describing is-
- You invite Bob
- Bob forwards the invite email to Fred
- Fred enrolls
- You didn’t want Fred to enroll
If you’re really having problems with unauthorized people accepting the invite, a way around that is to two-step the enrollment process.
First invite them, but with only Public access-
Then, once they’ve accepted, you verify it’s the right person, and then upgrade their access to the content groups you want.
@xenostorm @webflow-user-account @webdev I noticed that when the email is forwarded to someone else, when clicking on that link, the email field is already prefilled and greyed out with the email address of the person who was invited. I imagine that stops someone else from creating an account. Am I missing something?
Btw, do we know how long the invitation link is good for? I sent it to someone and they responded after a couple of days that the link had expired.
That’s just a (very) nice connivence… having the email pre-populated and the form field disabled.
Here’s what’s happening behind the scenes…
When an invitation is created, Webflow generates a one-time, unique token that is associated with the email used for that invitation.
That email is associated with that specific token and no other.
Webflow then appends that unique token to the url on the invitation link sent:
When you click the link shown above, you go to the signup page with that token in the url.
Webflow grabs that url token and does a lookup within their internal database to do a few things:
Checks if that token has already been used for a signup, if so, display an error, otherwise…
Grab the email associated with it, and display it on the screen.
That’s why you see the invited email address displaying and greyed out versus whatever email address you forwarded the invitation too.
That url token is associated to only 1 email address, and it should only work 1 time.
Yea, I consider this a bug when you look at the user flow I’ve outlined above.
But… I think they are currently considering it a limitation.
If you choose this option (“after manually adding users to this group”) for a role:
…that should never happen and you should only ever gain access when you (as the site admin) log into your Webflow account and manually add them.
The current state as I understand it is that there are 2 unique user flows for this:
- Ecommerce (paid or free accounts)
- Non-Ecommerce (free accounts only)
For the latter, there currently is no choice (and I consider it a bug).
For the former, using Ecommerce, I believe this is now fixed. You can set it up for free users (without requiring a credit card upfront) and control this AFAIK.
To hear more of our voices we need to either reach out directly to support or chime in on the Memberships Beta forum.
Feel free to use my breakdown as a reference to explain the situation.
So far I’ve seen them take feedback like this and change it with enough of our voices heard.
1 Like
Hi, I have a similar use case scenario, but a slightly different problem. I hope there is a work around that you can point me to!
I have a site with over 500 invite only members. After inviting them to the member space, it seems that only 10% have actually received the invite email. Others have been blocked by their company severs. I need to generate invite links to email them from a different email address. However, I can’t figure this bit out! I’m not really sure how to progress other than using a different system all together (going back to memberstack or airtable).
Any advice?
I believe that’s based upon the emails you’ve added to your project. But if you need to rotate the sending email, Webflow won’t allow that AFAIK.
That all said, save yourself wasted efforts testing different setups with Webflow Memberships. A different solution will be your best approach with what you’ve described. What your asking for spans beyond the basics.
The key for you is handling the email sending yourself, through your own provider, outside of a memberships platform.
You need a professional service that focuses on deliverability.
So make sure your new solution either allows you to integrate your own email provider, or they don’t require an invitation system like Webflow Memberships does.
1 Like
Hey Anna,
Is this one company? A 90% block rate is a bit weird, it makes me suspicious that the blocking is not due to the origin or content of the emails, but rather to the fact that they got all 500 at once, and it triggered all the spam defense systems.
You could try a drip-feed approach, inviting in small batches, e.g. 50 at a time, twice a day.
You might also get the company’s IT dept to whitelist the invite email address / domain, to improve the chances those will get through.
PLAN B
If the blocking is triggered by the mass-send, or triggered by something specific to the invitation email, you could also run some tests to see if the account-verification email ( send after self-enrollment ) gets blocked.
If self-enrollment verification emails are NOT blocked, then you can have a kind of pseudo-invite process instead.
But this is more involved. To cover all the bases I’d build that like this;
In your /sign-up page;
- Add a META no index to prevent the page from appearing on search engines
- Add a validation
patternattribute to the email address field, which requires emails from the approved domain@clientco.com - Possibly, add some JS to check the originating IP’s and match it against an approved range of traffic from the company ( may not work if they work from home without VPNs ).
Throughout the site;
- Remove any links to
/sign-up, e.g. from the/log-inpage.
In your Memberships setup
- Separate all of your gated content into a special access group, I’ll call it
verified-employee. Do not assign that access group automatically on new account creation.
As an admin;
- You will verify, and assign the the
verified-employeeaccess group manually, however you like. From a list of known emails, or based on the email domain. You can do this in the designer. - If 500 is too many to do manually, and you have straightforward approval rules you can automate this step with Make.
- In a similar way, you could automate the destruction of any account created with an unapproved email, even though they should be harmless.
This setup;
- Deters ransoms from signing up, by making it difficult to find and access
- Prevents them from accessing any gated data anyway, even if they manage to sign up
1 Like
Great, thank you both very much for the advice! I’ll update you on the build.
Hey there!
For anyone looking to do this - here’s a way with Memberstack.
First, create a login form - but no signup form.
Then, you can create a member in Memberstack and give them some temporary password.
You can send them these credentials in any way that works - and, with the invite, advise that they change their password upon logging in.
With this, there is no chance that anyone who is not invited can get in.
You can also import members via CSV 