web- / manager-login with some $_SESSION confusion on top

I was trying to make a front end login form by using the WebLogin snippet and found it rather confusing, so I decided to simply send the login form data directly to the manager login processor.

This lets me log in, but I can no longer use $modx->getLoginUserName() in custom snippets. Doing some snooping around (I’m quite new to PHP) I found that the getLoginUserXXX functions return data based on which way the user logged in. In one case we have $_SESSION[’mgrShortname’] and in another we have $_SESSION[’webShortname’].

My question is: what is the purpose for this distinction? The role and privileges of the user is already defined elsewhere in the session.
If I use the standard manager login procedure and then do a preview of my web page, the functions mentioned above all return NULL since my name is in the mgrShortname but I’m actually in the front end..

I’m confused..

Versions of MODx earlier than Revolution 2.0 separate users into Manager users and Web users. It’s partly due to a legacy codebase, but it’s also the basis of the security and access control system. If you log in through the Manager login, you’re logged in as a Manager user and any functions that are supposed to work in the front end, won’t recognize you as a Web user. I think doing it that way will also make a mess of trying to control user access through user groups, roles, and document groups.

I think your best bet is to tell us what problems you’re having with WebLogin. There’s a very good chance that we can help you make it work.

I won’t argue with the legacy codebase but find this a strange design choice. Like I said, a piece of code designed to return the login’ees name through getLoginUserName() breaks if the user logs in as manager and decides to edit content from the front end..

Anyhow, about the WebLogin snippet: I felt it was too congested. I don’t need password retrieval and want something simpler. What I’m doing right now is I call /manager/processors/login.processor.php through my forms action-attribute.

Maybe it is possible to call weblogin.processor.inc.php directly like I’m currently doing with login.processor.php, I haven’t looked into that possibility yet..

Quote from: Mar at Aug 14, 2009, 04:38 AM

I won’t argue with the legacy codebase but find this a strange design choice.

That’s why it’s gone in MODx Revolution.

Anyhow, about the WebLogin snippet: I felt it was too congested. I don’t need password retrieval and want something simpler. What I’m doing right now is I call /manager/processors/login.processor.php through my forms action-attribute.

Maybe it is possible to call weblogin.processor.inc.php directly like I’m currently doing with login.processor.php, I haven’t looked into that possibility yet..

Possibly, but you might consider this: Duplicate the Weblogin snippet, rewrite it, and use the rewritten version.

The design choice might be a little more understandable if you are aware that originally Etomite didn’t have any front-end user management at all. The MODx extensions to Etomite added web user functionality, among other things. So it wasn’t originally part of the core at all, and got bolted on by a third party (which later became MODx).

Please enlighten me, is the WebLogin only for web users?

If that’s the case there’s no point in using it: what I was looking for was a means for an editor to update site content without having to go through the back end manager. Which brings me to question #2: is there any safety concerns associated with calling /manager/processors/login.processor.php from the front end? If not, I guess things are dandy! Maybe I should wrap the php-call in a document ID with a redirect though..?

edit: and thanks for the background. I think my confusion stemmed from misunderstanding the difference between a web user and a manager user.

What you are looking for is QuickEdit (0.9.6) and QM+ (1.0). The editor logs in to the Manager and is sent to the front-end. The toolbars for QE or QM are at at the top of the page. He simply goes to the page he wants to edit. I believe that there are one or two snippets to allow a manager to login from the front end as well, although personally I think having to go to the manger login form to log in makes the editor pay a bit more attention to what he’s doing, as it’s more obvious he’s in a manager role.