SMF Module

Quote from: xwisdom at Dec 26, 2005, 02:45 PM

The problem here is what if the user was exported from MODx? IMO SMF will not know the password or be able to apply sha1

If we were trying to synchronize users, that would absolutely be a problem. What we really want to do is aggregate users though, not synchronize them between both repositories. We want to be able to get profile data from either place, MODx or SMF, making sure we don’t have duplicate usernames/email addresses, and being able to authenticate against either repository. This aggregation model will work much better and more efficiently than trying to syncronize user repositories with SMF or any other third party product.

Quote from: OpenGeek at Dec 26, 2005, 02:58 PM

Quote from: xwisdom at Dec 26, 2005, 02:45 PM

The problem here is what if the user was exported from MODx? IMO SMF will not know the password or be able to apply sha1

If we were trying to synchronize users, that would absolutely be a problem.  What we really want to do is aggregate users though, not synchronize them between both repositories.  We want to be able to get profile data from either place, MODx or SMF, making sure we don’t have duplicate usernames/email addresses, and being able to authenticate against either repository.  This aggregation model will work much better and more efficiently than trying to syncronize user repositories with SMF or any other third party product.

That’s going to be a little tricky. You see MODx requires a user id to be assigned to Roles and Access profiles.

If SMF (or some other) is used as the primary user information source a link table will have to be maintained. Now what happens when another application wants to use MODx as it’s primary user source? Where will it get the user information from?

[Third Party App] <extends> [MODx Users] <extends> [SMF users]

or

[SMF users]
[Third Party App] <extends> [MODx Users]

This is indeed the ideal but requires major changes to the core system.

IMO it’s best to make MODx the user source and have other system authenticate against MODx user base or have MODx authenticate against other system will maintaining user information separately.

Indeed MODx would have to maintain a ’copy’ of the user in the MODx user DB, but it would not be used for authentication/credentials, but only for profile/permission data which can probably easily be synchronized with the external source -- something would indicate that the record was an external reference to a user aggregated from an external system. I think we can accomplish this with very little effort in the current codebase.

Allowing other systems to do this internally from MODx, would require a solid API that could be loaded by external systems and would give them access to our authentication functions. This will indeed require major changes to the core.

as of TP3 you can override MODx’s authentification systems using a plugin.