Hi Kris

I'd like to point out that a SurfaceController exposes both:

a) The membership helper (Members) which is handy for basic web security stuff such as authentication, retrieval of the current logged in member, profile/login status, etc.

b) The member service (Services.MemberService) which is the new API for member management

For advanced stuff like registration, updating member profiles, complex querying etc. I think you should be able to replace the deprecated API calls using the member service instead.

Grtz

L

Hi Lennart,

Thanks for the feedback. After more late night digging I came to roughly the same conclusions. For the sake of being informative:

1. SurfaceController indeed exposes MembershipHelper as Members where you can do things such as Members.GetByEmail(string Email)

   which in turn returns your member as IPublishedContent. However, as far as I can tell this is readonly

2. If you want to do stuff with your member (update it), the above cannot be used and so I ended up doing things like this:

 var membershipService = ApplicationContext.Current.Services.MemberService;

 var checkMember = membershipService.GetByEmail(model.EmailAddress);

 checkMember.Properties["numberOfLogins"].Value = noLogins + 1;

So I think the above allows me to update the original code by Warren B. (which I think offers some very nice functionality) to use the new APIs. So far so good...

However, now I have run into another issue: I have forked Warrens solution here. When I compile the binary, place the dll in \bin and the folders AuthSurface and ProfileSurface in \Views, everything seems to work, i.e. the views render by e.g. calling @Html.Action("RenderEditProfile", "ProfileSurface") but when I actually try to submit updated info from that form, I get a YSOD claiming:

Could not find a Surface controller route in the RouteTable for controller name ProfileSurface

Which is very odd since ProfileController.cs ActionResult RenderEditProfile() ends with a call to return PartialView("EditProfile", profileModel); just like HandlesEditProfile does... If the views are found the first time around (for rendering the form, how come the route seems to fail after submitting?

Making this even more difficult is the fact that it is tough to debug this sort of thing (routing that is)...

Any thoughts?

A small update on this: I managed to install glimpse on my site and I did some checking: the proper routes seem to be in place:

And yet, pulling up the EditProfile page:

and submitting yields YSOD:

More info:

Since the routes seem to be in place I tried to access the views directly:

mydomain.com/umbraco/Surface/AuthSurface/RenderLogin

Which also seems to work... locally as well as remotely...

Hey Kris,

I am looking for an updated version of Warren's solution as well. Did you get very far with this?

Robert

is working on a reply...