Password Recover Email Message

Mar 28, 2012 at 12:15 AM

Thank you for the nice FBA Package.

We have a policy were we cannot include the user name and password in the same email message.  Nor can I include the site name/URL in the same message as the user name and/or password.

My first thought was that I could just modify the PasswordRecovery.xslt file at /_layouts/FBA/emails/PasswordRecovery.xslt  and comment out or remove the line(s) of code that generate the Site Name and User Name portions of the email message.

But when I looked at the xslt file, the message contained in that file look different than the message I recieve from my Password Recovery page (a webpart page with the FBA Password Recovery web part on it).

The email message I receive from the Password Recovery web part looks similar to this....
    "Please return to the site and log in using the following information.
     User Name: <UserName>
     Password:  <Password>"

But the xslt file appears to generate an email message that looks more like this...
    "You have requested this mail because you have forgotten your password to <SiteName>.
     Your user name is: <UserName>
     Your temporary password is <Password>
     Your temporary password can be changed immediately by logging onto the Change Password Page using your user name and temporary password.
     The ChangePassword page is located at <ChangePasswordURL>
     Thank you."

Why the difference?  Where can I find the code that produces the email message that I recieve?

Thank you,

Tom

Coordinator
Mar 28, 2012 at 1:42 AM

You should be able to modify PasswordRecovery.xslt to make the desired changes.

First, check the FBA Site Configuration page to ensure that the password recovery template location is pointed to that file.

If that's not it, raise an issue in the issue tracker - I think that the password recovery control that's being used is sending it's own default message out.  With a default SharePoint installation, this should never happen as it doesn't have the mailsettings section in the web.config which is used by the password recovery control to send an email. We expect an error to occur, and when it does we send the email via SharePoint using the template. So check for a mailsettings section existing in your web config. If it does, that's the problem.  Maybe it's there for another component that was installed?

Mar 28, 2012 at 4:59 PM

Thank you for your quick reply.

I did check the FBA Site Configuration page and verified that the password recovery email template is /_layouts/FBA/emails/PasswordRecovery.xslt

We are using SSL.  With SSL enabled, no emails were being sent and and error message was displayed.  Based on information contained in some of the other posts it was suggested to add a mailSettings section to the application's web.config file.  After adding the following to the web.config, emails were able to be sent.

  <system.net>
    <defaultProxy />
    <mailSettings>
      <smtp deliveryMethod="Network" from="email@domain.com">
        <network host="smtp.domain.com" port="25" />
      </smtp>
    </mailSettings>
  </system.net>

 

But now that I think back, without SSL being enabled, FBA pack did send emails and the message content of those emails matched what is in PasswordRecovery.xslt file.  Once SSL was implemented, then emails were not sent.  Adding the mailSettings section to web.config did allow emails to be sent with SSL on, but the content of the messages changed.

So I guess the question then becomes, is there another way to allow the FBA pack to send email messages when SSL is enabled? 

Thank you,

Tom

 

 

Coordinator
Mar 28, 2012 at 5:30 PM

Yes, you have to trust the root of the ssl certificate you are using. Central Admin -> Security -> Manage Trust. There's some discussion in this thread:

http://sharepoint2010fba.codeplex.com/discussions/349372

Apr 2, 2012 at 5:27 PM

Thank you.  Got it working.

I was doing this in a Dev environment using a self-signed certificate.  The self-signed cert was for servername.domain.com.  Added the self-signed certificate to the bindings for the web application in IIS.  Also added the cert to the servers Trusted Root Certificate Authorities.  In SharePoint, I created an AAM to allow the site collection to respond as servername.domain.com.  Finally I created a NEW Managed Trusted named SSL and imported the self-signed certificate there.   After all this, I was able to get the password recovery email to be sent via SSL.  I then updated the PasswordRecovery.xslt email template as needed and verified that email still worked via SSL connection.

Caution! Do NOT mess with the existing managed trusted named local.  This is a SharePoint certifiate for Claims Authentication.  Changing this will break your SharePoint installation.  I know this because I updated the trust local with the ssl certificate and broke SharePoint.  Took me a while but I finally fixed using Certificates MMC, Local Computer, and exporting the SharePoint cetificate and then going back into SP CA > Security > Manage Trust, and updating Local with the SharePoint certificate.

Thanks again for your help.

Tom