Is MODx "user" the recommended approach for all login-based sites?

I know there are no dumb questions, but this really feels like one.

When one is using MODx to build/manage a login-based website, is it generally always recommended to use the user management that is built in? I recently worked on a site with a registration/profile creation component. We built it such that it stored the entire user profile, including login and password, in an external database. It never even occurred to me to tie in to the MODx user account stuff. If that would have been more logical/efficient, could someone explain what the benefits are?

Second, if I had done it that way, how should I have handled all the fields that aren’t in the standard MODx user table? Is it better to create custom fields and get all the data in the MODx tables, or to just use MODx to handle the basic account info and login fuctionality, and keep the other stuff elsewhere?

Quote from: jrotering at Jun 04, 2010, 01:04 PM

I know there are no dumb questions, but this really feels like one.

It’s not.
Quote from: jrotering at Jun 04, 2010, 01:04 PM

When one is using MODx to build/manage a login-based website, is it generally always recommended to use the user management that is built in? I recently worked on a site with a registration/profile creation component. We built it such that it stored the entire user profile, including login and password, in an external database. It never even occurred to me to tie in to the MODx user account stuff. If that would have been more logical/efficient, could someone explain what the benefits are?

Definitely recommended (and a tutorial is in process); Revolution already loads a session and user object (even if the user is anonymous with id 0), so the major benefit would be utilizing the infrastructure that is there without adding unnecessary bloat or complexity. By extending the modUser object, you can store your data in the external table, define additional related table objects, even authenticate against it with a plugin (and keep the password external only), while also creating a simple modUser object that will make any Extra that already works with the MODx user and security system automatically compatible. Being able to define granular security policies for any core or custom object in the system is a benefit of utilizing the security system, etc. There are probably many more...in short: yes, but you can also do what you want if you’re really stubborn, or really need to bypass it. You can even provide a custom session_handler_class if you need to.

Quote from: jrotering at Jun 04, 2010, 01:04 PM

Second, if I had done it that way, how should I have handled all the fields that aren’t in the standard MODx user table? Is it better to create custom fields and get all the data in the MODx tables, or to just use MODx to handle the basic account info and login fuctionality, and keep the other stuff elsewhere?

Extending the modUser table class allows you to define relationships to external tables if you need to. Just model/reverse-engineer them with xPDO and add an aggregate or composite relationship to it using the external_key field in modUser or by storing the modUser id in your external table. The external_key field and external_data field in modUser you can now utilize for storing foreign keys to external systems and associated (unlimited) custom data fields. I will also be adding a similar extended data field to modUserProfile before RC3 that can be used in a similar way on the default user profile object. These data fields are simply JSON objects stored in the database and accessible as a PHP array using the get() and set() methods of modUser/modUserProfile; you can store unlimited custom data in them, they’re reasonably searchable, and they are (or will be soon, in the case of modUserProfile.extended) editable in the manager.

Much more on this soon.

GTK. VGTK. Looking forward to the tutorial.

Follow-up questions:

• Are there any limitations or performance hits on the total number of users in a single Revo installation?
• Would you say that it is probably best practice to *not* manage multiple login-based sites from a single Revo installation using separate contexts? Or is that not a problem?

Quote from: jrotering at Jun 07, 2010, 10:31 AM

• Are there any limitations or performance hits on the total number of users in a single Revo installation?

Not any limitations I am aware of, beyond those of physical resource limits, i.e. MySQL limits, etc.

Quote from: jrotering at Jun 07, 2010, 10:31 AM

• Would you say that it is probably best practice to *not* manage multiple login-based sites from a single Revo installation using separate contexts? Or is that not a problem?

Why should it be a problem? I hope it’s not a big problem, though I’m sure there will be some unanticipated issues here and there. Obviously, these are new features to explore and if you choose that path, you will be pioneering at least a bit for now. But the intent is certainly to support such situations; it will just be a matter of due diligence on designing and implementing a security scheme for the entire configuration.

Extending the modUser table class allows you to define relationships to external tables if you need to. Just model/reverse-engineer them with xPDO and add an aggregate or composite relationship to it using the external_key field in modUser or by storing the modUser id in your external table.

Would you be so kind as to give me a starting point for how to extend modUser class using the "modUser id in your external table" approach? I have an external table called ’ext_profile’, with an ’id’ field that contains the modUser id, and a bunch of other fields that contain additional user profile data. How do I get that into xPDO, add the aggregate/composite relationship, and extend the class?

I realize this is pretty vast and open-ended; I’m really asking for a tutorial. Just a starting point would be extremely helpful for now though.

Hey,

Check this out:
http://modxcms.com/forums/index.php/topic,50888.0.html

I’ve recently asked the same question...depending on how many stuff you want to
save with each user you might consider just using user-settings...

In MODx 2.0.0-pl (and already implemented in SVN) is a new UI that allows you to add unlimited attributes to a modUserProfile. This is the new extended field that exists in the profile table.

From an API standpoint, the data is stored in the table as raw JSON, but when accessing the field with the get() method, it returns a native PHP array. You can manipulate this array and then use it to set() the field value. In this way, you can store extended profile data in nested arrays if you need some extra organization to the attributes.

OK, so, use the new extended field in the profile as my means of linking external data into a user profile. Sounds good. Would my "update the extended data" snippet look something like this then?:


Is that basically right?

Quote from: jrotering at Jul 09, 2010, 01:53 PM

Is that basically right?

That is precisely right.

How would I do a modUserProfile query with some criteria in the table’s standard fields and other criteria inside of the ’extended’ field?

I tried something like this:


and got this: