Reset password on login page before user authenticates

Yes, this is the Password Recovery Web Part.  Yep, the user definitely exists and emails works from everywhere except this.  I'm running 1.2.0.  Hmm....

http://screencast.com/t/VlzRFIogt

 

Maybe this is a XSLT access issue instead?

 

12/08/2011 11:18:59.23 w3wp.exe (0x132C)                       0x129C SharePoint Foundation         E-Mail                         8gsf High     #160009: The e-mail address 'jordan.shane@gmail.com' is unknown. c4eff796-afed-4994-83c5-9a7f998609f712/08/2011 11:18:59.23 w3wp.exe (0x132C)                       0x129C SharePoint Foundation         General                       8kh7 High     Cannot complete this action.  Please try again. c4eff796-afed-4994-83c5-9a7f998609f712/08/2011 11:18:59.23 w3wp.exe (0x132C)                       0x129C SharePoint Foundation         General                       b9y3 High     Failed to open the file 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Resources\FBAPackPasswordRecoveryWebPart.en-US.resx'. c4eff796-afed-4994-83c5-9a7f998609f712/08/2011 11:18:59.23 w3wp.exe (0x132C)                       0x129C SharePoint Foundation         General                       b9y4 High     #20015: Cannot open "": no such file or folder. c4eff796-afed-4994-83c5-9a7f998609f712/08/2011 11:18:59.23 w3wp.exe (0x132C)                       0x129C SharePoint Foundation         General                       b9y4 High     (#2: Cannot open "": no such file or folder.) c4eff796-afed-4994-83c5-9a7f998609f7

You're right - with the full error message, it does look like the error message is coming back from the smtp server.  When you say the email works with the other web parts - does it work with this email address? I'm just wondering if relaying or something like that isn't configured properly on the smtp server (though if it were relaying i'd expect a 'cannot relay' message).  Maybe try removing this account and re-registering this email address with the membership request web part.

I'm seeing the same error message as well.  I dug into it a bit further and found that it works as expected for email addresses in my domain (test@mydomain.com), but throws the above error for email addresses outside of my domian (test@gmail.com)  I have asked our Exchange Administrator to review the relay settings to ensure it is configured to properly relay external emails.  I will post our findings when he gets back to me.

I didn't feel like it was the email server since it works everywhere else:  SharePoint Alerts, FBA New User Create feature, etc.  Only the forget password webpart was having issues.  I ended up just writing my own that did a postback and it worked fine.  I'm still not sure what the issue was.

You ended up just writing your own... Web Part?  Instead of using the provided one?

Yes, just a simple web part that did the same functionality.  Unfortunately it just didn't work for me.  Still not sure why.  The rest of the features worked great.

John, are you only having this error on the password recovery web part as well? Or do you also get an error with the membership request web part?

Yes, it only seems to occur on the password recovery web part.  Alerts, workflow, and other SharePoint emails are being sent to outside accounts.

Hi,

I had been experiencing the same problems as those faced by Jordan & John. During investigation I discovered the issue to be happening at the point the system tries to use the SharePoint object model to send an email - the password reset had already happened which was confirmed by monitoring the SQL tables in the aspnet database to see if the (encrypted) passwords had changed.

The workaround for me was to simply enable anonymous access to the claims authentication provider for the web in Site Collection Administration. Unless any further anonymous access is granted this still ensures the safety of your SharePoint sites from anon users.

Perhaps a suggested enhancement in a future release if this is a common problem might be to allow emails to be sent via the standard .NET object model rather than use the SP.SendEmail [sic] method. I realise this would require further configuration for the end user but there may be times where this is required.

Many thanks to the developers of this solution though, it's very, very good.

I think you hit the nail on the head Tobias. Thank you very much.

Usually when i'm testing, i'm either accessing as anonymous, or i'm logged in as a different user than the one that i'm recovering. (The web part really is meant to run as anonymous, because if you're logged in, obviously you don't need to recover your password).  I think if you're logged in and recover your own password, you'll essentially be logged out of SharePoint and no longer be able to send the email.  I'll update the code in the next release to elevate privileges before sending the email, which should fix this issue. I've raise the issue here:

http://sharepoint2010fba.codeplex.com/workitem/683

In the meantime, the work around is to run the web part anonymously.

Of course, running the sendemail code with elevated privileges is a much simpler solution than messing around with other email configurations-much better idea.

Glad it's helped...look forward to future releases.

Tobias.

On 5 Jan 2012, at 23:18, "ccoulson" <notifications@codeplex.com> wrote:

From: ccoulson

I think you hit the nail on the head Tobias. Thank you very much.

