Suggestion for GreenFuse (MODx Core User System and Tattoo)

Dunno where to add this, but I have an idea to make SSO (Single Sign On) system for MODx, and I was planning to have this implemented on the core, while I do still believe that my idea will need to be polished and commented by all the core developers and users for MODx.

So here I attached the database schema and data flow diagram for the new user base system, which might be applied to GreenFuse and the future release of Tattoo.

Any suggesiton or comment will be awesome. I’ll make this as my priority for now, because most of my projects required extensive use of User system on MODx, while I’m considering the current User Base system that we have is not stable and capable yet to be used as the main user system. I realize this while trying to integrate MODx with phorum. To be honest, I think phorum has a better user based system, and that’s why I’m here. I want to make MODx capable in becoming a master user base system for application like phorum, which I consider they have a mature user system.

Thanks

PS: Images is not being viewd to the forum, because it’s too long, and I know Zi doesn’t like that

ryan edit: But I am giving it a go!

Wow! Wendy, what did you use to generate those pics?

lol... I was actually expecting a reply to the proposed system

I’m using Microsoft Office Visio 2003 and the DBDesigner, the one that Raymond and Jason used.

DBDesigner?

Quote from: Mark at Feb 13, 2006, 08:18 PM

DBDesigner?

It’s here
http://fabforce.net/dbdesigner4/

No body seems to response to this proposal. :’(

Anyway, a much simpler solution will be to use the head ability, which will do the heave lifting, instead of using XML and etc.
After discussing this with Jason, he come up with 3 major things that will divide this whole system.
1. Credential/Authentication
2. Profile
3. Permission

All this SSO thing will only involve with Credential. So basically he main auth server will responsible with authentication of the user. It will check the email, username, and password of the user is correct, and it will identify the current user session is still valid or not. The other server/application will only need to check the auth from this main auth server, and if it’s valid, then the server/application will setup their own auth system to give access for this user for specific period of time depending on how the server/application work.

The profile will be a different thing, it will need to use REST or SOAP technology to let the main auth server or the server than store the users’ profile to exchange data with the current running server/application.

Permission usually being handled locally on the application itself, but considering for GreenFuse, we can have Permission to be exchange using redirection technology, just like the credential part, except this one is checking permission/role. This role will be duplicated by the application to its own known permission system.

So I think this is suppose to be simple and easy.
Now all we need is to come up with a better user management and API for MODx.
Do we need to contribute on this or I just have to wait for Jason or Raymond to combined the manager and web user, and provide us with a more useful and powerful API?

Thanks

A clean user API and class would be very useful for building MODx applications; I could certainly use one for the updated version of DocManager that I’m working on. And it would make it much easer to modify or even create radically different login scripts if there were such a beast to use at the core of any user management scheme.

Agree to that Susan.

I’m currently working on my UserMgmt library, which might need a little tweak, and I want to release it, but I know soon or later the library will b rendered useless. Something have to be changed from the core

Ok, before I sleep, I just want to pour out a few idea that I’m planning to do with the core.

Ever since I’m not a good coder myself, plus I’m still new to MODx, so here is the plan:
1. Remove web user admin from the backend
2. Keep Web User Permission admin from the backend, but associate it to the manager user
3. Change Web User login snippet to use manager login, but store the session data as web user with the right permission
4. Expose API for listing/editing/deleting/adding/logging for the manager/web users, which the logging will allow logging to both manager and web user or to specific permission.

WIll this do able? Is this the right way to go?

Thank you

I’d almost say that switching it all over to webusers would be more appropriate. How do you plan to delineate those that can access the manger and those that cannot?