How to block/redirect one User Role away from Admin Pages

[Peter Falkenberg Brown]

Dear All,

I've created a 'member' user role, and would like to block users with that role from seeing the Admin backend.

Instead, if they do go to the admin login, and then log in, I'd like to redirect them to to a specialized log in page for members,

where I'll do some redirections based on their account details.

I also want to modify the standard login screen, and place some explanatory text on it, but I searched for the word "Login" for example, and couldn't find which file to edit. I must be missing something.

I've copied the 'templates-admin' directory to my site directory, and have examined the default.php file.

But when I put some code into the file to test for the superuser (just as a test, since I actually want to test for the 'member' role), I ended up blocking the login page. So, even the superuser couldn't log in.

I believe I placed that code in the wrong place.

Does anyone have any tips? I want to block all access to the admin pages, but I still want to allow a member user to add and edit data using custom forms.

Thanks!

Peter

[adrian]

Peter,

Not sure if this really answers your question, but members do not need create/add/edit rights, or any rights that allow them to see the admin panel. You can still create custom forms that allow them to add and edit data. Even a guest user can submit a form that updates a page. Although I think you already probably know this, but just in case it helps

[Peter Falkenberg Brown]

Dear Adrian,

Yes, that makes sense. After hours of reading PW forum posts, my brain is fried.

But... I still need to block the admin backend. I'd love to edit the admin backend, to keep all the great things there, but I noted that Ryan said it was a bad idea to hide sections of the tree, that are only viewable, but not editable, by certain roles. But for my "admin" pages for users, I don't want them to see anything that they don't need to. I also want to heavily customize the look and feel of the admin.

So, I'm thinking now that I should just block the regular admin pages, and use custom forms with the api and hooks.

Although I was initially interested in the idea of taking an admin edit url and using that. But then I think I couldn't block the rest of the admin pages.

Peter

[adrian]

Blocking the regular admin pages, and using custom forms with the api and hooks is what I do. It is possible to make the forms match the fields for the page so you can re-use the same code anywhere. Again, sure you have seen it given all the reading you have done, but this is a good place to start:

http://processwire.com/talk/topic/59-module-want-form-builder/page-4

[Peter Falkenberg Brown]

Dear Adrian,

Thanks! I'll look at that page.

Peter

[Peter Falkenberg Brown]

Dear All,

I wanted to revisit this post. I still haven't figured out how to block the admin backend. I'm hoping that if anyone logs in with a role other than superuser, they'll get kicked out.

Any tips?

Thanks,

Peter

[kongondo]

Peter,

Have you had a look at /wire/templates-admin/default.php ? That's where the magic happens, I believe. Copy the contents of that folder to /site/templates-admin/ so that  PW will serve /site/templates-admin/default.php instead. I'm not sure about your requirements but you can pretty much redirect non-admins to other places by editing default.php, I think. I could be wrong. I'm not sure if there will be effects on the rest of the system though. Have a look at this admin theme switcher that I was tinkering with. Basically, I edited /site/templates-admin/default.php to redirect to an admin theme depending on the value of a Page Reference Field. 

Edit:

Have a look at this as well: http://processwire.com/talk/topic/3617-managing-users-and-related-pages/

Edited June 19, 2013 by kongondo

[Soma]

Why not create a custom login? The only reason to not give them admin access is if they're just front-end users. I wouldn't want my front-end user loging through processwire admin login. If you give the user no edit rights in roles they can't access the admin and get a "continue" link after login Even if you want them to manage content from frontend only I would take that route as the permissions can be defined on the fly in your temlates.

The other way would be as kongondo mentioned, and here's a code you could put in a autoload module (like HelloWorld.module). ready() is used because it get's you access to all API.

public function ready() {
    if($this->page->template == "admin") {
        if($this->user->hasRole("editor")) {
            $this->session->redirect("/somapge/");
        }
    }
}

[MatthewSchenker]

Why not create a custom login? The only reason to not give them admin access is if they're just front-end users.

Greetings,

I am also interested in this subject and looking at different methods to accomplish it.

Obviously, with community sites, we need to have a login where people go to a certain place (not the admin), and then have rights to edit or create content based on their login.  We also need to have the regular admin login.

Is the best practice here to set up a second login location, from a different URL?  For example, the admin login would be this:

www.mysite.com/admin

And the "regular" user login would be this:

www.mysite.com/login

Or would it be better to use the same login for everyone and then detect who has logged in and direct them to a different place?

Thanks,

Matthew

[horst]

@Matthew: I never would tell regular users the admin-login url. I would use different doors!

[MatthewSchenker]

@Matthew: I never would tell regular users the admin-login url. I would use different doors!

Greetings,

Horst, definitely. What I am interested in are the various ways people handle this with ProcessWire. We have several options for different situations.

Thanks,

Matthew

[Peter Falkenberg Brown]

Dear Kongondo, Soma and Matthew,

