Email not working for the FBA Management

Topics: Internet/Extranet Edition
Nov 4, 2007 at 3:53 AM
We have FBA working, signin works, but email password is not working and the new account creation does not email the user.

Anyone else have this issue? Someone mentioned web.config configuration for the email settings and i have tried adding mail settings but i still get the error: "unexpected error has occured." when clicking send. I cannot find any details in the logging or trace (verbose).

Any thoughts?

Nov 4, 2007 at 6:50 PM
We are experiencing the samen problem. Mail is working in the MOSS Server for Alerts etc.
Nov 5, 2007 at 5:20 PM
Same problem here, crying for help now.
Nov 6, 2007 at 9:04 PM
Same problem.

SMTP Server configured at Central Admin, and also at ASP.NET Web site Administration Tool, in the Application Section....

Any other idea?

Hows the email sending suppose to work, just by deploying and installing the features we've download?

Thanks

Luis.
Dec 15, 2007 at 5:22 PM
Edited Dec 15, 2007 at 6:56 PM
I am having the same issue on WSS (wont email newly created user). I tried messing with the web.config files in both the V3 admin site and the target sharepoint site and setting enablePasswordRetrieval to true in any combo between the two web.config files yielded a web site error. I also found that the requiresQuestionAndAnswer="false" set to true turns on security question feature BUT then when you approve a newly created user and hit OK, the user disappears from the list of pending/approved. I get no emails at all from this webpart although I get emails from the Password Reset webpart. Any clues? Maybe I placed some text incorrectly in the web.config files?

enablePasswordRetrieval="false"
enablePasswordReset="true"
requiresQuestionAndAnswer="false"
Dec 17, 2007 at 10:13 PM

bbernicky wrote:
I am having the same issue on WSS (wont email newly created user). I tried messing with the web.config files in both the V3 admin site and the target sharepoint site and setting enablePasswordRetrieval to true in any combo between the two web.config files yielded a web site error. I also found that the requiresQuestionAndAnswer="false" set to true turns on security question feature BUT then when you approve a newly created user and hit OK, the user disappears from the list of pending/approved. I get no emails at all from this webpart although I get emails from the Password Reset webpart. Any clues? Maybe I placed some text incorrectly in the web.config files?

enablePasswordRetrieval="false"
enablePasswordReset="true"
requiresQuestionAndAnswer="false"


Remember that the password reset Web Part does use custom settings in the web.config like this:

<mailSettings>
<smtp from="no-reply@example.com">
<network host="xxx" password="yyy" userName="zz" />
</smtp>
</mailSettings>

While the membership approval feature event receiver uses the default SharePoint outgoing email settings as configured in Central Administration.

My guess is that you either haven't specified an outgoing email server or the server you have entered is not configured to relay your emails to the intended recipient.

I usual test this by installing the SMTP service on my SharePoint box and configure Central Admin to use the local machine to drop the emails. Then I configure the SMTP service to queue all messages so I can see if they are getting dropped by SharePoint.

Try to Google for more information about the SMTP service configuration. It has been pretty well documented over the past 7 years I've been working with it.
Dec 17, 2007 at 10:15 PM


dannyburlage wrote:
We are experiencing the samen problem. Mail is working in the MOSS Server for Alerts etc.


Although it is nowhere mentioned, make sure you have turned

requiresQuestionAndAnswer="false"

to

requiresQuestionAndAnswer="true"

Otherwise the membership approval will not work correctly.
Dec 17, 2007 at 10:50 PM
Got it working today with this in web.config:
<system.net>
<mailSettings>
<smtp from="Admin@sharepoint.com">
<network host="vpc-smoss" port="25" />
</smtp>
</mailSettings>
</system.net>

Here's a couple new questions, however:

1. Is there a way to reduce the complexity of the passwords that get reset? I'm getting passwords like:

eGV*7ROs[WE#qQ
or
=o:F6SH]Msfn_k

I mean, really? I can just hear some poor helpdesk guy trying to read this aloud to a non tech-savvy customer. Or having to spend an extra 10 minutes on the phone having to explain to them how to cut and paste properly (without getting any trailing spaces, of course) just to get them back to a reasonable password.

Which brings me to question 2:
Is there any means for an administrative password change? Not a reset. But for me, as the moss/SQL admin to change a user's password. I've also tried the membershipseeder.zip, but that also requires me to have the current password. So, it would mean administratively changing the FBA user's email address to mine or a temp account to retrieve the horribly commplex password, then changing here.

Thanks
Sandar
Dec 17, 2007 at 11:23 PM
Edited Dec 17, 2007 at 11:38 PM


svanlaan wrote:
Here's a couple new questions, however:

1. Is there a way to reduce the complexity of the passwords that get reset? I'm getting passwords like:

eGV*7ROs[WE#qQ
or
=o:F6SH]Msfn_k

I mean, really? I can just hear some poor helpdesk guy trying to read this aloud to a non tech-savvy customer. Or having to spend an extra 10 minutes on the phone having to explain to them how to cut and paste properly (without getting any trailing spaces, of course) just to get them back to a reasonable password.

Which brings me to question 2:
Is there any means for an administrative password change? Not a reset. But for me, as the moss/SQL admin to change a user's password. I've also tried the membershipseeder.zip, but that also requires me to have the current password. So, it would mean administratively changing the FBA user's email address to mine or a temp account to retrieve the horribly commplex password, then changing here.


Haven't played with it (yet), but you may want to try changing the following settings:

passwordFormat="Clear"
passwordStrengthRegularExpression=""

Changing the password format to clear will cause them to be stored in clear text in the SQLDB and you can easily look them up. I'm not going to start a long winded explanation why clear-text passwords are bad, ok? ;-)

With passwordStrengthRegularExpression you should be able to change the complexity. As I mentioned, I haven't tried that myself (yet) but I can imagine that a proper formatted regular expression could be dropped in here to reduce the complexity.

UPATE: while going through the source code I figured out that the randomly generated password does not make use of the passwordStrengthRegularExpression as of yet. Maybe this might be planned for the future, but right now it appears to not have any effect. As far as I can see the new password is created with the following line of code:

System.Web.Security.Membership.GeneratePassword(System.Web.Security.Membership.MinRequiredPasswordLength, System.Web.Security.Membership.MinRequiredNonAlphanumericCharacters);

So, it looks like it's a feature and not a bug ;-)

Additional word of caution: when changing passwordFormat to "Clear" you are messing up all existing passwords. So be careful and maybe try this on a fresh virtual machine or at least with a clean SQL DB.

Good luck!

Cheers,

Sig
Dec 18, 2007 at 12:48 AM
thx - I do have SMTP working and config in central admin -- I also created an alert on the calendar and it emailed me.

Siegfriedcw wrote:

bbernicky wrote:
I am having the same issue on WSS (wont email newly created user). I tried messing with the web.config files in both the V3 admin site and the target sharepoint site and setting enablePasswordRetrieval to true in any combo between the two web.config files yielded a web site error. I also found that the requiresQuestionAndAnswer="false" set to true turns on security question feature BUT then when you approve a newly created user and hit OK, the user disappears from the list of pending/approved. I get no emails at all from this webpart although I get emails from the Password Reset webpart. Any clues? Maybe I placed some text incorrectly in the web.config files?

enablePasswordRetrieval="false"
enablePasswordReset="true"
requiresQuestionAndAnswer="false"


Remember that the password reset Web Part does use custom settings in the web.config like this:

<mailSettings>
<smtp from="no-reply@example.com">
<network host="xxx" password="yyy" userName="zz" />
</smtp>
</mailSettings>

While the membership approval feature event receiver uses the default SharePoint outgoing email settings as configured in Central Administration.

My guess is that you either haven't specified an outgoing email server or the server you have entered is not configured to relay your emails to the intended recipient.

