U4-3385 - Find a better solution for approving members

You'll need to back port this to 6.2 as well

I'm assuming this just means that by default members are not approved when creating them ?

@Sebastian - in v7 now when you create a user the approval depends on whether you check the approval box. Is that what you are referring to here?

Yes. So members should be approved immediately unless otherwise specified. I debugged for ages before I figured out why I couldn't log in with my newly created member account.

That's what I don't understand, the original code always approved a member by default, the code you changed means that approval status is never checked when logging in.

Now when creating a member it will just set their approval status to whatever you set in the check box.

Well, then I don't understand either because when I tested this, the member was never approved by default. :-) Let's revisit this for the next version, currently it seems to work as intended: a newly created member doesn't have to be somehow manually approved before being allowed to log in.

When you tested this, you created the member via the back office? of from the front-end somehow? If you don't select the approved check box in the back office it won't be approved when you create it.

Frontend. There's razor templates for partials/macropartials. They use the "old" member API, which had the behavior of not having to approve members before you could log in with their new accounts.

right, just needed to know that bit of info :) will make sure they are approved by default in that case.

Ah i see what is going on.

We should update these templates to use the membership provider really. A large problem with the old API is that it is responsible for encrypting/hashing the password - but it only performs this one way which means that any of the password settings you set in the membership provider get completely ignored. So if i want to encrypt my passwords instead of hashing them or want to change the algorithm in the config, this doesn't respect that whatsoever.

Anyways, that is just one of the dozens of fixes in the membership providers in 6.2 and 7.0.

So the reason this problem is happening is because it is using the old api to create the member which is not checking to see if there's an approved property configured for the entity and then not setting it to true (all happening outside the membership provider).

I've fixed this in rev: 596cf2a9e184fe9966dc96daa9d37a980288af39

• it uses events on the legacy API to auto-approve any member created with that API if the umbraco membership provider is enabled and if an approval property is specified.

Would be really great if you could double test this for me!

So: This works now, except in the backoffice when you create a new member you HAVE to set the Approved checkbox to true in order to be able to login. Whereas when you create a member from the frontend with the register snippet / old API the member shows as not approved in the backoffice yet they're able to login.

So I'm wondering: where do we configure that a member should be approved before they can login?

This is all fixed now.

Turns out my event handler wasn't firing so approved wasn't being set to true. What happens now is that if you create a member with the legacy api, they will be automatically approved (if they have an approved property, if they don't then the provider doesn't check for that anyways). In the UI, we set the approved check box to be selected when creating a new member.

So basically members by default will always be approved when creating them - but currently the internal MemberService doesn't do this but it can't be used publicly yet and isn't complete.