Context - Resource Groups Problem

Hi all,
I can’t get Resource Groups in other contexts than the default web context to work properly.

I’ve created a context called "mitglieder" for a subdomain which should contain member only pages. The subdomain-context works for non-protected pages, but pages with a resource group assigned are blocked in the front end while being editable in the back end. The pages are block for all users in the front end whether they have the resource group access added or not, even for the admin with the additional resource group accesses.

To make this problem even more interesting: Firefox,Chrome and Opera (newest version each) block these pages to all, IE 8 does not block the pages for user with appropriate rights (I made sure Browser caches were cleared before testing this repeatedly).

I attach screenshot of the settings I use. Is this a bug in the Revolution version I use (MODx Revolution 2.0.4-pl2)? Or have I missed some setting?

-Andrea

I think I found the problem:

Firefox, Chrome and Opera seem to need front-end login for displaying the restricted pages, IE 8 shows the pages whether you are logged in in the back-end or in the front-end.

Is there a way to get the other browsers to behave like IE 8 in that respect?

-Andrea

Could it be a cookie domain issue? If you’re logged in to www.domain.com, and view the front-end at domain.com (or vice-verse) you won’t be logged in; you may have inadvertently used the other domain with the other browsers but the same domain with IE.

I’m not sure.

The workflow was identical for all browser:
1. I logged into the back-end.
2. I edited one of the restricted pages
3. I clicked on preview to view the restricted page. After that I tried to view the page by copy&paste the URL from IE to the other browsers while being logged into the back-end of the other browser.

-Andrea

Did you attach a policy to the Resource Group in the front-end contexts? If so, did you make sure and give anonymous users access to the Resource Group in those contexts? Adding a Resource Group policy to the mgr context controls access in the manager interface; the others control access in the context in question.

Anonymous users have "Load Only" access in the contexts of web and intranet.

I’m a bit confused about what you said regarding Resource Group access to the anonymous group. Giving them more than "Load only" would render the Resource Group useless, wouldn’t it?

When I add a Resource-Group policy of "Load only" for the intranet context to the anonymous group, the only thing that changes is the kind of error page shown: The others browsers (Firefox, Opera, Chrome) show the unauthorized page instead of the error page when the user is logged in into the backend only. IE behaves as before: showing the restricted pages to the user when he is logged in into the backend only.
As before I made sure to clear the browser cache and all cookies before testing.

Should there be a Resource-Group policy of "Load only" for the anonymous group?

-Andrea

Update

This is getting even more weird. Because my workflow was first logging in to back-end, then viewing front-end, I overlooked a weird behavior of IE 8:

This time I went to the front-end first and tried to log in. As a result the error page was displayed. After that I logged into the manager and refreshed the error page in the front-end. As a result the landing page of the intranet was displayed and I could view and navigate the restricted pages in the front end. Then I logged out of the intranet in the front-end and then tried to log back in immediately after, the error page was displayed again (I was still logged into the back-end until this front-end action). This login trial lead to a logout in the back-end. A refresh of the back-end window lead to the manager login page.
I’ve tested this repeatedly and cleared the cache of all cookies beforehand. Firefox and Chrome let me login and logout of the front-end without affecting the backend.

-Andrea

P.S. This IE behavior is related to the intranet context. I can log in with IE8 using a front-end log in into restricted pages of the default web context. I attach my configuration of the intranet context. Is there anything I should add or change so that IE 8 can be used for a front-end login into the intranet?

P.P.S. I have to correct myself. I’ve tested again. I can’t login in the front-end using IE8 no matter what context the page belongs to.

Back to my theory, that the inability to log into the front-end with IE8 IS related to the non-default intranet context:

Further tests showed that an unsuccessful login into the intranet context seems to lock the login for the restricted pages of the default context. Only after clearing the browser cache AND the modx cache I can log into the restricted pages of the default context. Still not able to log into to the non-default intranet context with IE8. Which is bad, because the clients use it.

Does someone has an explanation for this? And maybe a "cure"?

-Andrea