Assigning a ressource-group to anonymous or logging-in without creating a user

For a website, where users are authenticated via an external site, I want to assign the externally authenticated, anonymous web user to a ressource-group to give her access to otherwise restricted docs.

What I would like to prevent is creating a new user, for every newly authenticated user (like the facebook login package handles it)

Is there a way to give anonymous permissions?
Or could I log in all those users under the same user-name?
(the second one feels wrong to me)

The site is on MODX Revolution 2.1.3

So, from an external site...
Firstly, MODX encapsulates the valid access within its environment, by checking its own session.
There is no anonymous permission to the restricted docs. It's simply not logic.
There must be several ways to manipulate this, and I will try to give a shot my own thought.

Objectives:
1. Cloning the users between those different domains.
2. Activating the valid user's session by using a 'bridge' snippet.

Procedures:
1. I always think that the MODX installation is an advanced distro, because in this distro the core/ folder can be moved to outside of the web root. What we'd need in that core/ folder is the $modx object.
2. Create a hidden but published resource with a plain blank template, with the 'bridge' snippet in it, and nothing else. This resource is the one that will pull the $modx object for your external site.
3. This 'bridge' snippet will check the MODX's user database whether the user is in the specified group with several permissions. This 'bridge' snippet will ALSO add the new user in parallel with the external site's user registering.
4. Your external site have a script that loads the MODX's restricted resource by using a cURL or file_get_contents. But check this benchmark before you choose.
5. That script is also responsible on registering the new user to the MODX's system.
6. You can use cross-domain AJAX to do this.

That's roughly.
Btw, it's a complicated work, I suggest you don't do this way.
Why do you want MODX serves as a 'slave' site?

Thanks, for the reply.
I have no direct control over the authentication. It's provided by a third-party,
I have a login-page (modx) with an iframe which references the third-party login-form.
The users authenticate with that third-party server.
The server then redirects to a page on my modx-setup with an md5 hash in the GET-Request.

A snippet checks the hash and, if ok, should let the user enter view private pages.

I'm not allowed - by terms of service - to store user info form the auth-server on my modx-site.

I thought of flagging an authenticated user in the session and use a plugin to redirect unauthenticated users from private pages to the public login page.
Just thought ressource-groups with permissions would be more elegant.
Looks like I have to learn a little more to write elegant code though.

My two options right now are:
1. Redirecting all users from private pages to login unless they've got my flag in the SESSION.
2. Creating a user with access in the manager and log-in all those externally authenticated users with that single user.

Any thoughts?

[edit: tried to better describe my problem] [ed. note: saschame last edited this post 15 years ago.]

Quote from: saschame at Sep 03, 2011, 12:18 PM

I'm not allowed - by terms of service - to store user info form the auth-server on my modx-site.

I assume you can at least store their username since they are typing it to authenticate with your site? If so, you can simply override the modUser class, and create a user record (with no other data; you don't have to store anything else) for the authenticated user when they login, to allow MODX to work as intended. This is how the Engaged Add-On I wrote for JanRain's service of the same name works, though it does store some profile information if allowed.

Thanks, Jason.

I'm not allowed to grab the username, but they supply a unique ID-string, which I could use as a username.

I'll look at «Engaged», thanks.

hi,

i've done that sort of things a few months ago (an Evo site but well, i assume that it would work in Revo too)

to achieve this i've simply made an intermediate page that is the page the external login targets.
This page only contains a snippet that checks if a md5 stored string matches the one passed with the login, if yes, add a $_SESSION var to the native modx ones and then header location...
this being done, on the reserved pages you've just got to check if this var is set. You can also check this var to display or not some menu elements linking to those private pages

quite easy to do and not ressource gready

have swing

This page only contains a snippet that checks if a md5 stored string matches the one passed with the login, if yes, add a $_SESSION var to the native modx ones and then header location...

@virtualbear
That's exactly what I had in mind, at first.

But then I need to track all the restricted pages by hand (hard-code doc-ids into the snippet and such).
That's why I'd like to go with ressource-groups. It feels more MODX-native.

@opengeek
I'm still looking into Engaged. I'm not very comfortable with extending modUser and packaging and stuff.
But I think, I'll take the parts with creating users from it.

Man, there's a lot of new stuff to learn with Revo.