LDAP authentication is done by user ID. LDAP fallback authentication first tries to authenticate against the internal database by user ID, then if that fails it uses the same credentials to attempt an LDAP authentication.

Jamie

I think it will be problematic to make that change because it goes beyond validation for login, the authentication cookie is either based on the email or the userid (LoginName field) , it cvan't be an either or situation and that matters everywhere the user is looked up.

My suggestion would be to populate the LoginName field with the email address for your board members, then they can login using their email addresses.

Best,

Joe

Problem is we don't SetAuthCookie, that is done for us behind the scenes by the ASP.NET login control using whatever was passed in and validated by the membership provider. For LDAP that is going to be user id aka loginname.

I don't see why you can't just duplicate the email address in the LoginName field, seems like a good solution for this problem to me.

when you enter an e-mail address and hit "Update User," it actually replaces the '@' symbol with a dot

That is an easy problem to fix, it is fixed now in the source code repository.

Hope that helps,

Joe

Those comments are from back in the .NET 1 days circa 2004 before use of the asp.net LoginControl and the existence of MembershipProvider.

look, I've tried to accomodate you but I'm getting tired of arguing with you.

That comment was before .NET 2, before support for LDAP. If we were setting the auth cookie I'd have gone along with allowing email and ldap together but I'm not changing that now.

If it is still important for userid to not be the same (I'm not so sure it is, they each must be unique per site but I don't see a big reason why they cannot be the same value for a given user) I would implement it different today perhaps with a custom validator on the registration page, but that would not solve the problem you are trying to solve for your 30 or so users that need to login without ldap using their email address. How about update their user ids to their email address and move on? Why must you keep arguing with me?

I'm arguing with you because I'm told to replicate the e-mail in two different fields under user profile as a "solution" to my problem when it really isn't. The user IDs for those 35 users were taken out of our donors database and we need those user IDs because of a module I'm working on which would use that database.

You could solve that problem in your feature by using a custom table to relate those ids.

I understand that you don't manually set the authorization cookie and that you let ASP.NET security framework take care of that, but I also know that this can be addressed and I'm willing to help.
I think the biggest issue here is that even though this is an open source product, the actual development of the entire CMS is fairly closed in the sense that it's not common practice for people to fork, make changes, and make pull requests. So essentially, one has to either fork the project and maintain his/her own fork, continually merging your changes into the fork or try and convince you first to avoid a situation where changes have been made, but you won't commit them.

You have a mythological view that all open source projects should be or are run a particular way. I'm not going to defend myself against that, I run this project my way, it is tightly controlled and that is my perogative, I've always been clear about that, I've never said its open for any or all changes to get in. I accept changes that I'm willing to accept or I reject proposals for many reasons that make sense to me. I'm not willing to make this change at this time. I'm sorry if you don't like that. Open  Source is many things to many people, an open source license doesn't mean every open source project must follow a particular process or that I'm doing it wrong if I don't accept your changes.

user ID and e-mail have separate fields for a reason. My original plan was to utilize as much of mojoPortal as possible and user ID and e-mail seemed to fit the purpose perfectly and they still do, but it looks like I'll have to work around the limitations.

They both serve the purpose of supporting authentication, neither one is an ID in the database sense of the word, they are not intended for joins to other tables in custom features, relating to other tables would be better implemented using UserID field or UserGuid field, but my guess is you do have the email in your external database so you could probably use that if you really wanted to, but a more correct relational way of doing it would use the actual ID fields as opposed to the loginname which is just labelled as User ID in the UI for the benefit of the user.

In a perfect utopian world maybe someday I would just sit around and coordinate the contribution efforts of others (if I agreed with the proposed changes in the first place), but in the real world that takes a lot of time reviewing changes and communicating back and forth and it makes the project require more formal processes the more developers that are involved, and that slows things down. And the more people who want to sling code my way it diverts my efforts off of my own devlopment agenda and puts it on someone else's. I have limited bandwidth so I run the project the best I can under the varying concerns and goals I have foremost of which is making a living. Have you ever heard of Rainbow portal? I once was involved with that and it was so open there were lots of people with commit access all coding in different directions and it ultimately self imploded as a project because there was no-one in charge enough to say no. If others run their projects differently that is up to them and not my concern to compete with them on process of running the project. I'm happy with the rate at which mojoPortal popularity is growing and I'm happy with the way it is progressing as a product, as far as I'm concerned my way of managing it is working very well.

What I am suggesting is to always use user Id for everything internally, including passing it to the SiteUser constructor. This way when user enters an e-mail for the username, we simply look up the user Id for that e-mail in Login.LogginIn event handler, re-assign UserName to the user Id and the proceed to pass it to SiteUser constructor.

SiteUser can always expect a user Id to be passed in to it, nothing else.

No, I don't like that idea. For LDAP users the cookie is going to have the loginname, and for the ones using email it would have the email address. you're suggesting sniffing the value of Context.User.Identity.Name to see if it looks like an email address then lookup ther username then lookup the user. Lots of extra weird logic and also additional hits to the database every time we lookup a user and big changes to code all to support this edge case of wanting to use email/database authentication in addition to ldap but also don't want to put the email address in the loginname field because we are using it to relate to some other custom data.

For this scenario, given the extra requirement that you don't want to put the email address in the LoginName field, I think the best solution is just modify the procedure like this:

ALTER PROCEDURE [dbo].[mp_Users_SelectByLoginName]

@SiteID int,
@LoginName nvarchar(50)

AS

SELECT *

FROM
mp_Users

WHERE
SiteID = @SiteID
AND (LoginName = @LoginName
OR Email =  @LoginName)

GO

Simple and effective and not really likely that this procedure will ever be modified by future upgrades. Not saying it could never happen but I don't expect it to, and it hasn't changed in many years so it hasn't been touched by an upgrade script in many years.

This would immediately meet your goal and seems like a reasonable solution to me for this particular scenario.

This is now implemented in the source code repository, see the 2 new settings under the LDAP Settings tab in site settings.

Note that the previous web.config setting for UseLDAPFallbackAuthentication is no longer used as it has been replaced by a site setting. 

I would appreciate if you and Jamie could test this since I'm not currently setup to test with LDAP.

Thanks,

Joe

Hi Joe, here are the scenarios I tested, and all work:

• LDAP fallback off: LDAP login works, database login fails
• LDAP fallback on: LDAP and database login work
• Allow sign-in with email: LDAP login by user ID works, LDAP login by email fails, database login by userid or email work

So it looks like everything is working as intended.

As an aside, one thing I noticed is that when LDAP fallback authentication is enabled with fallback off, the password field is hidden in the member list manage user interface. I think for consistency it should also probably hide the "User Must Change Password" checkbox in that case, since that really doesn't make sense in an LDAP-only environment.

Also, do you think the sign in ID textbox label needs to change? But maybe not, since I'm not sure if showing "User ID or Email" would be good, since LDAP still can't log in by email address.

Jamie

I would like to point out that technically ldap users could login with their email address since a database user is created for every ldap user and we must populate the pwd field with something so we generate a random password. An LDAP user could find out this random password by password recovery and then login using their email address and the mojoportal password instead of the ldap password. But this is also true when not allowing email, but still allowing database fallback, the user could login using either their ldap credentials or their username and mojoPortal password. So in any case where database authentication is allowed it is possible to login using the database credentials.

Best,

Joe