I usual test this by installing the SMTP service on my SharePoint box and configure Central Admin to use the local machine to drop the emails. Then I configure the SMTP service to queue all messages so I can see if they are getting dropped by SharePoint.

Try to Google for more information about the SMTP service configuration. It has been pretty well documented over the past 7 years I've been working with it.


Dec 18, 2007 at 12:50 AM
Thx again - I did try that but it still doesnt email..also, the entry, when approved in FBA Management, disappears from the list. Maybe this points to another issue.

Siegfriedcw wrote:


dannyburlage wrote:
We are experiencing the samen problem. Mail is working in the MOSS Server for Alerts etc.


Although it is nowhere mentioned, make sure you have turned

requiresQuestionAndAnswer="false"

to

requiresQuestionAndAnswer="true"

Otherwise the membership approval will not work correctly.

Dec 18, 2007 at 1:28 AM
Edited Dec 18, 2007 at 1:29 AM
{quote}
bbernicky wrote:
Thx again - I did try that but it still doesnt email..also, the entry, when approved in FBA Management, disappears from the list. Maybe this points to another issue.
{quote}

Actually, the fact that the items disappears is a good sign :-) It means you do have set requiresQuestionAndAnswer="true". Because when this option is set as soon as you approve a new membership request the item will be deleted from the membership request list and a new user will be added to the SQL database.

So, your only problem seems to be that you cannot get your SharePoint outgoing email working. Can you make sure that you have provided a working SMTP server in the Central Application outgoing email settings? And can you also make sure that things like Alerts are getting send?
Dec 18, 2007 at 5:57 AM
Edited Dec 18, 2007 at 5:58 AM
I do have SMTP working and config in central admin -- I also created an alert on the calendar and it emailed me. Could it be a bad version of the code? I downloaded the wsp on the main page dated in october. Should I be downloading and installing the latest check in - December I believe it is?
{quote}
Siegfriedcw wrote:
{quote}
bbernicky wrote:
Thx again - I did try that but it still doesnt email..also, the entry, when approved in FBA Management, disappears from the list. Maybe this points to another issue.


Actually, the fact that the items disappears is a good sign :-) It means you do have set requiresQuestionAndAnswer="true". Because when this option is set as soon as you approve a new membership request the item will be deleted from the membership request list and a new user will be added to the SQL database.

So, your only problem seems to be that you cannot get your SharePoint outgoing email working. Can you make sure that you have provided a working SMTP server in the Central Application outgoing email settings? And can you also make sure that things like Alerts are getting send?

Dec 18, 2007 at 4:37 PM
Hey Siegfriedcw
Thanks for your prompt reply. Forgive my coding ignorance here, but I don't see

"System.Web.Security.Membership.GeneratePassword(System.Web.Security.Membership.MinRequiredPasswordLength, System.Web.Security.Membership.MinRequiredNonAlphanumericCharacters);"

anywhere in the .aspx pages. Is that something that is in the source code itself and that I would have to see via Visual Studio 2005? (UPDATE: I just tried to open the FBAManagement.wsp in notepad, which was all gobbledyegook, and then Visual Studio 2005, which didn't recognize the file) Would it somehow be possible to alter this behavior by simply removing the second parameter:

System.Web.Security.Membership.MinRequiredNonAlphanumericCharacters

Do you think this would provide a password that had the required length but possibly not the overthetop complexity of the current generated passwords? If so, would this be something I had to remove from the installer code, use stsadm to remove the feature/solution, and then use stsadm to re-deploy it?

Thanks again for your assistance,
Sandar





Siegfriedcw wrote:


svanlaan wrote:
Here's a couple new questions, however:

1. Is there a way to reduce the complexity of the passwords that get reset? I'm getting passwords like:

eGV*7ROs[WE#qQ
or
=o:F6SH]Msfn_k

I mean, really? I can just hear some poor helpdesk guy trying to read this aloud to a non tech-savvy customer. Or having to spend an extra 10 minutes on the phone having to explain to them how to cut and paste properly (without getting any trailing spaces, of course) just to get them back to a reasonable password.

Which brings me to question 2:
Is there any means for an administrative password change? Not a reset. But for me, as the moss/SQL admin to change a user's password. I've also tried the membershipseeder.zip, but that also requires me to have the current password. So, it would mean administratively changing the FBA user's email address to mine or a temp account to retrieve the horribly commplex password, then changing here.


Haven't played with it (yet), but you may want to try changing the following settings:

passwordFormat="Clear"
passwordStrengthRegularExpression=""

Changing the password format to clear will cause them to be stored in clear text in the SQLDB and you can easily look them up. I'm not going to start a long winded explanation why clear-text passwords are bad, ok? ;-)

With passwordStrengthRegularExpression you should be able to change the complexity. As I mentioned, I haven't tried that myself (yet) but I can imagine that a proper formatted regular expression could be dropped in here to reduce the complexity.

UPATE: while going through the source code I figured out that the randomly generated password does not make use of the passwordStrengthRegularExpression as of yet. Maybe this might be planned for the future, but right now it appears to not have any effect. As far as I can see the new password is created with the following line of code:

System.Web.Security.Membership.GeneratePassword(System.Web.Security.Membership.MinRequiredPasswordLength, System.Web.Security.Membership.MinRequiredNonAlphanumericCharacters);

So, it looks like it's a feature and not a bug ;-)

Additional word of caution: when changing passwordFormat to "Clear" you are messing up all existing passwords. So be careful and maybe try this on a fresh virtual machine or at least with a clean SQL DB.

Good luck!

Cheers,

Sig

Dec 18, 2007 at 11:14 PM
Also - this is just WSS 3.0 not MOSS - is that an issue or should it work on both?
{quote}
Siegfriedcw wrote:
{quote}
bbernicky wrote:
Thx again - I did try that but it still doesnt email..also, the entry, when approved in FBA Management, disappears from the list. Maybe this points to another issue.


Actually, the fact that the items disappears is a good sign :-) It means you do have set requiresQuestionAndAnswer="true". Because when this option is set as soon as you approve a new membership request the item will be deleted from the membership request list and a new user will be added to the SQL database.

So, your only problem seems to be that you cannot get your SharePoint outgoing email working. Can you make sure that you have provided a working SMTP server in the Central Application outgoing email settings? And can you also make sure that things like Alerts are getting send?

Dec 19, 2007 at 8:44 PM
It doesn't make any difference if MOSS or WSS. I am working with it on both systems.

{quote}
bbernicky wrote:
Also - this is just WSS 3.0 not MOSS - is that an issue or should it work on both?
{quote}
Dec 19, 2007 at 9:02 PM
Many questions, at least some answers ;-)

1."System.Web.Security.Membership.GeneratePassword(System.Web.Security.Membership.MinRequiredPasswordLength, System.Web.Security.Membership.MinRequiredNonAlphanumericCharacters);" is part of the sourcecode which can be downloaded separately.

2. FBAManagement.wsp is actually a CAB file. If you rename it to FBAManagement.wsp.CAB you can open it with Winzip or similar apps. However, FBAManagement.wsp contains only compiled binary files and some ASPX, XML but not the source code.

3. IMHO, removing System.Web.Security.Membership.MinRequiredNonAlphanumericCharacters will not do the trick. The whole code to create a random password has been build around the ASP.NET 2.0+ GeneratePassword method. I believe you'd need to replace it completely with custom code to control how complex passwords will get, but I might be completely wrong since I haven't looked into that yet.

4. Once you're done with all source code messing and recompilation you have to re-deploy the solution, yes. If you grab the sourcecode you'll find all required CMD files inside a ZIP which will help you to get at least this task done.

FWIW: I am still going through the sourcecode and so far it appears more and more to me being a huge minefield.

So far, I've found simple bugs like sending a "Membership rejected" email even if the membership request is pending. I believe I've also found issues where the sourcecode doesn't actually handle all possible errors appropiately.

