Restrictions on Access control

[mindplay.dk]

I'm setting up a site that is private - it has no public viewable pages.

First I tried to edit the "Guest" role and turn off "View Pages" - that's not allowed.

Then I tried turning off the "Guest" role on the Access tab for the Home page, thinking all the child-pages would inherit that setting by default - that's not allowed either.

Are both of these restrictions "real" and in place for a reason?

It seems the only way to set up a private site, is to go through all the templates one by one and turn off the "Guest" role for each and every one of them - not a very practical or safe approach for a site that is intentionally private by default...

[SiNNuT]

Not an answer to your question but instead of going through all the templates a workaround could be?:

if($user->isGuest()) {
 echo "login required";
}

[mindplay.dk]

Well, fortunately for me, on this particular project, I have one distinct parent-node with a distinct template, so the problem was easily solved by restricting access to that template - all other templates inherit it's security settings.

You work-around is good for sites that are exclusively private - but not for sites that are private by default, but still publish some content.

[teppo]

I've solved this problem in the past with similar solution SiNNuT mentioned; in our case all templates actually use one template file which functions as a front controller and redirects queries to actual template files, making it relatively simple to determine whether or not access should be (artificially) limited.

Would still like to hear an answer to the first question by Ryan / someone who knows exactly why this is happening. It's more than a bit annoying sometimes and this kind of solution still feels a bit like a hack

[Soma]

I'm not sure, but how would you login if you remove public access to root template?

[teppo]

I thought it might be that too, but on the other hand PW doesn't seem to have any problem with me creating a setup where one page with view access denied for guests has another page below it with view access granted to guests -- in that setup guests can still access that subpage, even though they cannot access it's parent. Or perhaps it's completely another matter when we're talking about the root page..?

Anyway, to sum it up, I'm a bit confused about what's happening here

[ryan]

Guest access can't be turned off from the homepage because that's one checkbox that has potential to take down an entire site. It's built-in to reduce support burden. And it's in response to me having clients do this on two occasions and calling me in the middle of the night because their entire site went down. How they managed to do it, I don't know. But it convinced me that I shouldn't have a checkbox that can take down an entire site. I think that Teppo's solution is a good way to go. Another would be to put this in an autoload module (though I haven't tested):

public function init() {
 $this->addHookAfter('Page::viewable', $this, 'hookPageViewable'); 
}

public function hookPageViewable(HookEvent $event) {
 if($event->return === true) {
   $page = $event->object; 
   if($page->template == 'admin') return;
   if(wire('user')->isGuest()) $event->return = false; 
 }
}

[kolewu]

But how can I change the redirection target?  The configuration is only visible if I remove the view acces to guest -- but this cannot be saved.  It looks like the redirectLogin setting is only for the guest, so I have found no way to specify another target.

Maybe it would be possible to make the Homepage a login and build the site with another tree under it. Then when the user is already logged in, she can be redirected to the real home.

So this is really a lot of work, to only work around the restriction for the home page access rights?  Could we get a site setting private site meaning: there is no guest access beside the login page(s) (admin and possibly frontend).

[kolewu]

A workaround for now: remove the view access from the guest user and change the redirect settings. Then restore the view access for guest and save the changes.

With this workaround the following module (made from ryans code above) make your site a members only site.

<?php

class AccessMembersOnly extends WireData implements Module {
  public static function getModuleInfo() {
    return array(
		 'title' => 'MembersOnly module',
		 'version' => 1,
		 'summary' => 'prevent guest access to the site',
		 'singular' => true,
		 'autoload' => true
		 );
  }

  public function init() {
    $this->addHookAfter('Page::viewable', $this, 'hookPageViewable'); 
  }
  
  public function hookPageViewable(HookEvent $event) {
    if($event->return === true) {
      $page = $event->object; 
      if($page->template == 'admin') return;
      if(wire('user')->isGuest()) $event->return = false; 
    }
  }
}

I think the redirect settings should not be hidden at all because there may be more reasons for not giving access to any user than only with access rules.

[Soma]

Can't you just put this code in your main template?

if($user->isGuest()){
   throw new Wire404Exception(); // or redirect
} else {
   // not guest
}

[kolewu]

Yes, as suggested by SiNNuT in post #2 -- but I don't like this solution:

• you do have contradictory settings in two different places: configuration has view-rights for guest, template has the opposite
• if you don't have one main template you have to make sure to include this everywhere it is needed
• you don't get the right result from $pages->get("somePage")->viewable

I would like a setting in one central place most!  Either (my favorite) a setting this is a private site that changes the behavior of the guest rights setting or a module like above that together with the change that enables redirection settings every time.