Usually when i'm testing, i'm either accessing as anonymous, or i'm logged in as a different user than the one that i'm recovering. (The web part really is meant to run as anonymous, because if you're logged in, obviously you don't need to recover your password). I think if you're logged in and recover your own password, you'll essentially be logged out of SharePoint and no longer be able to send the email. I'll update the code in the next release to elevate privileges before sending the email, which should fix this issue. I've raise the issue here:

http://sharepoint2010fba.codeplex.com/workitem/683

In the meantime, the work around is to run the web part anonymously.

Hi,

Sorry to reopen an old post, just bored of banging my head against a brick wall now.

I've created the anonymous access page as outlined above, and I only installed the pack about 3 weeks ago, so I assume it has the updates you mention.

On this page that I've deployed, and activated, I can now access it without having to login, and have the password recovery control on it, and that's working as expected.

I also have the membership request control on, and while it appears to run on the page, as soon as I go to submit, it seems to do something then redirects me to the login page. (Copied below incase anyone can see whats happening)

http://admin-pc:16132/_login/default.aspx?ReturnUrl=%2f_layouts%2fAuthenticate.aspx%3fSource%3d%252F%255Flayouts%252FSharePointProject3%252FPasswordRecovery%252Easpx&Source=%2F%5Flayouts%2FSharePointProject3%2FPasswordRecovery%2Easpx

No user is added to the database, in an unapproved state so I'm not sure what I'm doing wrong.

This is what I have in the content bit of the page:

<FBA:PasswordRecoveryWebPart runat="server"  />
<h1>User Registration</h1>
<FBA:MembershipRequestWebPart runat="server"  />

As you can see, it's very basic, out of the box, password recovery works, membership request doesn't. Do I need some sort of template in my membership request control?

Thanks in advance!

It sounds like SharePoint is catching one of the operations that's happening behind the scenes as needing authentication, so it's redirecting you to the login page. Try changing the Site Collection's anonymous access settings to Lists and Libraries:

 Go to ‘Site Settings’, ‘Site Permissions’. Click on ‘Anonymous Access’. From the ‘Anonymous users can access: ‘ dialog, choose ‘Lists and Libraries’ and click OK. 

This will still keep the site secured to members only, unless you specifically enable anonymous access for lists and libraries. 

This has worked for me in the past, when there were issues loading the xslt templates and no anonymous permission on the site.  Since your password recovery control is working, i'm not sure this will fix it for you - but something to try.

Great, Cheers Chris,

Sorry for the late reply, got taken off the project to work on something else.

Setting the 'List and Libraries' to anonymous solved the problem.

I was then getting 'Unknown error' on submission but after looking round the discussions, worked out it was an email issue. Downloaded smtp4dev (http://smtp4dev.codeplex.com/) as I'm on a Win 7 machine, which provides a useful smtp service and has solved all, membership is now working!

Thanks Again,
Bav 

 1

Do you get the warning if the file is closed when you compile? I find that Visual Studio will generate a lots of warnings for tags and other issues it doesn't recognize when the file is open.

Hi Guys,

I am facing the same problem of Redirection as everyone mentioned over here. for this I have used following tricks
1)creating Standard sharePoint page and making anonymous access to page
2)also use creating Application Page with making anonymous access to page using UnsecuredLayoutsPageBase class and set AllowAnonymousAccess and AllowNullWeb to true.
yet my page Redirects to same Login page.

for this now I hv decided to Deploy Latest FBA pack with version 1.3.1 but problem is that i hv already user created in SharePoint and corresponding Database also. so what wl happen with existing users if i wl deploy new FBA pack. will there be existing users as it is or everything wl go??
Kindly Help me in this regards

Regards,
Sachin
Deploying over the FBA Pack will just update the FBA Pack. It won't affect any existing users on the system. (It's just management tools/web parts on top of your existing SharePoint FBA setup, so it doesn't touch the users/membership setup at all during deployment).
with the help of latest FBA pack, can i solve my problem of redirection to application page or is there any another alternative.
kindly let me know in this concerns
Sorry, I missed your earlier mention of redirecting to the same login page. It will redirect to the same login page if the person logging in doesn't have access to all or part of the page that they're being redirected to. So I think it really has to do with the permissions of the person logging in. Try giving them site collection admin privileges and I bet they'll be able to login.

Then you'll just have to find what's causing the redirect. Fiddler is usually a good tool to determine what's causing it, as you can see the last item that was requested before the user was redirected back to the login page.

I've found that with publishing sites, I may not have published an image used in the master page - which causes everybody but admins to be redirected.