Extendig SqlMembershipprovider

[ManniAT]

Hi,

SqlMembershipProvider does (allmost) what I want.
So I'm not willing to write my own provider.

But I want to change some little things.
a.) I want to be able to add an "Email-OptIn feature"
so the user should get an email with a link "Click here to activate your account"
b.) I want enhance the above thing to a "Managed OptIn Feature"
so the email goes first to an admin
he either chooses to negotiate or to accept the user by redirecting the mail to him

Until the user didn't click on that "verification link" the account should not be able to login.

Can this be done without writing my own provider, and using the existing controls?

Cheers

Manfred

[Brock]

> a.) I want to be able to add an "Email-OptIn feature" 

So you can set the DisableCreatedUser=true for your CreateUserWizard control.
This way when the user account si crated, it's initially diasbled. Also handle
the CreatedUser event to send an email with the link or URL they must click
to activate the account.
 

Again, this is just logic in your Createduser event that decided who to send
the email to and updates your workflow as appropriate.

-Brock
DevelopMentor
http://staff.develop.com/ballen

[ManniAT]

Hi Brock,

thank you for your reply. I solved it 2 days ago in the way you suggested.
Maybe anybody else will also have such a "problem" so I will tell a short how to.
After digging in the things I found that it is pretty easy to to such a thing.

I tell the wizard not to activate the user (as you wrote).
I handle the "CreatedUser" event. There I made a GUID and use a part of if as
some kind of "activaton string". I store this in User.Comment.
And I send a mail to the user.with a link to the activation page.
Furtheron I solved another thing here - a "default role membership".

Than I made a page ("ActivateUser") where I load the user, check if
the passsed "ID" fits the comment - and if so I set User.IsApproved to true.

The only tricky thing (I found no other way than this) is to have an email after
resetting the password. Since the PWD is not readable I could only parse it somehow
from the e.Message.body in the "SendingMail" event. This seems a little unsave,
since the format of the message can change.
So I do another ResetPWD to get the new for my mail message.
With that approach I have also the ability to enforce another "activation" step again.

The things were pretty easy - after finding out where to intercept the system :-)

Cheers

Manfred