Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
By HelpDrupalHelpMe on
Drupal access control is not as granular as I thought.
I don't understand why everyone who registers is automatically assigned an authenitcated user role and given full access to my content. Shouldn't that be left to me to decide?
It seems to be either yes or no. I am using a subscription software and I would like subscribers to only access content based on the Taxonomy they subscribed to.
Under,
Home » Administer » User management » Access Control: node module: access content
If I check mark this setting, why does it give the user full access to content? It is too broad.
I only want the user to have access to content based on the Taxonomy they subscribed to otherwise ACCESS DENIED page.
Comments
Try the Taxonomy Access Control Module
This should give you the granularity you need. It works fine for me - though I only have two levels of subscription - setup could be a bit fiddly (ticking the correct boxes) if this number is large.
Gareth
I don't understand why
I'm not trying to be funny... but that's because that's the definition of "authenticated" user (one who is authenticated).
You can control what access authenticated users have at admin/user/access just like any other role. You can create additional roles for somewhat finer grained access.
If you want to control access based on taxonomy, then gareth_w is correct, you should check out the taxonmy access control module. There's quite a few AC modules-- Content Access allows for very fine grained control.
Perhaps for your use case it is too broad. For many many users it is not. Drupal core strives to be light weight with minimal features applicable across all use cases that are easily extended by plugging in modules. Why should the many users who don't require extensive AC be burdened with having features they will never use simply because it fits your use case?
If you need additional functionality, simply plug it in. If you don't, you dont have to. It's that simple.
I am already using Taxonomy
I am already using Taxonomy Access Control, perhaps I did not configure it right as the user that should not have access to a particular taxonomy can still view the names and crumbs instead of just getting an access denied page.
Even still I have to allow users to view all content or nothing at all. It's a one size fits all approach because the "authenticated user role" is automatically thrown at all user roles I create. Which sort of defeats the purpose of creating different user roles. Does "Access Control" Supercede everything?
Also there are some Administrator items in the NAV that i do not want the subscriber to see and I can't seem to control this like I can with blocks.
How about better safe than sorry? If anything Drupal core should be heavy on security and access control as much as possible out the box. I would rather have that than the minute inconvience of a few check boxes. At least the option to create them would be great.
That's right
but with T.A.C. when you create new taxonomies/roles you can set this to that plain authenticated can't see them. So authenticated is your base level (useful for website help, FAQ, account services etc that apply to everyone) and then specific classes build on top of that.
However, your admin items should be hidden by default - maybe you need to examine closer the visibility settings of these?
Gareth
I must be doing something
I must be doing something wrong!!! This was one of the last steps for me and would be a big set back if it doesn't work.
Even though I have my setings for each role set the way I like it in the Taxonomy Access the registered user can still view EVERY bit of content no matter what the taxonomy is.
Again, Access Control seems to be the culprit, it either allows the user to view all content or nothing at all. Which is why I don't understand the point of creating different roles or the Taxonomy module. People say it works so I must be doing something wrong.
I just don't know what the right combination is. It seems to be that Access Control supercedes all no matter what I set in the Taxonomy Access Module.
There's actually a pretty
There's actually a pretty good troubleshooting section in the readme.txt file for the current recommended release-- did you go through all the steps? If so, post the results here and I'll see if I can see anything obvious.
perhaps I did not configure
I've not used that module, so I can't really help much except to say that I'm pretty sure its a popular AC module, so it sounds as if 1) its not configured right or 2) it's a bug. The issue queue for the module should be able to provide specific assistance.
You're sort of missing the point here... the authenticated user role isn't "thrown at" anything. The very definition of authenticated user is a user that has authenticated by logging into the system. period. There are a many many many cases where that is all the AC anyone wants. You can then build additional access control models based on your particular use case. But authenticated vs not (anonymous) is the most basic level, is appropriate to all, and it is available to by default.
I do this simply by turning off the provided nav menu and creating a custom nav menu (using the Taxonomy menu module), but there are probably several other ways of doing this.
Don't confuse security with access control features. Drupal is very security conscious out of the box but that has nothing to do with the level of access control features core provides. How you want to model access control for your particular use case is a feature issue, while whether or not the chosen access control features function as they are supposed to is a security issue.
There are many different ways to model access control. Yours is taxonomny based. There's also role based. Path based. Node based. Organic Group based. User based. None is more right or wrong than any other-- it all depends on the use case at hand. Including them all would needlessly bloat core as well as provide endlessly complicated security considerations.
Drupal is more of a framework than a full fledged product. It's highly modular and features are meant to be plugged in as necessary. That keeps core small, succint, and high quality. That philosophy is not likely to change any time soon so if you're looking for a full featured product that is optimally configured for a specific use case OOB, then you're probably looking in the wrong place.