Thanks for your input...

Soma, where would you put your code example? In default.php, as Kongondo suggested? Would it be possible to

suggest exactly where in default.php, or elsewhere, you would put it, with a complete example? When I looked at default.php,

there's a lot going on. The function would have to come into play right after a log in by someone with a barred role.

I think this type of code would be very useful, even as a default module. For example, one could configure the backend to

only allow xyz types of roles, or perhaps even easier, offer an option to block certain roles. Like an include and exclude list.

For the front end:

I'm developing a scheme for members with a custom login at /members/, so that the user (who is an actual PW user with

the role of 'member') would get redirected to a custom home page just for them, on the front end.

When the user registers as a member, from a custom front end page, the script would not only create a user account, but

would also create a member home page under the /members/ url, e.g.

/members/1097-8247913542/

This would serve as an account page for that member, and offer a variety of functions for the member.

The '1097' is a standard user id, and the longer number is randomly generated, with the whole thing used

as an account number, used for authentication on every page under the member's section. I made it a hard-to-guess

number for just a bit of security, so that the account urls of other members would not be easy to guess.

I've created a set of template/field groups that all use the user_id and the account_url, and have

structured the member pages just like a regular /section/page/ tree.

Using Ryan's idea of not passing html until the end is a good idea, allowing for redirection when necessary,

but I'm not just using a master control script because I want to provide different functions for each type of

member branch or page. Thus, I'm going to create a template file for each type of page in the member section,

and simply include headers and footers, etc, but include them as variables that would get output at the bottom

of the page.

I've written apps with a huge control script, running off of one url, but the files were, well... huge. I feel now that

placing the functions that apply to one type of page or section url, in the template php file, allows those urls to

load much faster, with less overhead. I think that PW's design, in this fashion, is excellent.

It also allows an admin in the backend to easily navigate through all the members' pages, since each member's

sub-pages are all under their account 'home page', in the tree.

So... I think I've got the front end concept, but blocking the backend admin from any role that isn't a 'backend'

type of user would be a great thing.

Thanks, all,

Peter

[Soma]

Again, as I said in my previous post, if you give the user only view permission, they won't get into the backend. When they login through admin login you'll get a "continue" link that links back to the website. So without doing anything you already got those user from accessing the backend, but they still can use the admin login screen if they know it, but it's not issue at all.

In one of a project I used this technic with a front end sign in and login http://muetterhilfe.ch/angebot/online-beratung/anmeldung/

Similar to what you say, I create a user page after they successfully registered, and save that in a page field on the user. After they login they get redirected to their page with a simple profil page and form to ask questions a expert then can answer.  All the "permission" and handling is done without any permissions or special roles (just the user role with base view permission) just in the templates with absolutely basic API code. User's can't access other user pages, and this is simply done in the user page template, it checks if this really is the current user page. It all requires minimal coding and setup. It's so simple it's scary and often you think this can't be, but it is.

When I find the time I'll maybe make a write up or simple profile that shows this simple setup.

[Soma]

Dear Kongondo, Soma and Matthew,

Thanks for your input...

Soma, where would you put your code example? In default.php, as Kongondo suggested? Would it be possible to

suggest exactly where in default.php, or elsewhere, you would put it, with a complete example? When I looked at default.php,

there's a lot going on. The function would have to come into play right after a log in by someone with a barred role.

The code I posted would be in a autoload module. Instead of the init() it is the ready() because it's executed when the full API and page request is ready.

If you have HelloWorld.module put that function inside just after the init(). When you have the module installed it's active and all users with "editor" role will get redirected to "/" if they try to access admin.

[Peter Falkenberg Brown]

Dear Soma,

Thanks for your additional replies. I think I assumed that the 'member' role would have to have edit permissions, but it looks like what you're saying is that since the membership access is all controlled from the front-end, via scripts and the API, they don't need edit mode to edit and update their own pages, via the front end. Is that correct? Somehow that's fuzzy to me, because when they run a page in the front end, they're logged in as a member user, so when they hit a save button to add or edit a page, PW knows that they're saving a page to a template field set, so I would think PW would check and say, "Hey, you don't have access!"

Am I missing something?

Thanks,

Peter

[Soma]

Ah no not at all. All you do with api on front end to add or save content is non access aware and it does what you tell it to do. You could take roles and permissions into account and most likely this is what you do. PW has those checks also implemented same as you would do on your front end. The edit page screen wont load and throw an error if you dont have permission but you're not using the admin processes in your frontend so you take care through api on your own.

[Peter Falkenberg Brown]

Dear Soma,

Ah ha... thanks for that clarification! I shall go back and rework my system a bit.

The Discovery of ProcessWire continues...

Peter

[MatthewSchenker]

Greetings,

If you have a chance, please post some code on how you accomplish this.

What I'm looking for is the best method for directing different users to different pages after logging in.  Admins/Super Admins go to the admin page; editors and members (for example) go to a specified URL.

