Switching contexts pervents Login from logging in (frontend)

OK, I've got the following situation going on.

I've got 3 contexts. web, other and playground. Hooked up to two URLs, I'm only using web and other. Since 'web' is launched in the index.php root of MODX as a default context, you basically have no other option to switch context (switchContext) next to editing the file manually, this reducing backwards compatibility and upgradablity. So, I sorta found my way around that in the past by hooking OnHandleRequest (modrequest.class.php) to switch context depening on the URL.

All fine and dandy, I see the context switching, other language, other site root, other error page, all of that fancy jazz. Now, I want to keep the plug and play going here, so I tried to equip the login.html page on both contexts with the Login snip from Shaun. Easy? Yes! Well, sorta.

When I added it, you immediately get a fancy template which lets you login on the fly as it were. Well, the web logs in fine! other however, does not. So, I tried adding &contexts=`web,other` and that worked. Well, the documentation clearly states "(Experimental) A comma-separated list of contexts to log in to. Defaults to the current context if not explicitly set.". So, I'd try to avoid that. I tried hooking the core by adding login_context or add_contexts but both won't do the trick. I see the PHPSESSID changing in the cookie, I also see the record in the modSession database chaning, but still my user doesn't login. I test this by adding the [[+modx.user.id:userinfo=`fullname`]] and `internalKey` to the page. Yes yes, both uncached.

So, I'm really out of options besides manually editing the index.php and jerry riggin' the whole ordeal... I'm here on my last legs asking for help, because I've tried it all, I think!

Oh and before you ask, (anonymous) and Administrator (the admin user I try to login) have Super User (0) / Administrator rights on the page and the anonymous group have "Load", just like on web. I compared the 2 and the rights match to the letter/byte/phantom leg.

Thanks in advance lads.

So, I tried adding &contexts=`web,other` and that worked

Then what's the problem? It's pretty stable imo. Context support was added a long time ago, nothing wrong with it. It pretty much passes whatever you tell it on to the core's login processor, no problem there.

Thanks for the QR Mark.

Basically there isn't a problem, but it feels like a fix. I want it to work OUT OF THE BOX. You know! Adding it, logging in an go. And especially because it clearly states "Defaults to the current context if not explicitly set.".

So, I want to try and figure out of this is a bug and/or why it doesn't work. The switchContext is called OnHandleRequest, so even before OnLoadWebDocument and parsing. Aside from that, and correct me if I am wrong, when I POST/REQUEST to the same page under the same specific enviourment variables (thus context plus the login post action) I assume the same context is loaded? And the strange thing is, in my "loginResourceParams" I've got "success":"Yay" set up and when the login is correct and posts through, the user isn't logged in but the QueryString clearly reads those params. (/login.html?success=Yay)

Again, contexts=`web,other` is fine, but I don't want each user/developer to mandatory add those params on each Login snippet on each login resource in each context. Seems like a lot of effort for something that should work non the less.

--edit
Also, _initSession is called in the initialize function of MODX, directly out of the index.php file. Perhaps I've got something going on there right now. I tried to change the session_name per context but that obviously doesn't work, due to the context being loaded after the initial initialization.

Do you have one login page and kinda hack it to think it's in a different one, or one login form for each context?

Breaking it down...



Easy answer, 1 per context, thus 3, currently 2 in use due to testing with 2 contexts.

--edit
I partialy fixed it by adding the component to the loadExtensionPackages portion. Right between the initContext and initSession, I managed to switchContext and now it works as expected. I now however need to resturcture my initializer and plugin, but that's OK for now, since it's still in the early stages.

Still, I'd like to debate further about how and why this is such a problem... I might be missing something here. [ed. note: ReSpawN last edited this post 14 years, 7 months ago.]

Used this before with no problems, so I'm kinda tempted to argue it's your switchContext

In my multi context solutions I tend to edit the index.php. Perhaps your plugin was firing *after* the Login was initialized, making it recognize the default context as the loginContext, which only worked on the right one when specifically calling it in the snippet call.

Hehe, argue you may, but the fact remains that even then the addContexts or loginContext for the Login snippet don't work. Aside from that, the switchContext function couldn't be more straight forward than it already is. I'm guessing that somewhere between switchContext and the initial session handling, the Login contexts passes through and doesn't enter the right context. As stange as that may be, I've tried dumping the values in both the Login snippet (the controller) and even the login.php processor from MODX itself. Still seeing the "other" context and still, no login. ;-)

As I said, I've fixed it so that I switch contexts between the initContext and initSession, but it's still strange, no?

Without diving into the request handler I have no idea where "between the initContext and initSession" is. A plugin, or modified the actual code?

From looking at the Login code yesterday, your loginContext should be where you want to login to (which defaults to the current context as per $modx->context), and addContexts should include any other contexts. So if you only want to login into "other" that should be the loginContext, if you want to login to "web" as well "web" would be your addContexts. So addContexts shouldn't be "web,other" in that case. The Login's &contexts parameter adds it as addContexts.

Between initContext and initSession lies the loadExtensionPackages. The context initiates the caching and (re)buidling of the alias map and so forth. Session obviously handles the session management. What I had was, due to MODX calling handleRequest and further on going to the modRequest class handleRequest (thus initiating the first really useful event "OnHandleRequest"), a hook that switches on HandleRequest, but then the context and sessions have already been initiated by the _initContext and _initSession. I noticed in the modSession database table that each time I logged in, the row changed and the login context in the serialzed cache was "web" instead of "other".

So, in short, hooking onto the OnHandleRequest proved to be too late for logging in and so forth. Perhaps it's a bug, perhaps I'm reading the code wrong. That doesn't leave out the fact that Login didn't handle my "other" context login the way it should, by just logging in. Even when the context was switched, the language changed and the site_start was pointed to 3 instead of 1 as resourceId.

I'm getting the feeling that we're talking along side eachother... I am almost convinced this is either a bug or that I missed something which is catched in the initSession handler. Out of experience I would say that logging in revokes the current PHPSESSID, generates a new one for a specific context and adds that to the $_SESSION global. No luck tho, since loggin in in "web" turned out that the dump of $_SESSION has 10x more data than in "other".