I have been playing with the various access modules, and having some difficulties doing what I want to do (and having it semi-intuitive for my users). I'm basically trying to put together a very basic intranet type site where employees can create/edit content and maintain/share some knowledge. I'd like some help if people could explain how'd they would setup this type of situation or maybe could point me in the right direction. Below are the basic requirements

All pages are protected from public view by default (but a few pages, like the front page, can be made public)
All pages have view and edit priviledges by default to all users (wiki style if you will, and i've got add revisions enabled by default)
Should be able to restrict edit priviledges to certain roles/users for specific pages or groups of pages (only view access)
Should be able to restrict view (and edit) priviledges to certain roles/users for specific pages or groups of pages. (no access)

here is a list of what I've tried and issues I've come across -

Taxonomy_access - This module seemed like the way to go initially, and at this point is probably my best bet, but it seems really un-intuitive for users to deal with. Plus, I want to be able to use taxonomy (and have the employees use it) to classify the pages without worrying about it affecting access.

Simple Access - the biggest problem here is that by default it leaves all nodes viewable. Plus, it requires me to setup additional access groups instead of using the groups that are already setup, which seems to lead to an additional layer of complexity and might make it un-intuitive for users

TAC_lite - This module is also nice, and at first glance seems like it could work too. It seems more tied to existing user roles, but I'm afraid this still isn't quite right. It doesn't seem to offer the flexibility of specifying read only or read/edit to different sections. Plus, it has the same issue as taxonomy access in that i don't want other taxonomies causing access conflicts.

Other access modules that don't seem to apply, but for completeness I've also investigated
Node privacy byrole - Doesn't seem to be ready for 4.7 and it doesn't really show any signs of being updated.
Node Access Arbitrator - Am hoping to only need one access module, so hopefully won't need this
Nodeperm_role - this sounded really promising, and even suggests that it will be upgraded to 4.7, but a request asking about the upgrade has been unanswered for quite awhile now.

Are they any other modules that I should invesitgate? Could someone please explain how you would setup a site's access to achive this?

To give a little more background, consider it being used for documenting the computer systems.... I don't want the public to know how the network and system is setup. I also want the employees to be able to contribute "how tos" and "tips" about the way they do things and have those tips edited by other people as the system changes. I also need to create some things that people can read but shouldn't change. Plus, there will be server setups and potentially some other sensitive material that should only be accessible to upper management or sys admins. I've also decided to go with drupal for this because 1, i like drupal and wanted to use it and 2, because this might need to grow and expand over time to include other features like a CRM package or group calendars - so if that factors into the access solution i choose now please tell me. Also, I have played with groups and am aware of its access features, but this is a very small company without different departments, so it wouldn't make sense to use that either.



alex_b’s picture


ad Simple Access variant: you CAN change the default published/not published settings in

administer -> content -> configure -> content types->configure

I implemented exactly what you are explaining in your post with a mediawiki + a restriction module. see http://www.c3mundos.org/wiki .


AjK’s picture

I've only had to do this once but here's what I did:-

1st up, install the Front Page module. That allows you to control anon and auth front pages.

2nd, in access_control I made it so that anon users could not view nodes (Admin >> access_control [node module "access content" unchecked]

3rd, I suppressed the navigation menu for anon users by using the "Show if the following PHP code returns TRUE (PHP-mode, experts only)." in the Admin >> Block [Navigation configure] and then used this code:-

global $user;
if($user->uid > 0) return TRUE;
else return FALSE;

What all this gives you for anon users is a front page and a login and not alot else.

I should add that you may need to config blocks like the navigation above otherwise they will appear. The reason I suppress the navigation (and other blocks if needed) is there's, imho, nothing worse than giving users links that lead to access_denied, esp if you know in advance you're going to deny access!


KarenS’s picture

Node privacy by role is working for 4.7 (I am using it). The 4.7 version is in HEAD, you need the cvs tarball (see http://drupal.org/node/41463).

Also, you might check out organic groups. Unlike most of the other access control systems, it defaults to hiding everything and displaying to the public only the things you specifically ask to be displayed. You said you had played with groups, not sure if organic groups is what you meant. Even if you only have one group, the access control features might be just what you need.

rcross’s picture

Yep, head does seem to work with 4.7 and it makes things much more ... umm, simple. This definitely looks more like what I'm asking for. I'll be putting this through a few tests to make sure it does what i want it to. Thanks.

I was going to mention this in my original post, but this problem brings up the more general issue of permissions in Drupal. Is it just me, or does it seem like the permissions system in drupal needs to be redone (or at least cleaned up)? To some extent I can see the benefit of having modules that provide a specific interface for different types of usage - but there doesn't seem to have these permissions options available in a default drupal install. For example, the fact that we even need a module called "node access arbitrator" seems to indicate that there are issues involved that should be dealt with in core. Personally i think this is one of the "big issues" that should be addressed in the next release similar to the way the forms api was such an impressive overhaul. Anyone else care to comment?


KarenS’s picture

I'm not expert on Drupal access control, but from the digging around I have done I think that the node access abritrator is the beginnings of an attempt to pull all those pieces back together.

rcross’s picture

yes, I agree that the purpose of the module is to integrate different access control modules - my point is that this "integration" is an indication that core needs work in this area. If nothing else an "access arbitrator" should be part of core, not a contrib module. Also, this is all a bit concerting when you also realize that non-core modules are not vetted for quality/security. So, its highly possible that someone could use a node access module for securing their site and the module could actually give the site security holes (not intentionally of course).


KarenS’s picture

The node access abitrator has been added to core in 5.0.

rcross’s picture

Hey Everyone,

Since I"m always looking for solutions to problems in the forum and always hoping for better documentation, I figured it would be good of me to do on to others as I would want others to do onto me. So, here is how I setup my intranet site and what I used.

Very basic intranet site - suitable for small groups or small business

Provide a place for employees to contribute knowledge/information as well as posting company policy/procedures. Some information is sensitive so it requires permissions to be restricted to a few appropriate roles. Of course, the entire site is protected from public view. Note: This site is seperate from the company's public website - a different setup would be necessary to integrate the two.

Core Modules Used:

Contrib modules:

What I did:

Access Control - I setup a few different roles, like SysAdmin, Management, Financial. Then anonymous users have no priviledges at all and authenticated users have most priviledges. Other roles have almost no priviledges either, except for a few administrative priviledges for SysAdmins. Then I used node_privacy_byrole to setup default priviledges for each content type. Note that authenticated users have "permissions for permissions" by default as well and by default all roles have both read and write permissions (except anonymous users)

I used the Front_page module to provide a welcome screen to any random person that comes across the site and provided links to the corporate site. Then, (as part of the front_page.module), I set authenticated users to redirect to the "node" page - this allows "post to front page" to actually work. Note -I was glad to find I didn't need to enable anonymous users any permission to "access content" and front_page still worked - however, it does restrict the site just a little and makes it impossible to make any content inside the system viewable by the public. At the same point, this is how the site is supposed to work so I decided not to worry about it plus any information that should be available to the public should be published on the public website (yes that does include minor duplication of effort but worth it)

I setup the glossary.module and enabled the input filter in the default filter. I also used the urlfilter as well. I included the freelinking.module but it caused a few issues which I seemed to have resolved in an "ok" manner, by putting the filters at different weights. It goes html filter -> line break ->freelink->urlfilter->glossary. I'm still not 100% happy with the freelinking module and I might remove if i get any complaints from users. I mainly wanted it so they could easily link to other internal pages without needing html.

Used the print module and enabled it for authenticated users - also uploaded a different logo to use for the printed pages. Nothing important here.

I used the statistics module to give a rudimentary "tracking" of different users actions. Semi interesting to look at now as I can see what people are doing upon their first login and how they are exploring bits. Will probably not have much interest after the initial period unless I need to track "problems" - like an angry employee or something of that nature. There might be some better modules for this but since its suppposed to be a fairly open system by nature its hard to "lock down".

I used Books for the more formal and static "policy/procedure" type of things and then used taxonomy and taxonomy menu for classifying and navigating the non-book pages. I created a hierarchical structure for classifications and made it a required field (no free tagging). I also created another vocabulary "Other" and enabled free tagging to allow people to add new terms and tags. I disabled this vocabulary in taxonomy_menu though since there will not be much structure to it. I also included a "project name" vocabulary that is also free tagging but is still part of the navigation thru taxonomy_menu. These three classifications should provide enough flexibility for my users while still providing some structure.

As part of the glossary, I also had to create a taxonomy vocab for glossary. (Note glossary.module creates its own menu entry, so I disabled the taxonomy_menu for the glossary vocab) Interestingly enough, when i created it I was required to tie it to a content type, but I edited to remove the content type tie and it bypassed that problem. (I didn't want "glossary" to be an option in the create content page). I also found out that "administer glossary" has no functional purpose so you can enable it or disable it with no change. I however wanted users to be able to add/edit glossary terms. To do this, you have to enable "administer taxonomy" which I didn't really like. The work around that I came up with is to add a menu item as a child to the glossary menu item and use the direct link to adding terms to the glossary taxonomy. Then I disabled the "categories" menu item under administration so that users wouldn't see it. Then I created a block with a link to the taxonomy administration page "/admin/taxonomy" and I left the title blank. Then I used the "php mode" to only show that block to the admin user (UID #1) but I could've easily modified that to allow any SysAdmins to see that block too. Here is the code in the for the block. (I modified this from the handbook entries on PHP scripts)

global $user;
  if ($user->uid == 1) {
    return TRUE;  // block will be shown
  return FALSE;

Other Misc - I re-arranged the navigation menu to have all the navigation elements near the top of the list (better usuability i thought). I disabled the freelinking menu item. Used bluemarine theme because it was semi-close to company colors and didn't want to do a custom them. Used the options to include logo and favicon.ico but disabled the search bar in the theme and chose to enable the search block on the left hand side. Also, setup site so only admins could create users (no registrations) and modified the email sent out upon creation. I removed the listing of the password initially created so as to make it more likely they will change their passwords upon login. I enabled clean urls, mainly to make it easier for internal communication of links not search engines. i also setup a cron run to make the search index work. Disabled cache (not needed) and changed files to be governed by drupal (small company so little overhead). Modified the search ranking a little.

Future Work:
In the near future I might add in the notify or subscription modules to allow for email notifications. I might also look at including the tinymce module but I wanted to see how the users responded to this first before potentially complicating things. I have also read there can be a few issues with Tinymce and the different filters and I didn't want to spend time debugging it just yet. I also might have to change my php memory if my users start wanting to upload large files, but I haven't modified it for now. In the longer term, I might consider adding other functionality like liquid wiki, organic groups, calendars, CiviCRM, or other features but only as site grows or people request them. The only other consideration would be if the company wanted to allow clients to have access to any of this information like project status or allowing clients to submit issues. This would require reworking the permissions a bit - I think it would be fairly simple to define a new role a "general employee" and move all the default permissions to that role. Then disable all access to "authenticated user" and define a seperate role for "client" and provide whatever priviledges are there (mainly just view permissions) and update the node_privacy_byrole information accordingly.

General Note: This site was also a prime candidate for a private wiki. I decided to use drupal for a few reasons. 1) drupal provides the ability to add other functionality down the like, like a company calendar or integrating CiviCRM to be used internally. 2) The wiki's I looked at all seemed to have one problem or missing feature that didn't quite fit for me (as a newbie to those systems). I narrowed my choice in wiki's to TWiki (which I liked alot but seemed more than what I needed and seemed to have dificult setup), MediaWiki (lots of reports of it being difficult to secure since its primary audience is public wikis) and a few others like docuwiki, pmwiki, wikkawiki,wackowiki, and moinmoin. 3) I was more familiar with drupal


P.S. Feel free to make any comments or point out any other issues you see that I might've missed. I have also edited this thread's title to note the solution

rcross’s picture

hey, I can't seem to edit my original post. I don't know if an admin needs to do this, but i was hoping to change the topic to -> "[Solved] Access Control for Intranet/Private site" Thanks


rcross’s picture

oadaeh’s picture

I'm currently setting up a site which is very much like what you describe here. I just wanted to say THANKS! for taking the time to outline what you did here, because you answered a couple of questions I had in areas at which I had reached a stopping point.

rcross’s picture

Glad my efforts could be of use. Would you mind adding your modifications/alternatives into the mix once you're finished? I've been noticing that more people are starting to use drupal for internal type sites, and I'm sure it woudl be helpful. I created a book page here -> http://drupal.org/node/63456 so if you just wanted to add a comment to that page or a reply in this post, that would be great


incrn8’s picture

Let me add my thanks. I was just asked to take down a live site while the client checked things over, and need a way to have only a front page open to the public. Your article is going to help me a lot with that.



rcross’s picture

Sorry for a late reply, but I might add that if you're using the 4.7 version of Drupal, you could just use the "site maintenance" option in the site setting and then customize the maintenance page. other wise, you can use the frontpage.module very very easily. Good luck!


trantt’s picture

thanks for of the info

raster’s picture

Just wanted to add to the "Thanks" messages... I'm working on an intranet and this write-up served as a great starting point...

Steel Rat’s picture

Hi RCross,

you did a lot of good work here, thanks for posting all this!

I have something similar going on, nothing so important as a work intranet, but a role-playing game site instead.

I went with Organic Groups becuase it does a pretty good job of encapsulating content within the group (about the only drawback is the forums.) I needed to be able to encapsulate based on the named user and not by role, since there could be several, not to mention other privacy concerns I have yet to deal with.

At any rate, i'm about 80% there with Organic Groups, Views.module, CCK, and a few others.

Steel Rat
Drupal Site: RPGMapShare.com

hedac’s picture

If you use CCK nodes you can create as many content types as you want and assing permissions to roles for each content type

dman’s picture

I'm scoping an intrante job which wants all sorts of odd access control levels, and I'm evaluating the taxonomy versions vs the role versions vs the groups versions of implimentation.

As well as super-admin-user-anon roles, the admins and users are segregated by 'office' where they have limited write and read permissions (respectively) to their areas, as well as shared public stuff.

I'm pretty sure groups is what I want

If I was consulting, I'd tell them to shelve it - I've worked on nationwide intranets with tens of thousands of pages of department-only pages, and it simply wasn't worth preventing employees accessing most stuff from the office in the next town. If it was on the intranet, it was there to be available, and frankly not very interesting to someone outside that role. OTOH, user B not being able to see the link that was emailed them by user A is annoying.
However, I'm just asked to make it so. I think I'll get as far as a demo, and as long as I can get the client to log in as a local admin we can demonstrate how awkward and unituative the disappearing access will be :-/

How to troubleshoot Drupal | http://www.coders.co.nz/

karldied’s picture

Dan, others: any further thoughts on what you used for access control on your project, and what the different modules do, how they compare, and which ones are designed for what tasks? -Karl

dman’s picture

I didn't actually impliment any of this.
By describing the difficulties of finding a complicated, customized way to get the system to do a job whose sole purpose was to PREVENT people from getting things done, we got the client to scale down their requirements.
Which I think is the correct result.

Could you work in an office where every single drawer and shelf and piece of equipment was locked with a different key and each individual was issued a big key-ring with keys only for each item they were supposed to be able to use? No. They get a door key or passcard and then can move around the office freely, even if they do spend 95% of the time at their own desk.

Filesystem Access Controls can be made to behave like this, but in a business situation, where everyone is on the same side, locking things down like that just eats up lots of admin time with people getting permissions to do stuff. People in the web group can edit web stuff. End of story.

How to troubleshoot Drupal | http://www.coders.co.nz/

jlmeredith’s picture

It Ain't Easy Being A Geek

Jamie Meredith
Senior Director of Operations / Plan Left, LLC / Nashville, TN
LinkedIn - http://www.linkedin.com/in/jlmeredith

martinvandiest’s picture

I need to build a news site that will have both public and secure content.

It would seem that the easiest way to deal with this would be to have the capabilty through either a module, or better, core, to give each node either public or secure status/access. I experimented with the 'nodeaccess' module a little in 4.7 and it seemed to do what I needed, but, being that I have not seen any plans to port 'nodeaccess' to Drupal 5, I need to find something different.

I did play around with Organic Groups a little but it didn't seem very friendly for just simple access controls. Also, if I were to type in the url of a group post, even if I weren't in that group, I would still see the content.

Ideally I would like the workflow for the contributors/editors to be as simple as:

Login (ssl - authenticated by a central server, i.e. LDAP or ? )

Create/Review/Revise/Publish Secure Content (for eventual public viewing)

I would want to be able to set all nodes to default=secure but with check boxes at the top of the forms so after it has been revised and reviewed the editors can make it publicly viewable even if only in the taxonomy/index. It would be a big plus if the secure nodes were invisible in the taxonomy view so people won't get 'access denied' messages.

Fortunately I only have to maintain two types of access, public and secure.

Just an afterthought... it would be useful to not only mark something as secure but also set which roles could access the node in the case of using certain financially oriented modules which might require an even more restricted viewership.

I just starting poking around drupal about a month ago, and, I am not a coder so maybe this is harder than I imagine.

Drupal 5 RC1 + CiviCRM 1.5

rcross’s picture


I would suggest looking at the other node access modules and the work flow module. From my understanding, everything you are asking for is readily available you just need to read through the manual and some other forum posts. Try looking under publishing workflow or publishing node access. This thread was targeted at a specific purpose, which is fairly different to your needs. This is definitely not the only or best way to secure nodes for all purposes. Also, i would point out that there is a node access api that is being included in core 5.0 which is supposed to allow the different node access modules to work together and i think it also provides alot of default security options out of the box. You should also get familiar with the roles page, where you can define access privileges based on role.