multiple context login

Hello!

Today I would like to share with you the outcomes of my, rather simple solution, of multiple contexts and login which automatically logs user in to all of them, no matter which one of the is used to log in.

The contexts are web and pl, where each of them have own translations handled by Babel.

Here's what I did to make the login work for all of the contexts:

I tried using placeholder in Login call &contexts=`pl,web`
I checked users and their user groups, both users and their respective user groups have access to all contexts and its resources
I tried assigning postHook to Login which would log in user to all contexts as suggested by Bob in this https://forums.modx.com/thread/82028/allowing-member-access-to-multiple-contexts post
I also tried changing session_cookie_path to "/" as mentioned in this post https://forums.modx.com/thread/?thread=79375&page=2
I cleared the cache, flushed permissions and flushed sessions every time a change has been made

Only postHook worked for me but since it has been applied, the redirection after login does not work...
It logs in user properly but refreshes the same page instead of performing redirect

I'm out of ideas at the moment so maybe someone here knows what may be causing this behaviour?

Regards [ed. note: ellipsis_89 last edited this post 11 years, 9 months ago.]

I'm guessing here, but I think you may be trying to redirect across contexts. If you put a snippet with this code on the Login page, it will tell you what context you're in at that point, which could help figure things out. If the redirect works when the target page is in the same context, that will help prove my theory:




You might be able to do the forward yourself in your postHook with something like this:



I don't know if that would work, and there's a good chance that someone else knows a better way to solve your problem.

Thanks Bob, your code snippet got me in the right direction for my problem.
This is my setup:
- Login snippet is on resource in web context
- after login, user should be redirected to site start of 'private' context

This was not working, it was like the redirect could not be made cross context. There was no redirect, but I was logged in.

Bob's solution worked for me after I switched 2 lines: I had to switch contexts before I could make an url with $modx->makeUrl. Otherwise I got the error: 'Attempted to redirect to an empty URL'.

Just posted this in case anyone else runs into this problem.

Another solution might have been to add the other context to the Login tag's &contexts property. I'm not sure it existed at the time of my previous post.

Tried that already, but didn't work for me...

However when I use your snippet, I just found out I get new problems with Wayfinder not displaying a menu from the other context (in private context I want to display a menu from web context). Now I've got it working by setting loginResourceId to a resource in web context, and in that resource calling a snippet that redirects to the site start on the private context.. And that works, strange isn't it?

Contexts seem to be quite problematic!

I avoid them whenever I can.

There's a section in my book with the heading: "Do You Need Another Context?"

And that is precisely why I arranged for Bruno to develop migxMultiLang. A set of MIGx TVs, one for each language, is much easier to deal with.

Thanks Bob and Susan... I wish I had known this earlier ;-)

Contexts seemed to be the best fit for our needs: a public web context and a private context for logged in users, in a separate subfolder. (domain.com/private). I thought it would be easy to set the ACLs and so on. I guess we really need to buy your book!

Bob, I did get the Wayfinder menu to work again and it had nothing to do with switching contexts, I'm ashamed to say it was a stupid typo on my end . Susan, migxMultiLang looks great! But it doesn't give you the means to set access permissions like I need to do right? But for a multilanguage site it looks like a great solution.

There are definitely some advantages to putting private Resource in a separate Context, but it's not all that difficult to just put all the private Resources in a Resource Group and protect it, which would avoid the need for a separate Context.

Quote from: BobRay at Feb 01, 2014, 06:47 PM

Another solution might have been to add the other context to the Login tag's &contexts property. I'm not sure it existed at the time of my previous post.

[[!Login? &contexts=`web,private`]]

I have the same issue, this is not working for me. I used babel for multi-language.