U4-3385 - Find a better solution for approving members

Created by Sebastiaan Janssen 05 Nov 2013, 12:19:30 Updated by Sebastiaan Janssen 05 Jun 2015, 16:28:23

Had to comment out approval as it was always on for all member types, it should not be on by default. See rev c19a8fa602f062c76197b27cb9b29635c186197a


Shannon Deminick 07 Nov 2013, 00:09:36

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

Shannon Deminick 07 Nov 2013, 00:14:26

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

Shannon Deminick 19 Nov 2013, 07:28:16

@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?

Sebastiaan Janssen 19 Nov 2013, 12:53:20

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.

Shannon Deminick 19 Nov 2013, 21:54:12

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.

Sebastiaan Janssen 19 Nov 2013, 23:04:56

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.

Shannon Deminick 19 Nov 2013, 23:07:14

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.

Sebastiaan Janssen 19 Nov 2013, 23:44:33

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.

Shannon Deminick 19 Nov 2013, 23:46:19

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

Shannon Deminick 20 Nov 2013, 04:12:28

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!

Sebastiaan Janssen 20 Nov 2013, 14:25:02

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?

Shannon Deminick 21 Nov 2013, 01:19:34

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.

Priority: Normal

Type: Bug

State: Fixed


Difficulty: Normal


Backwards Compatible: True

Fix Submitted:

Affected versions: 7.0.0, 6.2.0

Due in version: 7.0.0, 6.2.0


Story Points: