If I setup a view that only allows authenticated users to access, pre-authorised users can unexpectedly access the view as well. This is of course a bug. I can reproduce it on two of my setups.

Comments

hunmonk’s picture

hunmonk commented
Status: Active » Postponed (maintainer needs more info)

please disable all contrib modules, check your permissions, and then perform some tests to see if pre-auth users can access any core-permissioned areas that they should not be able to. for example, if auth users have access to comments, and pre-auth users don't, is this working correctly?

if this is working correctly, then enable views again (and only views, no other contribs), and see if your permission problem still persists. if it does not, then turn on your other contribs one at a time until you find the one causing the problem.

please report back with your findings.

mun’s picture

mun commented

Hi,

I've disabled all contrib modules and the problem persists. It seems to only clash with Views and not core-permissioned areas.

Thanks

hunmonk’s picture

hunmonk commented

what views modules are you running? just views API and views UI?

mun’s picture

mun commented

Yes that's right. It's version 6.x-2.6.

mun’s picture

mun commented

When I check the roles of a pre-authorised user, there are two roles: authenticated which is checked by greyed out, and pre-authorised, which is checked. Should authenticated be checked but greyed out?

mun’s picture

mun commented

I've just had a quick look at views.module and it appears that it assumes all users with an uid are authenticated:

function views_check_roles($rids) {
  global $user;
  $roles = array_keys($user->roles);
  $roles[] = $user->uid ? DRUPAL_AUTHENTICATED_RID : DRUPAL_ANONYMOUS_RID;
  return array_intersect(array_filter($rids), $roles);
}

So if I setup a view that only authenticated users can access, pre-auth users will be able to access it too.

hunmonk’s picture

hunmonk commented
Project: LoginToboggan » Views (for Drupal 7)
Version: 7.x-1.x-dev » 6.x-2.6
Status: Postponed (maintainer needs more info) » Active

because core doesn't manage the auth user role via the database anymore, logintoboggan must dynamically unassign the authenticated user role when a page is loaded. any module that is manually messing w/ roles is going to screw that up.

i don't think views should be adding in auth/anon to the roles array -- i global $user object should already contain those as added by core where appropriate, at which time logintoboggan can remove the auth role where necessary in the page init.

reassigning.

merlinofchaos’s picture

merlinofchaos commented
Project: Views (for Drupal 7) » LoginToboggan
Version: 6.x-2.6 » 7.x-1.x-dev

If login toboggan is re-defining what authorized user means, then it has to deal with this. Views just goes by what core does.

I would recommend in this instance not using 'authenticated user', or login toboggan implementing an alternate role filter since it's redefined the roles. Or using a permission string. There are many ways to deal with this.

hunmonk’s picture

hunmonk commented
Project: LoginToboggan » Views (for Drupal 7)
Version: 7.x-1.x-dev » 6.x-2.x-dev

examining sess_read() and user_load(), both core functions take care of handling anon/auth user roles. IMO it's views bug that it's doing it manually -- it shouldn't be overriding what core does there, because core is already handling it correctly.

looks like a one-line patch to views would fix the issue -- i nominate mun to do it since he wants it fixed... ;)

dawehner’s picture

dawehner
Primary language German
commented
Status: Active » Postponed (maintainer needs more info) 
$account->access && $account->status

Is this the check to find out whether a account is really active?

esmerel’s picture

esmerel commented

Given the back and forth on this issue, I'm going to leave it another week, but if it's still inactive then I'm going to close it.

esmerel’s picture

esmerel commented
Status: Postponed (maintainer needs more info) » Closed (works as designed)