And last but not least I believe the emails aren't getting send because there's at least one more error in the membership approval codeblock, which I am tracing down right now.

As for the user disappearing from the membership request list but never show up in SharePoint: this is a major bug in the whole solution and I cannot imagine how this slipped through. The problem is that the current codebase (even the build checked-in on Monday) does not even implement it to create the user in SharePoint but rather only add the user to the SQL membership database. Because of that it is not possible to get user self-registration working at all until this has been fixed by someone.

HTH

Cheers,

Sig Weber

{quote}
svanlaan wrote:
Hey Siegfriedcw
Thanks for your prompt reply. Forgive my coding ignorance here, but I don't see

"System.Web.Security.Membership.GeneratePassword(System.Web.Security.Membership.MinRequiredPasswordLength, System.Web.Security.Membership.MinRequiredNonAlphanumericCharacters);"

anywhere in the .aspx pages. Is that something that is in the source code itself and that I would have to see via Visual Studio 2005? (UPDATE: I just tried to open the FBAManagement.wsp in notepad, which was all gobbledyegook, and then Visual Studio 2005, which didn't recognize the file) Would it somehow be possible to alter this behavior by simply removing the second parameter:

System.Web.Security.Membership.MinRequiredNonAlphanumericCharacters

Do you think this would provide a password that had the required length but possibly not the overthetop complexity of the current generated passwords? If so, would this be something I had to remove from the installer code, use stsadm to remove the feature/solution, and then use stsadm to re-deploy it?

Thanks again for your assistance,
Sandar
Dec 19, 2007 at 11:28 PM
Thanks Sig for the enlightenment! This makes sense. I also only have FBA Membership Request Management and FBA User Management under Site Actions > Site Settings. Was playing and found a _layouts/FBA/Management/rolesDisp.aspx file which wasnt listed under Site Settings. Now the _layouts/FBA/Management/usersDisp.aspx is nice but when the password secret is turned on, you cannot add a user from the new user link on this page. If you turn off password secret in the web.config then this works nicely as a method for entering users via a webpage. You do have to create a password though.

I can only see using membership right now to allow a user to get their account setup, taking us out of the account creation process (truly the most annoying for most IT folks next to please power cycle your equipment). Then we can add a user under people and groups into a sharepoint group manually to allow more than visitor rights (which it seems all that the newly created member gets is read only access - same as anonymous. Cool thing is we at least gather emails of people interested in our site. not to create spam of course). We can always email them that they are not approved for access to a group from the group screen. I think I will create a web page to expose the sql users to an admin allowing the admin to then add the users to a sharepoint group. After this is all fixed with the code I will then revisit the process of adding and admin the site.

As for now - all other features of this code work well enough for me to put it into a semi-workable site for some of my users to toy with. Now I gotta get that .dll to work from the FormsBasciAuth so I can have some Microsoft integration. ;-)

{quote}
Siegfriedcw wrote:
Many questions, at least some answers ;-)

1."System.Web.Security.Membership.GeneratePassword(System.Web.Security.Membership.MinRequiredPasswordLength, System.Web.Security.Membership.MinRequiredNonAlphanumericCharacters);" is part of the sourcecode which can be downloaded separately.

2. FBAManagement.wsp is actually a CAB file. If you rename it to FBAManagement.wsp.CAB you can open it with Winzip or similar apps. However, FBAManagement.wsp contains only compiled binary files and some ASPX, XML but not the source code.

3. IMHO, removing System.Web.Security.Membership.MinRequiredNonAlphanumericCharacters will not do the trick. The whole code to create a random password has been build around the ASP.NET 2.0+ GeneratePassword method. I believe you'd need to replace it completely with custom code to control how complex passwords will get, but I might be completely wrong since I haven't looked into that yet.

4. Once you're done with all source code messing and recompilation you have to re-deploy the solution, yes. If you grab the sourcecode you'll find all required CMD files inside a ZIP which will help you to get at least this task done.

FWIW: I am still going through the sourcecode and so far it appears more and more to me being a huge minefield.

