This project is read-only.

Bugs in mainline release of CKS:FBA

Topics: Internet/Extranet Edition
Dec 23, 2008 at 2:33 PM

I'm evaluating CKS:FBA for user self-registration to secure areas of a public Sharepoint site. We're working off of the CKS:FBA mainline, building the WSP ourselves - however, we've encountered a number of bugs, some of which are posted in the discussions (and not fixed), and some of which aren't reported at all.

Given the relatively slow pace of activity on this project (CKS:FBA), is it worth reporting them? Is there any chance I can help fix them myself?

The most recent one that I noted was that the password recovery email was completely broken. It's an easy fix, and I'd love to contribute it back into the codebase.

Dec 23, 2008 at 3:05 PM
  Our group finds ourselves in a similar situation. I know that our group would appreciate the posting of any bugs that you find and if your group is feeling generous, their solutions/workarounds. Even knowing what the bugs are without a fix is helpful! We're currently working on adding the FBA to our public sharepoint site but first we're extending the registration form to include several more fields. We've fixed the dependent feature bug that was preventing activation in Sharepoint and are slowly learning/reviewing the codebase.

I can assure you we, at least, would appreciate your postings! :)

Dec 23, 2008 at 3:19 PM
Edited Dec 23, 2008 at 3:22 PM
I filed work item 8604 for the password recovery issue. Once I get through implementing this, I'll go back and try to figure out what else we fixed.

Like you, we needed to extend the registration form to get some custom fields. We ended up adapting the solution posted here and extended by David Martos to provide for somewhat flexible custom fields. Unfortunately, David's code doesn't really provide the complete solution, and we found that with the current codebase, it's really not possible to disable approval of user accounts - a requirement for us - so we had to hack around the code in order to allow for the flexible custom fields without user approval.

Who's responsible for maintaining this project?
Dec 23, 2008 at 3:40 PM
I'm not sure who is the primary on this project. I do know that Mike Sharp (rdcpro) posts frequently to the discussions about CKS:FBA. I clicked on the People tab and noticed quite a few names are attached to this project.
Dec 23, 2008 at 5:31 PM

These days, it's probably either me or Anthony Sumner who is doing most of the work...but we've both been swamped with our regular work.  Anthony was able to get that Beta 1 release, which was huge relief to me, as I've been supplying folks with my black market WSP for a while.  I have a separate branch that has most, if not all of those bugs fixed, but I haven't had time to merge it into the main branch, which was completely re-organized and updated to VS2008.  The main thing for me was to fix the auto-approval stuff, and the Emails.  I'll spend some time over the holidays merging these, and we'll get a beta 2 release out (and I'll fix the bug that prevents you from turning off approvals in the first place). 

Fixing auto approval required fairly significant changes, because of an oddity in how the user is internally provisioned by ASP.NET.  Also, the user wasn't getting added to the correct group, so while they showed up as a user, they couldn't do anything.  I fixed these by adding another event handler for the OnCreatedUser.  Then in the MembershipRequest.ApproveMembership call, the user's internally generated password gets reset to a known value, so that it can be emailed.


protected override void OnCreatedUser(EventArgs e)
 SPSite site = SPControl.GetContextSite(Context);
 if (site.Features[new Guid("{69CE2076-9A2F-4c71-AEDF-F4252C01DE4E}")] == null)
  // Note: this doesn't run using the privileges of the anonymous user, so we elevate them
  // Also, you can't use the original Site even with elevated privileges, otherwise it reverts back to anonymous.
   using (SPSite site2 = new SPSite(this.Page.Request.Url.ToString()))
    using (SPWeb web = site2.RootWeb)
     MembershipRequest request = new MembershipRequest();
     request.UserEmail = this.Email;
     request.UserName = this.UserName;
     if (System.Web.Security.Membership.RequiresQuestionAndAnswer)
      request.PasswordQuestion = this.Question;
      request.PasswordAnswer = this.Answer;
     request.FirstName = this.FirstName;
     request.LastName = this.LastName;
     request.DefaultGroup = this._DefaultGroup;
     request.SiteName = web.Title;
     request.SiteURL = web.Url;
     request.ChangePasswordURL = string.Format("{0}/{1}", web.Url, web.Properties[MembershipReviewSiteURL.CHANGEPASSWORDPAGE]);
     MembershipRequest.ApproveMembership(request, web);



If you have fixes for these or any of the other bugs, I'd  be happy to include them in whatever way is necessary.  Once we get a stable 1.0 release, I'm pretty sure that there are a number of folks who'd like to get the custom fields added in there, along with some auto-provisioning/configuration code for ASP.NET FBA itself (which is something I need for my production environment myself).

Mike Sharp




Dec 23, 2008 at 5:41 PM

Thanks for the thoughtful reply. I've currently got a setup with SVN tree and VS 2008 project, so it probably would make sense for me to wait until you get the Beta 2 branch checked in, and then I can diff what I've done (again, mostly in the areas of custom fields integration, but some minor bug fixing as well). Perhaps we can tag-team some of the remaining issues?

Dec 23, 2008 at 7:24 PM
Heh, we have the Beta 1 release checked into our TFS internally and were thinking along the same lines as Peter. We have also identified the need to add some styling/customization code to the webparts that are provided but we're holding off on doing that until a later iteration. Although we might go ahead with that considering Mike's generous offer to do some work over the holidays. :)

As a side note completely unrelated to this, wouldn't it be useful if we could link our internal TFS to the codeplex TFS so code changes could be managed as a series of merges between branch on the source TFS (codeplex) and our TFS? I think it would certianly facilitate an easier exchange of code updates.

Anyways, random thought.

Dec 23, 2008 at 9:16 PM

That would be great!  I guess I'd better get cracking. 


The email styling things bothered me too.  I made a bunch of changes to the email templates a while back that were incorporated into 17054 or earlier, but I missed one or two because I didn't need (at the time) auto approval.  At least one I've fixed recently in my "black market" WSP...

On the random thought...I don't really know enough about how TFS works to even know if that's possible...In fact, I'm kind of the exception around here--I don't connect to TFS directly, I've been using SVNBridge and TortoiseSVN to connect.  While that's been good in that I've discovered a couple of bugs in the build scripts (because they don't assume the project is built that way, and so the .svn folders get inadvertantly included in the cab file), it's not so easy to maintain two branches...My merges have been all manual.