Joe will be able answer this better than I can, but as far as I know, the only supported "customization" for the registration page is the optional registration agreement text you can use. If by "FB auth" you mean Facebook authentication, a number of other security pages would have to be modified in addition to registration, and site settings would almost certainly need to be stored, and then you are looking at a serious fork of the code, which is very much not recommended--you'll lose the ability to upgrade your sites without an error-prone re-merge of your customizations each time.

Besides the built-in database authentication, mojoPortal supports LDAP, database with fallback to LDAP, Windows Live, and Open ID authentication. I don't know if Joe wants to add even more authentication options, because each additional method adds another layer of complexity, but I'll let him speak to that. If he is interested, it may be that you can work with him to get your Facebook authentication code integrated into the mojoPortal core and thereby avoid the whole forking issue.

Jamie

You need to copy also your custom.aspx file(s) in the post build event.

Make sure you debug the mojoPortal.Web project not your own project, you will be able to step through your code and set break points but you can't debug directly from your site it has to run in the context of mojoPortal.

I've committed the change to the source code repository so the registration link is configurable from Web.config but this is only needed if you are not using the same url and overwriting our registration page with yours. Look in Web.config in th elatest code and you will see the settings.

As far as persistence it depends on your needs and how you need to be able to query the data. In some cases it may be best to make your own custom table join on UserID and/or UserGuid to mp_Users and add fields to your custom table for your properties. We do have a table mp_UserProperties where you can store custom key value pairs as strings. There are methods on SiteUser for SetProperty(propertName, propertyValue) and GetCustomPropertyAsString(propertyName). These are used by our built in customizable user profile. But again depending on how you want to query and display the properties it may be better to use a custom table than to use key value pairs.

Hope it helps,

Joe