Howto ¨separate¨ the adminstration part of DRUPAL from the public site

dkaragiozov - August 10, 2005 - 12:08

Hello All,

We (development team) are implementing a site in DRUPAL (http://www.publicvoting.org) and would like to ¨secure¨ the administrative area provided by DRUPAL.

The requirement is to allow ¨admin¨ to login using one of the following options:
1) use client-server certificates;
2) restrict the admin login from a specific IPs;
3) have two instances of DRUPAL (public and admin), and the admin can login only in the admin site which is fully under SSL. I suppose two ¨instances¨ of drupal can share one and the same database but in this case how to ¨disable¨ the admin blocks and pages only for the admin site (instance)? Is it possible to identify the admin/system tables and give them other permission (different mysql user)?

Do you have other suggestions how to ¨separate¨ the administration part of DRUPAL from the public site?

Thanks in advance
Diman

good idea..

Dublin Drupaller - August 10, 2005 - 12:14

That's a good idea Diman. A site I have setup for someone else who admins it themselves gets confusing for them - one of the biggest problems is working out if "can only I see that or can everyone see it?" type thing.

Seperating out the admin section would help that.

At the moment I suppose one way of doing it would be to use the sections.module and the admin team having 2 logins...1 regular and 1 administration that takes them to a seperate themed section and the roles for each account determines what they have access to. Although that means that there is a lot of lgging in and out and remembering passwords.

Not sure if that contributes or helps...but, I think it's a great idea.

Dub

thanks for the suggestion!

dkaragiozov - August 10, 2005 - 12:18

I will try the sections.module!

Diman Karagiozov
Tetracom IS Ltd.
http://www.tetracom.com

no worries..

Dublin Drupaller - August 10, 2005 - 12:38

no worries Diman...please post back up here with how you get on..when building a drupal site for others, it's actually quite daunting for the site admins to see all the options...

I find myself switching OFF the administer menu item and creating a custom block that only appears when a specific ROLE is viewing the page...that's quite simple to do and I just insert direct links to "changing member permissions", or "moderating comments" etc. so they don't have to navigate through the administer menu.

It's a workaround, but useful.

you can also use CSS to position that block away from the core site..which is feasible if you're using a fixed width site...i.e. the special custom admin block appears in the very top right hand corner of the screen, for example.

Anyway. good luck with the sections module...and post back up here if you have time with how you got on.

Dub

I agree with

bonobo - August 10, 2005 - 14:39

Dublin Drupaller -- I follow the same basic procedure when setting up a site.

My ideas are more from a UI perspective, but I think it's important to figure out your primary objective: to improve the actual security of the admin sections within drupal, or to improve/simplify the look/feel of the admin sections of drupal.

Or both.

If the goal is to improve the look/feel of the admin section, I would recommend creating something along the lines of an "Admin Home Page" -- a page with links to the main admin features that loads when a user logs in with sufficient admin privileges. This page would load in place of the normal home page seen by other users, so the admin would see different content than non-admin users.

Thanks for working on this module. It sounds like a nice addition.

Cheers,

bonobo

------
http://www.funnymonkey.com
Tools for Teachers

I tired to hide the admin block

dkaragiozov - August 10, 2005 - 19:54

Some days ago I managed to hide the admin block, however the URLs to the admin functionalities were still working.

Hiding the admin block is a step in the direction we want to but still not as secure as the requirements define...

Thanks!

Diman Karagiozov
Tetracom IS Ltd.
http://www.tetracom.com

seems like a couple different issues here

walkah - August 10, 2005 - 17:55

if you just want a separate look and feel, something like sections.module is fine - or the civicspace theme actually uses a different (consistent) look & feel across it's variants.

However, if you're looking for security - most of what you're looking for is possible. The following might be a workable solution:

using some "$base_url" magic you could actually allow SSL & non-SSL to the same site (i.e. check for ssl and set $base_url to use https:// if in use - otherwise not).

you could also then restrict admin access by IP with a simple module, something like the following :
* have a module implement a permission - call it "restrict by ip" or something - then create an admin role that has all the other permissions required and this one as well - and make sure only admins have this role".
* this new module will then store allowed IPs (via the settings hook) and verify that accounts are using an allowed IP - via a _user hook.
* this module could also verify SSL usage - and redirect if required.

Does that sound suitable?
--
James Walker :: Bryght Guy

Sounds good :-)

dkaragiozov - August 10, 2005 - 19:52

You are right that the latest posts focus on a different issue - the look-and-feel. This is an open issue, but for my the security is more important at the moment.

I was looking for a sound solution or explanation how the scurity level can be increased, so thanks for the hints!

I will further read about the different hooks in the module and hoefuly will have time to work on it by the end of the week.

Diman Karagiozov
Tetracom IS Ltd.
http://www.tetracom.com

The way I'd approach it...

styro - August 12, 2005 - 01:47

Off the top of my head, I'd be inclined to make or customise a theme for the public that doesn't output the links and other stuff you don't want them seeing. With PHPTemplate you could also add checks into the block template that figure out whether or not it should output anything based on eg user role and block name etc. You might also need to override the odd theme function in template.php too.

See: http://drupal.org/phptemplate

Then I'd create two virtual hosts (admin and public) with the same document root but different hosts (and a different port for SSL). The admin virtual host would contain your SSL config stuff, and your IP restrictions etc. You could possibly even use the webserver auth module in Drupal for logging in via client certs (although I have no idea whether or not that would work). In the public vhost you could even configure Apache to redirect or 404 requests starting with /admin maybe?

Within Drupal I'd then create two different sites under the sites directory named after the virtual hosts - each using the same database. The public site would just contain your custom theme, while the admin site could contain any standard themes you want (you'd put the webserver auth module here too if you end up using it). You'd need to remove all the themes from the common webroot level themes directory though.

See the INSTALL.txt and http://drupal.org/node/274 for more info.

Hope that wasn't too convoluted :)

 
 

Drupal is a registered trademark of Dries Buytaert.