auth0.redirect_uri context setting for multiple contexts?

[claytonk]

I'm using Auth0 for manager logins on a multi-context site and have run into a problem.

Maybe I'm missing something, but without the ability to override the auth0.redirect_uri setting via context settings I can't find a way to start a manager session in the correct domain for each context, and without the ability to do so the site editors can't preview unpublished content in every context, only the context using the domain in the auth0.redirect_uri system setting.

I don't want to hack your source, so I'm wondering if there's a way to do this I'm not aware of.

Thanks for this extra by the way, it's saved me a lot of headaches now that my primary client is mandating Auth0 SSO for all their sites.

[sepiariver]

Hello @claytonk let me dig around in this a bit

I realize it’s restrictive currently

Maybe if I can learn about how the feature can be locked down—do you have editing context settings behind ACLs?

By the way there’s a newer version 1.3.x in the repo but not uploaded to modx.com yet. Might want to deploy on dev and see if it gets you anything, in the meantime

[claytonk]

Thanks or looking into it, and thanks for the heads-up on v1.3, I'll update and see if that helps.

Context settings are not affected by ACLs.

[claytonk]

Doesn't look like 1.3 alters the problem in any way. The init function pulls the system settings and passes them as a config array to the SDK, there's no check for overrides. I can hack a quick fix that passes an alternate URI via additionalParameters for now, but it would be great to have at least context-level overrides.

BTW, another suggestion: I've had to alter the login snippet to allow redirecting to the manager via defined URI instead of using a resource ID. I know you didn't build this for manager logins, but it might be a good idea to include some way of redirecting to the manager.

[sepiariver]

Ok so there are a couple options:

1.Provide a system setting to allow context setting override. This means anyone with access to edit context settings can entirely control the behaviour of Auth0
2. Maybe this can be restricted to the redirect_uri? This URI will receive user data, so misconfigured it can be a leak, however the Auth0 tenant has a setting for allowed refirect_uri, so maybe it’s ok?
3. Give point 2, maybe I just let redirect_uri be overridden at the Snippet level, which can have context_key or whatever you want passed in?

Thoughts?

[sepiariver]

And…about the manager thing, I can look for a non-numeric valid URL value in the snippet and allow redirecting to that…would that help? Should it be restricted by domain in any way? Some sites have manager on a different domain

[claytonk]

Ok so there are a couple options:

1.Provide a system setting to allow context setting override. This means anyone with access to edit context settings can entirely control the behaviour of Auth0 2. Maybe this can be restricted to the redirect_uri? This URI will receive user data, so misconfigured it can be a leak, however the Auth0 tenant has a setting for allowed refirect_uri, so maybe it’s ok? 3. Give point 2, maybe I just let redirect_uri be overridden at the Snippet level, which can have context_key or whatever you want passed in?

Thoughts?

I don't think any other settings need context-specific overrides, so 2 or 3 would be fine with me. In my case, the Auth0 tenant does restrict callback URIs so I don't see a security issue with option 2.

[claytonk]

And…about the manager thing, I can look for a non-numeric valid URL value in the snippet and allow redirecting to that…would that help? Should it be restricted by domain in any way? Some sites have manager on a different domain

Yes, that would help, that's essentially what I'm doing currently, only I'm passing the value as a relative path, so it keeps the current http_host, which works for me. If you want to restrict it to full, valid URLs, that's fine too, not a big difference. Not sure if restricting by domain would be necessary. If the domain isn't the same as the resource the snippet is called on the manager session won't be accessible anyway, unless I'm misunderstanding.

[claytonk]

I don't think any other settings need context-specific overrides, so 2 or 3 would be fine with me. In my case, the Auth0 tenant does restrict callback URIs so I don't see a security issue with option 2.

I might be wrong on that now that I think about it again. There could very well be instances where an admin may have a large number of contexts and would like to run different tenants or apps on different contexts. Maybe that's just not a realistic solution. I don't allow any site admins access to context settings unless they are entity administrators, so it's not generally a problem, but I can see how it could be. Maybe an option to replace the system preferences with a JSON config file?

[sepiariver]

Thanks again @claytonk these are all good points and I'll be referencing this thread specifically while working on 2.x, which will be the next release. It just made more sense with the changes contemplated here, plus a big refactor that has been on the table for years...

I'll leave this issue open until that release it out and the criteria raised here have been satisfied (or at least addressed if not satisfied :)

[sepiariver]

Hi @claytonk I have a new major version pretty much ready (needs a whole lot of documentation)

What is your availability to take it for a test drive in a multi-context scenario like that described in this thread? There are some potentially breaking changes so I'd strongly advise against deploying to production just yet, but maybe you have a dev or staging instance that fits the bill?

[claytonk]

Sorry for the slow reply. I'm actually starting on a staging instance with 3 contexts early next week, so I can certainly text a new version if it's ready. Let me know.

[sepiariver]

No problem at all @claytonk :)

please send me an email (my address is in my GitHub profile) and I’ll get the package over to you