U4-4653 - MembershipHelper RegisterMember does not set password and ignores logMemberIn

Created by Marcel Hogenstein 09 Apr 2014, 11:53:21 Updated by Bilal Isa 10 Nov 2014, 21:59:38

I've been playing with the new Membership functionality in v7.1.0 and v7.1.1 and i found two issues in the RegisterMember on the MembershipHelper:

  1. The password is not set on a member. This becomes obvious when you view the new created member in the backend: the password fields aren't set and are required before any other property can be saved.
  2. The logMemberIn boolean in the function call, as wel as in the RegisterModel are ignored. The FormsAuthentication.SetAuthCookie is called in the last line. Also this methods reminds the user for the next time automatically. This should be avoided I guess.

The first issue can be worked around by setting the password explicitly by calling the ChangePassword method on the MembershipHelper. This might be related to U4-4600 and U4-4454 The second issue is more annoying, when two-step authentication (where the emailaddress is validated prior to approving a member) is required.


Sebastiaan Janssen 09 Apr 2014, 12:08:51

  1. yes, you need to set the password using ChangePassword.
  2. Okay, we'll look into it. You can just log them out now as a workaround and do a "proper" login the way you want it to happen. Remember you can also use default ASP.NET membershipprovider code and avoid our helpers completely.

Marcel Hogenstein 09 Apr 2014, 12:23:12

I do remember that, but I just liked the approach of having a MembershipHelper available. Looks like a valuable piece of code when I looked into it on GitHub. T

  1. The RegisterMember just forwards the call to create the member to the PerformCreateUser, where the memberTypeAlias is a string. The overload of CreateWithIdentity on the MemberService with a memberTypeAlias as a string is not redirect to the right overload and therefore the password is ignored on RegisterMember (or this CreateWithIdentity overload anyway).

  2. I guess a call to FormsAuthentication.SignOut(); will do here as a workaround.

Marcel Hogenstein 09 Apr 2014, 12:48:24

Coming to think of it, 1) might just have worked in the 7.1.0RC as I can't remember I ran in to this issue.

Shannon Deminick 14 Apr 2014, 09:03:30

Will look into this, just for my own notes, see note on this commit: https://github.com/umbraco/Umbraco-CMS/commit/53c0bd6938f345ad9f1cd8892af3ae83553e1d94#commitcomment-5997281

Shannon Deminick 22 Apr 2014, 08:49:14

Have tested with the legacy provider and it works as expected, having an issue with the new provider which leads me to believe there's a small error in the provider or new api for handling password persistence, will fix up.

Shannon Deminick 22 Apr 2014, 09:02:06

All fixed in rev: a92c2321789cd7b553d2cc9351880825e3da22a8 will merge into 7.1.2

Have added another flag to the register model so you can decide if you want the cookie to be persistent or not (default is true).

Bilal Isa 10 Nov 2014, 21:59:38

I want to take the liberty of re-opening this issue.

As I understand from reading the last comment made by Shannon the bug was fixed in connection with merge to 7.1.2. When I look here https://github.com/Umbraco/Umbraco-CMS/commit/a92c2321789cd7b553d2cc9351880825e3da22a8 it looks like RegisterMember is still signing the member in

public MembershipUser RegisterMember(RegisterModel model, out MembershipCreateStatus, bool logMemberIn = true)

the only difference is that it's now creating a persistent cookie - I might be wrong or misunderstanding the issue. I'm running Umbraco version 7.1.8 and I'm using Membership Helper in surface controller in the following way

var member = Members.RegisterMember(registerModel, out status, registerModel.LoginOnSuccess);

but I'm always getting signed in.

I even tried

var member = Members.RegisterMember(registerModel, out status, false);

with the same result.

Thanks in advance.

Best, Bilal

Priority: Normal

Type: Bug

State: Fixed

Assignee: Shannon Deminick

Difficulty: Normal


Backwards Compatible: True

Fix Submitted:

Affected versions: 7.1.0, 7.1.1

Due in version: 6.2.0, 7.1.2


Story Points: