Plugin feedback - deny context access to anon...

I noticed in Revolution that anon users are allowed to access any new context, even if you don’t explicitly give them permission to do so. I think this is a bug (there’s even a bug report for it: http://svn.modxcms.com/jira/browse/MODX-1969), so until it gets fixed, I came up with the following plugin to allow only a single HARD-CODED user to access the context in question:



Is this a good "quick-n-dirty" solution for now? It seems to work, but I’m new to plugins, so I thought I’d ask in case I’m missing something obvious (like maybe it would break with some URL hacking or something).

You could also add a context access ACL giving access to that context to the admin (just like the one that gives the admin access to the ’web’ context). That should protect it from everyone who isn’t granted explicit access to it.

Right-click on the administrator user group and select "update" to get there.

BobRay: I’ve tried that, but I’m afraid it doesn’t work! :-( I IRC’d with Jason Coward (OpenGeek) about it a few days ago, and he said it looks like a bug, so he filed a bug report for it. So it looks like it’ll be fixed in some future version. This plugin is just supposed to be a temporary band-aid until it’s fixed.

Thanks!

FWIW, I just reported the bug based on our IRC conversation. It still needs to be reproduced to determine if it is actually a bug or if there is some problem in your usage.

It wouldn’t be the first time I’d been the cause of a "stupid user" error! ;-)

Okay, well, here’s my setup:

-Revolution 2.0.0-rc-1 rev6614

-I’ve created my subdomain and context per this guide: http://svn.modxcms.com/docs/display/revolution/Creating+a+Subdomain+from+a+Folder+using+Virtual+Hosts

-I’m using the plugin here: http://svn.modxcms.com/docs/display/revolution/Using+One+Gateway+Plugin+to+Manage+Multiple+Domains
to switch contexts based on the subdomain.

-I’ve given the "Administrator" user group the "Administrator" access policy in the new context. No other permissions have been granted to this context.

-I have caching turned off.

With this setup, I’m still able to access pages as an anonymous user. I’m pretty sure that I’m really logged out when I try, too, since I have a call to "[[username]]" in my template, and upon logging out I see "(anonymous)" in the template.

Is anyone else able to reproduce this?

I assume that it’s a Context Access policy and not a Resource Access Policy and that you tested it from another browser where you’re not logged in to the manager (clearing any cookies in that browser to make sure) and flushed cache, permissions, and sessions first in the Manager.

I’m pretty sure I tested this and it worked OK here.

Yes, it’s a context access policy. And yeah, I tried it out with another browser. :-( Wonder what I’m doing wrong?

Oh hey, I just noticed that you’re the "Bob" from bobsguides.com . Thanks for your website, I’ve learned a lot from it!

Anyway, when I noticed my problem with anon access, I went hunting for info on it. I actually ran across your website, wherein you say:

"Nothing you do in a Context Access ACL will affect which documents any user can see in the front end. That can only be done in a Resource Group Access ACL specifying a Context other than the "mgr" Context."

(http://bobsguides.com/revolution-permissions.html)

This jived with my experience (since I seemed to be unable to restrict access with a context ACL), and is actually what spurred me on to chat on the modx IRC, where I met Jason.

You’re right, (thanks for the kind words). I guess OpenGeek will have to straighten both of us out.

Now that you’ve refreshed my memory (with my own site, LOL) my understanding is that Context Access ACL entries only affect access in the Manager and that you need to put resources in a Resource group to block access in the front end. I could definitely be wrong, though. I wrote it after having the same experience you did.

Gotcha. Okay, well, when I showed your page to OpenGeek, it seemed that he had the impression that it wasn’t supposed to work that way (i.e. that context ACL’s SHOULD be able to restrict access on the front end), but I could have misunderstood him.

Thanks for your feedback!

Though now that I think of it, we still haven’t answered my original question! Is my [short] plugin in the first post a suitable workaround (regardless of whether or not it’s supposed to work that way)?

Thanks!