Scotty, how does WLPE/MODx save the password to the database?

Hi Susan,

I looked at the manager_users table by mistake, so did not realise there was an extra column, "cachepwd". I assume this would be a problem!?

Are there any real problems with the rest of their profile remaining with MODX? My suggestion was purely about integrating membership names and passwords.

I’m a non-coder (if it isn’t completely obvious), so I’m being very speculative by even suggesting any possible method of integrating the two systems. I hope I’m not wasting people’s time with nonsense.

Thanks.

You could actually use any hash algorithm you want in the database; you would need to modify the login processing code to use the same one on the POST password from the login form. You might also be able to make use of a plugin with one of the web login events. The biggest problem is that MODx sets its own session_name (from the config.inc.php file generated on installation), so the two sessions need to be coordinated with the same session_name.

Other than the login snippet, only the manager/processors/save_web_user.processor.php would be effected, and I believe that a plugin would be useful here to modify the password to be encrypted with a different hashing algorithm. You would need to use the OnWebSaveUser and update the new user’s password since the password is encrypted after the OnBeforeWUsrFormSave is evoked; it’s actually part of the query, so it uses the MySQL md5 function.

Hi Susan,

Setting the session name is straightforward, as it can be very easily changed with SMF to match the Modx cookie name (it can be reset to anything I wish within the SMF forum admin area).

I’m afraid the rest of your explanation is way beyond my abilities to understand. I am hoping that if there is some potential to this idea, a coder might like to look at this. It seemed to me (and more so because of your replies), that the code changes required by such an approach might be quite minimal. And, if it is relatively straightforward, this approach could be used to integrate Modx with many other forums and other mass-participant softwares too.

If this was made to work (using a common cookie name), then being logged onto one system would automatically have members logged into (and logged out of) the other - yes? If so, and if logins were handled only by the SMF side of things (disabling weblogins in Modx), would Modx code modifications still be required in manager/processors/save_web_user.processor.php? I don’t mean to put off anyone from developing a full solution, I only mention this in case it allows for a very much simpler solution.

Thanks.

If logins are only needed on the forum side, then nothing needs to be done. However, if someone moves from the forum to the MODx site, then goes back to the forum, there is the possibility that their forum session has timed out and they would need to log in again.

What MODx is doing is saving a user’s password as a one-way hash using MD5. It can’t be recovered (although it is always amusing to enter a hash (the 16- or 32-character hash) in a Google search and see what you get back). This is handled by the manager/processors/save_web_user.processor.php script when adding users via the Manager, and by the websignup.inc.php file in the weblogin snippet (it would also need to be modified in the code for changing passwords).

When the visitor logs in, his login is taken from the form and encrypted with the same MD5, and that is what gets compared to the database. This is handled by the weblogin.inc.php snippet file.

Since there are so many places where the MD5 is specifically used, and to change all of these places would be a problem when upgrading MODx without destroying your changes, MODx provides "events" that can be used in plugins. The code in a plugin will be inserted into the normal MODx processing at the point of the selected event(s). This way you can change how MODx does things without changing the core MODx code at all. There are plenty of events available for creating/editing users, changing passwords and logging in and out.

For example, if you know what SESSION variables and COOKIE variables another program needs to set when a visitor logs in to it, you could use one of the three MODx login events to set the appropriate SESSION and COOKIE variables; then as long as the other program is using the same session_name, it would be fooled into thinking the visitor was already logged in. If the other program keeps a record of login/logout information, the same plugin can also make the necessary inserts/updates to the other program’s database. And another plugin would fill in the other program’s user tables in its database whenever a user is created or edited in MODx.

Quote from: sottwell at Mar 19, 2010, 01:07 AM

If logins are only needed on the forum side, then nothing needs to be done. However, if someone moves from the forum to the MODx site, then goes back to the forum, there is the possibility that their forum session has timed out and they would need to log in again.

Hello Susan,

But, unless I’m missing something, this is what happens anyway. If they do not set their login to be permanent, they are logged out anyway, on the forum or not. I assume that if they do indeed set their SMF login as permanent, they will not be logged out by visiting the Modx controlled content.

Oh, do you mean that their session is timed out due to inactivity? This doesn’t happen with SMF. Either their login time expires, or they must logout if they have set their login as permanent.

Quote from: Colin at Mar 19, 2010, 08:27 AM

Oh, do you mean that their session is timed out due to inactivity? This doesn’t happen with SMF. Either their login time expires, or they must logout if they have set their login as permanent.

Right, SMF uses a custom database session_handler, MODx uses the default PHP files session_handler. Because of this it is likely impossible to get the sessions to behave the same.

It is so frustrating that there is no practical solution to this. One of the reasons I was atracted to Modx in the first place was because there already existed a Modx-SMF bridge (which, as far as I can tell, no one has managed to get working properly). I’m not suggesting that I will move away from Modx, but integration of such mass-participatory softwares is practically a must these days.

I know that there has been some development of a native Modx solution, but complex communities require complex forum software, and I can’t see the Modx forum being developed to something comparable this side of never. I know I’m probably expecting too much.

Is there any serious thought/discussion about a common system of handing registrations, memberships, sessions, etc., with other mass-participation softwares? These issues will never go away until a common framework is developed, and the need grows by the day.

Anyway, thank you Susan and OpenGeek for taking the time to reply.

Should be possible to use a plugin to switch MODx to using the same session handler that SMF (or any other application) uses. It would be easier to use a plugin to modify MODx’s behavior that to modify the other app’s behavior, since as far as I know this event model and API is, while not exactly unique, fairly uncommon.

Quote from: Colin at Mar 19, 2010, 07:13 PM

I know that there has been some development of a native Modx solution, but complex communities require complex forum software, and I can’t see the Modx forum being developed to something comparable this side of never. I know I’m probably expecting too much.

Is there any serious thought/discussion about a common system of handing registrations, memberships, sessions, etc., with other mass-participation softwares? These issues will never go away until a common framework is developed, and the need grows by the day.

We try to make MODx as flexible as we can; MODx Revolution will introduce even more ways to integrate external systems more easily (i.e. you can provide a custom session_handler class, and/or custom user class, and/or external authentication plugin, etc.). But the fact is, we cannot make existing software that was architected in completely different ways than the MODx framework was, automatically work together. In fact, some software just won’t ever work right with MODx. This is a more common problem in the PHP world, where there are no standard APIs for common services like authentication and authorization, as there is in say the Java/J2EE space.

I would love for everyone to choose to build their advanced components on the MODx framework, but there are so many frameworks (CMS-oriented or not) out there in the PHP world, getting everyone to build interoperable stand-alone web apps all on the same framework or in completely interoperable ways is just likely not going to happen any time soon. Until then, we have to pick our battles, and the forum issue is one we have chosen to fight by providing a native solution. I think the power and flexibility this native solution will demonstrate in the not so distant future might surprise you immensely.

And as for "complex communities require complex forum software"; I hardly agree with that. Complexity is easy to achieve. Simplicity and ease of use IMO are much more important to a successful community than "complex software" ever will be. It’s just much harder to achieve, and for me the MODx framework means the freedom to explicitly meet complex custom requirements head on to provide more elegant solutions. It also serves as a toolbox of reusable components that makes my team more efficient as we approach each new project.