Starting authenticated session in a different context

Security
1

I had a script that was previously working (a year or two ago) that was able to receive a request in the web context and authenticate the user into a different context, then forward them to a restricted resource. Not sure what’s changed in the last couple releases, but this no longer works. Is this still possible?

I’ve tried:

$modx->user = $modx->getObject('modUser', array('username' => 'myusername' )); 
$modx->user->addSessionContext('key');

and I’ve tried:

$login = $modx->runProcessor('security/login', array(
    'username' => 'myuser',
    'password' => 'password',
    'addContexts' => 'key'
));

Both these options create a session token and return true for $modx->user->isAuthenticated(‘key’) but when I actually visit the context I’m still shown the login form and can’t access the restricted resource.

Yes, I have verified that the username in question is part of the correct user group with the right permissions, I’m able to access the documents I need to when I’ve logged in via the login form.

The script also works just fine if I use it in the context in question, but it doesn’t work from outside the context.

Any thoughts on what’s changed that would prevent this? Very frustrating. Worst case, I can run the script on all the contexts in my instance, but I really wanted it to be context gnostic and run from a single URL within the web context.

Any help would be appreciated.

Site is running on MODX Cloud, version 2.7.2, PHP 7.1

2

Any chance there are different (sub)domains at play here, causing session cookies to not persist/be shared between the contexts?

Even a www subdomain vs a different one could be a problem if the session_cookie_domain is not set specifically to .domain.com.

3

Yeah, there are subdomains, but there were before as well. Thanks for bringing up session_cookie_domain, I expect that’s the clue I needed. I tried an explicit setting, but it didn’t help, so I’m betting this is an issue with cookie consent. I hadn’t thought of this as a client-side issue, but we have a cookie consent system running on these sites now, which is a fairly recent change, and that may be what’s causing the problem.

4

Just to reiterate as it’s easy to miss (not saying you did - but someone else coming across this in the topic might): when configuring the session_cookie_domain setting explicitly to share a session cookie between subdomains make sure it’s prefixed with a dot: .domain.com.

I’ve not personally worked with cookie consent tools, but is that actually able of intercepting cookies set server-side?

Could also try changing the session_name to make sure fresh session cookies are served.

5

Thx. Yeah, I did preface it with a dot, tried *.domain.com as well (with the correct domain, obviously) but both actually prevented login altogether, so I’ll keep experimenting. Will try session_name as well.

Perhaps I’m misunderstanding (always likely), but my assumption is that anything cookie related is stored browser-side, so cookie consent tools would be able to remove/manipulate them.

6

Just know that if you change ANY of the session related settings, you need to completely clear all cookies from your browser or login will not work because of the existing invalid cookies. This is an extremely common issue when changing session_cookie_domain, session_cookie_path, session_name, etc.