In the admin area, we can specify a URL where people go who don't have rights to see the admin page, but that bypasses the login screen.  What we need is a way to let them log in, then specify the URL they go to AFTER logging in.

Thanks,

Matthew

[Peter Falkenberg Brown]

Dear Matthew,

I'm using Ryan's code on this page:

http://processwire.com/talk/topic/1716-integrating-a-member-visitor-login-form

as a reference for my system. (Still designing it.)

I'm going to keep the normal admin login for admins and editors, with the blocks that Soma mentioned, for other users.

For the members, I'm going to make a new login page that will use the regular API functions to look them up in the user field set,

and then, based on their user id, look them up in the /member/ account data set, to grab their membership url, and then redirect them to that page, e.g.

/members/1097-8247913542/

I was thinking about putting the membership url in the user template/field set, but I'm also using the member urls as a tree in the back end,

for admins to view and manage.

I don't have the code yet, but I think the concepts outlined here, combined with Ryan's code, should work well.

I hope.

But one point is that my membership system is entirely locked down, not viewable by the public, and not even viewable by other members.

Peter

[MatthewSchenker]

Greetings,

Thanks Peter.

Looking at Ryan's code you quoted, what I am doing is actually even simpler (at the moment): just want to have users log in and be directed to a page I set up with various buttons, actions, and tables for the project. In other words, it does less than the normal admin page, but that's all the client needs.

Like everything else with ProcessWire, I'm certain that this it is simpler than it seems at first! Still, this is a crucial piece of a lot if sites.

Report back on success!

Thanks,

Matthew

[Peter Falkenberg Brown]

Dear All,

Here's an update on how I've protected the admin login url so that only superusers could login to admin, and the registered users with the role of 'member' could only access my front-end code.

If anyone has any comments or corrections, I'd appreciate them.

1. I renamed the admin url to something other than 'admin'.

2. I set the admin template to only HTTPS, so that logins are encrypted.

3. I used Soma's recommendation to set the permissions for the 'member' role to view only.

    Thus, even if they could log in, they would only see a 'Continue' link, as Soma mentioned. (Thanks, Soma!)

4. After copying the wire/templates-admin files to site/templates-admin, I added these lines to the very top of the default.php file in sites/templates-admin:

if ( $user->isLoggedin() && ! $user->isSuperuser() )
      {
      $session->logout();
      $session->redirect("/members/", false);
      }

    Thus, users who log in, who are not super users, will get logged out, and redirected to /members/.

    I log them out so that they will not be tempted to just use the admin url to log in and get redirected.

    Since I haven't yet digested autoload modules, this code seemed easier to me.

    After I work with modules, etc, I might change my mind.

5. I found some .htaccess code on the web that works with friendly urls (rather than real directories), and it tested correctly, so I added this code to the bottom of the public_html/.htaccess file (with urls / filenames changed to generic names in this post):

# set env variable SECURED if current URI is /some_admin_name

      SetEnvIfNoCase Request_URI "^/some_admin_name" SECURED

# invoke basic auth if SECURED is set

      AuthType Basic
      AuthName "Page Error"
      AuthUserFile "/home/some_username/.htpasswd"
      Require valid-user
      Satisfy    any
      Order      allow,deny
      Allow from all
      Deny from env=SECURED

Based on all of this, I have multiple layers to keep people out of the admin pages.

What do you all think about these security measures and techniques?

Edit:

By the way, I was going to use this "LocationMatch" code in the Apache virtual host file, but it didn't work. It popped up the password box, but then the browser went into "waiting" mode. I believe it's because the .htaccess file, with the definition of the admin friendly url, was defined *after* the main apache file Location code. I could be wrong. Here's the code I tried:

<LocationMatch /some_admin_url>
    AuthType Basic
    AuthName "Page Error"
    AuthUserFile "/home/some_username/.htpasswd"
    Require valid-user
</LocationMatch>

Best regards,

Peter
 

[ryan]

This is a great post–these all seem like excellent practices Peter, thanks for posting them. I'm not sure you necessarily need the extra Apache authentication, but it certainly can't hurt to have that extra layer. I'm also glad to see how that's implemented, as I didn't realize how. As an extra layer, you can also enable the SessionLoginThrottle module (that comes with the core) if it's not installed already. 

[Peter Falkenberg Brown]

Dear Ryan,

Why thank you, and you're welcome!

Yes, in a way, having three locks on the door feels very much like a New Yorker.

But I lived in Manhattan for two years, so there you have it.

I'm going to add SessionLoginThrottle. That's a good idea too!

Best regards,

Peter

[apeisa]

Steve have build some excellent modules for admin security: http://modules.processwire.com/modules/auth2-factor-ppp/ and http://modules.processwire.com/modules/session-login-alarm/

[Peter Falkenberg Brown]

Thanks, Antti. I'll check them out.

Peter