Access, roles and users

[bwakad]

Would be nice to have a thorough explenation how to setup access. It might be me, but I never succeeded in setting this up the right way (at least, what I would like). Going to Access does not explain a lot. Docs neither.

Example :

permissions - I can add a new one. But what to do with it? it just has a title and name field...

users - I can add users, and asign roles...

roles - I can check what permissions they have, but how do you handle this in frontend, especially with new permissions.

I find under permissions the "page-view (required)" rather confusing. If it IS required, why put it there?

I would like to see a PW native function or something that said:

find all pages - from this directory - but show only - if they have certain roles (page-view)

That way, page-view would make sence to me. But as I said, it could just be me...

[totoff]

no, it's not just you ... +1

[teppo]

ProcessWire uses quite basic RBAC system and it probably just didn't feel necessary to dive further into this. Some of the basics:

• Each user has one or more roles; "guest" is always assumed and required, even for non-logged-in users (i.e. visitors)
• Each role is a named collection of one or more permissions; page-view (as you noted before) is always assumed and required and only displayed because, well, it's there (that's actually supposed to be helpful; you don't have to guess which permissions this role might have, what you see is what you get)
• Permissions are just permissions, there's nothing really magical about them; for the most part they're just Pages with special purpose
• Each Page uses a Template and each Template has access settings, where you can define which roles have access to the basic actions on Pages using said template: view, edit, create and add children

One important thing to note here is that an user having a role with page-edit (or page-view) permission won't instantly allow that user to edit / view all pages but it is a prerequisite for giving this kind of access at Template level (via access settings). Template level access settings are just one use case for the access control system in ProcessWire; it actually goes a lot further and is much more versatile than that.

(Admittedly this part does sometimes cause confusion and thus it might be worthwhile to document it more clearly.)

Programmatically managing and/or checking for roles/permissions is explained in the docs. If you want to check if user has specific permission, whether that's built-in permission or one you've added yourself, it goes like this:

$john = $users->get("johndoe");
if ($john->hasPermission("read-the-docs")) {
    echo "Sure thing, go ahead: http://processwire.com/api/";
}

Cheatsheet also provides basic info on most (if not all) actions you can perform on/with users, roles and permissions.

If you use $pages->find(), it should already only return pages that current user has view access to (unless you add "include=all"), so I'm not entirely sure what you're referring to in your last comment. Pages don't have roles, they have a Template, and that Template has access settings. If current user doesn't (via one of her roles) have access to view that Page, it won't be returned by $pages->find() either.

Note: $pages->get() is different from $pages->find(), as it assumes you really want that one, specific Page. It always returns the Page (if it exists) without considering permissions.

[bwakad]

Well, you certainly made effort in trying to explain!

... so I'm not entirely sure what you're referring to in your last comment. Pages don't have roles ...

Just to clearify this:

find all pages - from this directory - but show only - if they have certain roles (page-view)

They would be the current user...

I can add a role, and I can add a user.... A user is a page;

I can add permissions to a role, and I can add a user (page) to a role;

At this point my page has a role, but you say it doesn't  !? Sorry if this is a bit confusing...

Now, this is clear (it's definitly not in the docs!) :

$user = $users->get("johndoe");
if ($user->hasPermission("read-the-docs")) {
echo "Sure thing, go ahead: http://processwire.com/api/";
}

From this I understand, that whatever permission we set, has nothing to do with API and It's more like a text-placeholder to allow or disallow through template by just calling this string... while all this time I thought it was to set things in back-end that would not anymore needed to be restricted by if/then/else inside templates...

Is page edit something to allow a user to edit the page by back-end?

[Martijn Geerts]

Now, this is clear (it's definitly not in the docs!)

it is, but not much written about it https://processwire.com/api/variables/user/

From this I understand, that whatever permission we set, has nothing to do with API and It's more like a text-placeholder to allow or disallow through template by just calling this string

What you see is the pagename, it's just a page object, as it extends Page. If you give a user a permission, you could check if the user has that permission. As permissions is the parent of a permission, you could get that permission by page name. (Pagenames under the same parent are unique).

Is page edit something to allow a user to edit the page by back-end?

It's a permission you could set on template level. You could ask if $page->editable() (for current loggedin user), which returns true or false. So this can be done on front-end and happens in the backend to. It is used for example in the hookable ProcessPageListRender::getPageActions. (Pages list) So, if the user has edit rights, show the edit button after the page.

Edited September 8, 2014 by Martijn Geerts
Show the usage of $page->editable() in admin.