[Login] Trouble getting member only pages to work with Login in Revo

yea - that’s the tutorial I’ve been using, just about to try it again.

-sean

Quote from: Mark at Jul 15, 2010, 09:03 AM

I’ve started writing a tutorial... can be found here: http://svn.modxcms.com/docs/display/revolution/(Tutorial)+Making+member-only+pages

Check if you did everything.

Open another browser to check (another browser, not just another browser window or tab).

By default, if you don’t give anonymous users permissions to "load" the resource they will get a 404 error. There’s a section in Bobs’ guides about that.

mother-francis that was confusing.... I think I found the problem [well it’s working now]

Something to add to your tutorial, ’check that the user has a role’
also, when flushing permissions, that user you are trying to test has to log out then log back in again in order to see the changes in access.

-sean

Quote from: sean69 at Jul 15, 2010, 10:01 AM

also, when flushing permissions, that user you are trying to test has to log out then log back in again in order to see the changes in access.

FWIW, you can flush sessions to force all users to be logged out when making security access changes.

OK - what the heck is going on here..... If I flush all my browser caches then delete all cookies and disable cookies entirely -

I can see all the protected pages from my resource groups, I can see them and access them!!!

that can’t be right, what could possibly be happening there????

-sean

Did you protect them in the mgr or web context?

hmmmm it seemed to have something to do with Bobsguide

* Create a new Access Policy called "Load" and add a single Permission: Load.
* Create a new Resource Group Access ACL entry for the anonymous User Group with the Resource Group of the protected resources, a Context of "web," a Role of "member" and an Access Policy of "Load." Do this for each protected Resource Group

I removed that and it appears to be working again [as expected]

But still some other little oddities... I have:

[[!Login? &loginResourceId=’59’ &logoutResourceId=`61`]]

for login, but it seems to only redirect to the login page if you have not already started browsing the site otherwise it logs you in and stays on the current page ... ok - that makes some sense.... but I do need to enforce a login page....

rrrrr.
-sean

Quote from: sean69 at Jul 15, 2010, 01:46 PM

hmmmm it seemed to have something to do with Bobsguide

* Create a new Access Policy called "Load" and add a single Permission: Load.
* Create a new Resource Group Access ACL entry for the anonymous User Group with the Resource Group of the protected resources, a Context of "web," a Role of "member" and an Access Policy of "Load." Do this for each protected Resource Group

I removed that and it appears to be working again [as expected]

That is to be able to get a 401 response vs a 404 response on the front-end. Without the load attribute (if these Resources belong to a protected Resource Group in the web context), anonymous users will not even know the page exists, nor will they be able to load that data when the site is accessed (thus the 404 vs. 401). However, they should not be able to browse the page if another User Group besides anonymous is tied to a Resource Group the Resource belongs to in the web context.

Quote from: sean69 at Jul 15, 2010, 01:46 PM

But still some other little oddities... I have:

[[!Login? &loginResourceId=’59’ &logoutResourceId=`61`]]

for login, but it seems to only redirect to the login page if you have not already started browsing the site otherwise it logs you in and stays on the current page ... ok - that makes some sense.... but I do need to enforce a login page....

It should only do that if redirectToPrior is set to 1 (or Yes in a property editor). I thought the default was 0. Hmmm...