I'm wondering if anyone has had any trouble with SPContext.Current.Web.CurrentUser showing up as null when using forms-based authentication?
In my personal development environment, this is not an issue. On our shared development site, it is. This has a bad side effect of the Change Password web part not rendering, among others. This of course makes things very difficult to debug because I can't
simply step through the code.
The site in question is an anonymous endpoint (extended web application), and that is the chief difference between it and my personal environment. The web.configs have all been updated as per your setup tutorial. Logging in works. We have an ASP.NET LoginView
in the master page, and it properly detects when someone is logged in or not, shows your username, etc.
Do you have any suggestions for what I might check?
I'll also add that assigning an FBA user as a Site Collection Admin isn't working right, either. The user gets an Access Denied error when attempting to load any admin-type pages (i.e. /_layouts/15/settings.aspx). I feel like this is related to SharePoint
not "seeing" the FBA user as a SharePoint user as well.
You should be able to set an FBA user as a site collection administrator. The only reason i've seen for it not working is if there is an error in the membership settings in your web.config (web application and securitytokenservice).
Can you login with an FBA user if you assign them other permissions? Do the FBA users get recognized in the people picker? Is it just the admin pages that don't work?
I think I might have a better idea of why it's not working.
In my personal development environment, I have both Forms and Windows Auth activated. When I log in with Forms, I'm using SharePoint's "native" forms auth login page. I log in via Forms Auth and everything works as expected.
On the shared development server, we're using a custom web part to perform the login. It takes into account that FBA uses claims now, and seemingly logs in successfully. Like I said, we have a LoginView web part that updates accordingly between anonymous and
authenticated users. We even have an ASP.NET LoginName control that correctly picks up the authenticated user's username.
But, there must be a difference in how SharePoint authenticates FBA users and how we're doing it via the web part. Can you think what step we're missing in our custom code that would allow a user to login but not "register" correctly with SharePoint?
Feature Request: Please add a customizable Login web part to the FBA Pack!
If you're using a custom web part to login, I would guess that that's where the problem lies. Most tutorials out there show building a custom login web part using the ASP.Net login control. Although this works in SharePoint 2007, this will not work in
2010 without major customization. Use reflector on the SharePoint login page and you'll see what I mean. They are using the ASP.NET login control, but much of the functionality has been overridden.
If you just want to log somebody in with a user and password, you can find the code to do that in membershiprequest.cs. Essentially the magic line to do that is:
Microsoft.SharePoint.IdentityModel.SPClaimsUtility.AuthenticateFormsUser(new Uri(web.Url), request.UserName, request.Password);
The login web part is planned, not for the next release, but the one after that. It's probably 4-6 months out.
We do use the standard Login control, but we have tied it into WIF so that it generates a claims token (i.e. the FedAuth cookie). I suspect we're doing things 90% right, and we're missing a step or two to have it working correctly.
This gives me some leads to track down, so thank you very much for your help! And I'm glad to hear you're planning the Login web part. I'll happily swap out our custom code once it's released.
The part of the login control that seems to break things is the standard asp.net authentication cookie that it creates. If that cookie exists it breaks SharePoint. But definitely check out the reflected code of their login page - it shows how they deal
with the cookie and does a few other things.
I figured it out. I wanted to follow up here so that it might help someone else.
Our site represents an externally-accessible, public website. We extended the web application into the Internet zone, and have Anonymous and FBA access enabled for it. Since it's external, we have a solution that locks down access to the "_vti_bin"
directory (i.e. any requests to it result in a 404). For sites that are purely anonymous, this is almost never a problem. When using FBA, it prevents SharePoint from fully authenticating the user. Even though the user could log in using FBA credentials, SharePoint
never had a valid SPUser object mapped to it. Thus CurrentUser is null and you get all sorts of funky problems.
Glad to hear you got it working!