So far, I've found simple bugs like sending a "Membership rejected" email even if the membership request is pending. I believe I've also found issues where the sourcecode doesn't actually handle all possible errors appropiately.

And last but not least I believe the emails aren't getting send because there's at least one more error in the membership approval codeblock, which I am tracing down right now.

As for the user disappearing from the membership request list but never show up in SharePoint: this is a major bug in the whole solution and I cannot imagine how this slipped through. The problem is that the current codebase (even the build checked-in on Monday) does not even implement it to create the user in SharePoint but rather only add the user to the SQL membership database. Because of that it is not possible to get user self-registration working at all until this has been fixed by someone.

HTH

Cheers,

Sig Weber


svanlaan wrote:
Hey Siegfriedcw
Thanks for your prompt reply. Forgive my coding ignorance here, but I don't see

"System.Web.Security.Membership.GeneratePassword(System.Web.Security.Membership.MinRequiredPasswordLength, System.Web.Security.Membership.MinRequiredNonAlphanumericCharacters);"

anywhere in the .aspx pages. Is that something that is in the source code itself and that I would have to see via Visual Studio 2005? (UPDATE: I just tried to open the FBAManagement.wsp in notepad, which was all gobbledyegook, and then Visual Studio 2005, which didn't recognize the file) Would it somehow be possible to alter this behavior by simply removing the second parameter:

System.Web.Security.Membership.MinRequiredNonAlphanumericCharacters

Do you think this would provide a password that had the required length but possibly not the overthetop complexity of the current generated passwords? If so, would this be something I had to remove from the installer code, use stsadm to remove the feature/solution, and then use stsadm to re-deploy it?

Thanks again for your assistance,
Sandar


Dec 20, 2007 at 12:53 AM

I also only have FBA Membership Request Management and FBA User Management under Site Actions > Site Settings.


Sounds like you didn't install the latest build from the sourcecode tree. The very latest builds include an import feature. On my testmachine I couldn't make it work at all, but if manage to get it working it at least offers a way to copy the users from the SQL DB into SharePoint groups. Still one manually step too much for us but better than nothing ;-)


Was playing and found a _layouts/FBA/Management/rolesDisp.aspx file which wasnt listed under Site Settings.


That's weird. I do have an FBA Role Management feature which, once activated, puts a new item on the Site Settings page called "FBA Role Management". It offers a way to manage SQL DB roles. Those are a totally different beast and not related to SharePoint groups. Hence we turned it off and prefer to use SharePoint groups (which irons out another bug with SQL roles <g>).


Now the _layouts/FBA/Management/usersDisp.aspx is nice but when the password secret is turned on, you cannot add a user from the new user link on this page.
If you turn off password secret in the web.config then this works nicely as a method for entering users via a webpage.


Yep, ran into this bug too. Hence I keep the passwort secret question & answer off for now (no time to fix that until tomorrow).


I can only see using membership right now to allow a user to get their account setup, taking us out of the account creation process (truly the most annoying for most IT folks next to please power cycle your equipment).


Indeed. I hear you loud and clear.


Then we can add a user under people and groups into a sharepoint group manually to allow more than visitor rights (which it seems all that the newly created member gets is read only access - same as anonymous.


See above. If you manage to get that import feature working at least this process gets a little bit easier.


I think I will create a web page to expose the sql users to an admin allowing the admin to then add the users to a sharepoint group.


Again, the import feature does exactly that.


Now I gotta get that .dll to work from the FormsBasciAuth so I can have some Microsoft integration. ;-)


Good luck!

Cheers,

Sig Weber
Jan 30, 2008 at 4:45 PM
Hello all

Just did a post about my experience implementing the Forms-Based Auth solution from here at Codeplex. Thought it might benefit the community. You can check it out here:
http://vanlaan.typepad.com/vanlaanon_sharepoint/2007/12/iie-forms-based.html

