Hello - First let me say thank you for this great pack of controls. I am using the latest version at this time (1.0.3) and have scoured your forums here and your blog. I have everything working after using this blog to get FBA "Mixed Mode" to allow
anonymous and secure content based on inheritance. That post is at:
http://blogs.visigo.com/chriscoulson/mixed-anonymous-and-secure-content-with-sharepoint-2010/.
Everything works EXCEPT I cannot figure out how to show the "Change Password" control even though the page is anonymous. It does not throw any errors, it just shows the title and then the web part is blank. This has hosed two FBA accounts, as when users
click the link in my email with the temp password, they try to log in after not seeing the web part and then they enter the temp password, THEN it throws an error and the account becomes locked/useless. Any insight into why this is happening given the version
and setup I have decsribed would be most helpful. Thanks!
Currently the Change Password control is set to not display if a user is not logged in (If they're not logged in, how can they change their password?). I envision the workflow as they login with their temp password, now that they're logged in they
can see the change password control and change their password. I'll usually set the web part to not display the chrome, so that nothing can be seen when the user is anonymous.
You shouldn't be getting an error though - what's the error message? Is the error coming from the Change Password control?
Potentially the error could be from the URL Rewriting rules - if there's a problem with your rules, you'll get errors. Try disabling the URL Rewriting to see if it works fine without it.
Also, the latest version is 1.1.0. I'm currently testing 1.2.0 - it should be released within the next couple of days.
Thanks for the fast reply - I feel dumb as of course what you are saying makes sense. I assumed (I know, I know, assumptions) that I needed to add the username field to that control so users could type it in.
It doesnt seem like URL Rewriting is available on this server, so I dont think that is playing a role. The reason I got confused was that I was following the links in the email that get sent from the "Lost Password" function:
You have requested this mail because you have forgotten your password to (agency) SharePoint 2010 Portal.
Your temporary password is: BU]f2-eCJp}Fu) Your temporary password can be changed immediately by logging onto the Change Password Page (links to blank control) using your user name and temporary password.
The ChangePassword page is located at http://(site address)/ChangePassword.aspx. (links to blank control) Thank you.
and then the next step they are taking is to hit the "Sign In" link from the top right and they try to put in the temp password they get:
Server Error in '/' Application.
Description:
An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.ServiceModel.FaultException: The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute
or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework 3.0 SDK documentation and inspect the server trace logs.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
That's true - there is the username field - I can see how that would be confusing. If you'd like to do it that way, add a feature request in the issues tab and i'll consider it for a future release.
Do you get the error if you log in regularly and then go and visit that page? If that works, compare the url in the email with the one on the page to make sure they are the same. Try copying the url from the page, signing out, and then visiting the
url manually. If that works then there's probably an issue with the url in the email. If that doesn't work, and you can never visit that page then there's probably a URL Rewrite error. If you only get an error when logging into that page
with the new user's login, then there might be a permission issue somewhere, but i'm not sure what that would be.
I can hit the page no matter what method I use to get there (the email URL and the normal URL are one in the same), it's just that the control is blank. Users finally started testing more today, and of course they are all blocked from gaining access to the
site due to this issue.
They all get the default email after I approve their accounts that link to the blank "change password" web part. My instinct is to blast MS for not having something to handle this built-in, but what's the point...
Could it be my .NET version? The error states 3.0 but the site is set to 2.0?
Oh ok, I thought the users were able to sign in ok, and then when they were redirected to this page after signing in they got the error. What happens if you sign in manually and then visit this page, do you get the error? If you sign in manually can
you visit any other page, or do you immediately get this error after you sign in?
Did you try disabling the url rewriting?
It won't be your .net version - 3.0 and 3.5 are just extensions to 2.0 - so you always set the site to 2.0.
Originally I had used a different method for setting anonymous access and under that method I was able to setup two FBA accounts with different rights and everything worked. I ran into several deal-breaker issues with the first method, and then blissfully
I found your method mentioned above (thanks for that too!) and that solved my issues. It was after starting a new site collection and following your blog post that I first noticed the Change Password issue. Everything else works perfectly!
Let me list out the steps:
User visits front page of site (anon) and that includes a link to the Membership Request page
User completes request, email sends fine
Admin views FBA request, approves User
User gets email as shown below, clicks link
Link takes user to "Change Password" page, which has blank web part
User tries clicking "Sign In", takes them to log-in page
User selects "Forms Based.." and enters username and temp password
Error above displays.
So the be clear - the change password page never actually throws an error, that happens only on the default log-in page when using a temp password.
This is the email:
Your request for an account on <agency> SharePoint 2010 Portal has been approved and you have been granted access.
Your user name is: <username>
Your temporary password is: <temp pwd>
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
http://<web address>/Membership/ChangePassword.aspx.
Once you have changed your password, you can browse the <agency> SharePoint 2010 Portal site at <web address>
If you need additional access please contact the site administrator.
Thank you.
As far as URL rewriting, it is not installed on the server, and my Googling has not
yielded any results on where to configure or disable that if not listed in IIS or Services. Thanks so much for trying to help me - I really appreciate everything you do to help us noobs with SP.
which configures url-rewriting. So ignore my url-rewriting comments.
So I assume then that you can login properly using FBA? A temp password isn't any different from a real password - so it should work the same as if they had changed their password. The only difference I can think of between a new FBA user and an existing
FBA user that works is permissions. Try giving the new user the same permissions that you have, and then have them login. Maybe just for a test, make them a site collection administrator.
I did set a new account to be site admin and got the same error. I WAS able to log in using FBA no problem, and even had my personal FBA account set as secondary site admin and that worked great. Once I went to test the password change function (using the
forgot my password feature) I was locked out, as I got this error each time I attempted to log in, and my old password no longer works of course. Argh...
I'm working now on trying to get more detailed error information, but setting the <serviceDebug> flag is not appearing to have any effect on the error message. Thanks again for all of your help. Perhaps I need to step back and try to see if there is
a fundamental flaw with how I am managing security. One question I have is: Do I need to have to the FBA pages (request, pwd, etc) set up in each sub-site or can I manage sub-site membership from a single source (the root level)? This is how I wanted it to
work:
Top level site (anonymous access to all) which Includes FBA pages in the "SitePages" directory (Request Mem, Password Mgmt etc) - accomplished
Sub-sites which can either be wide open or secured by FBA - accomplished
Allow "Site Owners" to set permissions for users on each sub-site (without having access to see or edit other sub-sites' users) - not sure yet
Once I have this issue with the change password function resolved, I will eb able to continue testing with users. I may have to start over again with a new collection using your latest version or re-evaluate how this should work and look around for alternatives
to FBA (not having any luck there). I have a shiner from banging my head against this - why did I agree to manage SharePoint!!! :)
Very strange. Creating the user with the FBA Pack web parts should be no different that creating the users with the IIS Management tool, or the User Management page on the site settings. The only difference should be that the web part allows
a SharePoint group to be auto assigned. I'm thinking something else is going on here. Be sure to check your SharePoint logs to see if there's anything useful in them. But yeah, if you're still having problems I would probably try again with a clean new
site collection. Get everything working first without the FBA Pack (You shouldn't need it to get things set up - use another tool for managing the membership users - like the IIS membership tool). Once everything's set up again, and working with users
you register through the other tool, then install the FBA Pack to add the web parts to the pages. That at least will narrow down the cause of the problem. You can always see if you can get your current site to work by undeploying the FBA Pack and
generating the users externally - but I'm guessing the problem is elsewhere.
As for managing users from the root level, you can do that. There is a bug (fixed in the upcoming release) that won't let you use SharePoint groups defined on sub-sites - but as long as you define all of your SharePoint groups in the root site you should
be fine. Regarding your last point, you should be able to do that through People and Groups.
Howdy again - well, I started from scratch and re-created everything, and unfrotunatley I'm back at the same place. I was trying to figure out exactly what went wrong since this time around it failed before I tried anything else (anonymous access and all
that jazz) so it hit me that the only time worked was when I was using a previous version of your script. The 1.0.3 worked, and the 1.1.0 does not. Sigh...