Also did a post on configuring the dual-auth web apps in Sharepoint here:
http://vanlaan.typepad.com/vanlaanon_sharepoint/2007/12/dual-authentica.html

Hope this helps,
Sandar Van Laan
Jan 30, 2008 at 5:37 PM
Edited Jan 30, 2008 at 8:17 PM
The correct urls are: http://vanlaan.typepad.com/vanlaanonsharepoint/2007/12/iie-forms-based.html and http://vanlaan.typepad.com/vanlaanonsharepoint/2007/12/dual-authentica.html
Update, the wiki isn't working as expected. http://vanlaan.typepad.com/vanlaanon_sharepoint/2007/12/iie-forms-based.html needs to be http://vanlaan.typepad.com/van _ laan _ on _ sharepoint/2007/12/iie-forms-based.html
Feb 6, 2008 at 3:34 AM
Use the source code from http://www.codeplex.com/CKS/SourceControl/ListDownloadableCommits.aspx as it works very well and is updated from the Oct 2007 code. The email works great with this code. Seems to only work with the spadmin user though even though I tried granting other users sitewide admin and FBA admin role rights.
Feb 7, 2008 at 7:28 AM
email should work now. Use the latest source code it's a huge improvement!
Feb 8, 2008 at 2:57 AM
Figured out that users must be added as site collection admins under site settings for the FBA items to show in site settings as well as email upon membership approval to work. Very nice!!


bbernicky wrote:
Use the source code from http://www.codeplex.com/CKS/SourceControl/ListDownloadableCommits.aspx as it works very well and is updated from the Oct 2007 code. The email works great with this code. Seems to only work with the spadmin user though even though I tried granting other users sitewide admin and FBA admin role rights.

Feb 8, 2008 at 8:48 AM
Hello all and let me start by saying thank you to all who are participating in this.
I do have a question though.

I have the latest source code "9518".

I can: login, change password and retreive password
Also when the Forms Based Authentication Site Membership Review List feature is ACTIVATED, I can sign up using the Membership Request Web Part.

I can Not sign up using the Membership Request Web Part when the Forms Based Authentication Site Membership Review List feature is DEACTIVATED.
I get the error "The parameter name cannot be empty or bigger than 255 characters. "

I thought I read that if the Forms Based Authentication Site Membership Review List feature is DEACTIVATED, then the membership request webpart would just bypass the review list and approval process and email the temp password to user so they can log in.

Please let me know if I have misunderstood or have not configured something properly. Thank You
Feb 8, 2008 at 8:48 AM
Edited Feb 8, 2008 at 8:51 AM
.
Feb 8, 2008 at 8:48 AM
Edited Feb 8, 2008 at 8:52 AM
sorry for the extra 2 posts... for some reason, the above question posted three times
Mar 10, 2008 at 9:15 PM
I downloaded the lastest source code, and deployed it. I am still unable to have users sign up via the Request Access web part. No email will be sent to the users.

I know email is working, I set up alerts so whenever the Request Access List gets updated I get an email, but the users never get emailed once they are approved.

Also, is there any way to The FBA roles to a sharepoint group?
Mar 11, 2008 at 8:18 AM
I have the same problem. Mail ist working but the user password will not be send out.
Mar 11, 2008 at 8:26 AM
sorry my browser went down
Apr 2, 2008 at 6:50 AM
I learned some interesting things about the FBA approval.

1. Once the user request access, the user can go to the recover password web part (if it is available) and recover their password. I've found that upon using the recover password web part the password always receives the password in the email. (You must have put the mailsettings element and its sub elements into the web.config file of the extranet or fba provider site). This is true without having had any approval from the FBA Membership Request Management!

2. If the user has recovered their password, they receive a long and ugly strong password. They can reset the password by cutting and pasting it in the change password web part along with their new password and verifying their new password. This is true without having had any approval from the FBA Membership Request Management!

3. If the user is clever and peform the steps above, they can log in but do not have any real permissions.

4. The FBA Membership Request Management and other items are not visible unless the user is a site collection administrator. (This was mentioned above, but I found it out the hard way)

5. I made sure to have a site collection administrator that is authenticated by the fba.

6. If I approved a FBA Membership request in the FBA Membership Request Managment (also displayed as Site Membership Review List once you are in the page) using a site collection account that uses the FBA membership provider, that user gets an email with the password.

7. If I approved a FBA Membership request in the FBA Membership Request Managment (also displayed as Site Membership Review List once you are in the page) using a site collection account that uses the Windows authentication type that user does not get any email, but does get permissions defaulted from the request web part (at the very top of the edit screen for the web part).

8. I cannot view the FBA User Management screen (I get an error page when I click on the link) if I'm using my Windows authenticated site collection administrator account.

9. I can view the FBA User Management screen using the Windows authenticated site collection administrator if I add the connection string, fbamember and fbarole elements to the web.config file of the extended web application that uses the windows authentication type. The elements would be the same that you put in the FBA web.config file as described in the walkthrough.

10. The passwords that were sent to the users (after approval) had 7 characters, the number characters that the recover password sends out seemed to be maybe 12 characters or more (just a guess on the 12 characters, I didn't count because it was so long). I change my member provider to 7 characters defined in it like so minRequiredPasswordLength="7" , I'm not sure if this is what did it because I didn't test it, but I'm just taking it for granted to set the minRequired characters to 7 yeilds a 7 char password from the email after being approved. I'm to tired to test this and I have other puzzles to figure out. here it is in full --

add connectionStringName="AspNetDbFBAConnectionString2" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="true" applicationName="/" requiresUniqueEmail="true" passwordFormat="Hashed" maxInvalidPasswordAttempts="5" minRequiredPasswordLength="7" minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10" passwordStrengthRegularExpression="" name="FBAMember2" type="System.Web.Security.SqlMembershipProvider,System.Web,Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a"

11. It almost seems that the email elements attributes and contents that one places in the web.config files are meaningless and that the email information is retreived from the "web application outgoing email settings" for the extranet web application. I put in totally incorrect information in the web.config files and it still sent the email using the web application outgoing email settings.

12. If the user alert for the FBA Membership Request Management screen was set while in the FBA application side, the alert will link the user to the FBA application side of the FBA Membership Request Management screen even if the user is a Windows Authenticated alert reciepient.

13. If the user alert for the FBA Membership Request Management screen was set while in the extended application side (Windows authentication type), the alert will link the user to the extended application side of the FBA Membership Request Management screen.


And here is my problem. I want my active directory user to approve FBA users requests using their active directory account, they can approve them but no email is sent off to the user if the windows authenticated user approves it. I think that I need to include a member provider for my FBA somewhere where the "Web application outgoing email settings" are set. This is set in the central admin, application page. Does anyone know where these settings end up? Do they end up in the database or some config file somewhere? If so please let me know, I'm going crazy with this. (And I kow that I can have the active directory user just use a fba user ( for a site collection administrator) to approve requests, so please don't suggest this because I don't want to do this ;-)

Anyhow, to breifly summarize my setup I used Anonymous access for the FBA login, request, recovery and pw change. I used then created a site below these site collection sites and disable Anonymous access.



Hopefully not to long and someone has a suggestion for me.

Thanks,
Jimmy


Aug 15, 2008 at 4:47 PM
Aug 15, 2008 at 4:50 PM
Edited Aug 15, 2008 at 7:19 PM
Thanks Jimmy, because you made tests I didn't think to make, and that helps me a lot ! Your n. 6, mainly, because, like you, I want the requests to be approved by an administrator logged in with AD account, and it didn't come to my mind to test with a FBA administrator.
But in this situation, I don't see any solution for us.  :o/

And you're right, <mailSettings> in web.config doesn't seem useful. I don't use it, and emails are well sent, for pending and aproved (with FBA admin) status as well as for password reset.

For information, I used the changed set 15235 of the source code, which corrects the error message I had when accessing the user management page with an installation in a foreign language.

Thanks all for the work !