In fact, it doesn't control access?

I tried what you described in your bug - the ?q=node/# and it does not allow me to access protected nodes.

If you created nodes before you installed TACLITE then you need to re-submit your nodes for TACLITE to work. Here is what I do and it works:

1. Created nodes.
2. Installed TAC_LITE.
3. Edited created nodes and clicked 'SUBMIT' on each one of them.
4. Voila the node is not accessible.

Check your access control settings - click on the TAC_LITE access by role tab and ensure that only the required roles have the access to the right tags. In my case I did not give any access to "Authenticated Users" instead gave rights to the new "Customer" role I created.

If you have tried everything I described above and yet managed to get access, then please let me know about your settings - this module is very important to me and hence I would like to know if there is something else that lets unauthorized users access the node.

I have set tac_lite to control access to my forums, so that an anonymous user cannot see several of my forums eg I have restricted forum/5.

It works at /forum ie the restricted forums are not shown to anon users, but if an anon user manually enters /forum/5 they are shown the forum post listing page for forum 5, although none of the posts show. Surely this is incorrect behaviour? An anon user shouldn't even know my forum 5 exists.

I think that you misundertand the purpose and the extent of tac_lite usage. It does what it says it does, and it does it quite well. It does as much as it can given the state of the Drupal core and it's quirks (such as the separation and overlap between the menu and the node systems, where the menu also controls access rights). Actually, tac_lite gives Drupal something no other CMS that I know has: an easy individual access control.

The reason people are experiencing this *limited access control* as a *bug* is probably because they did not organize their website correctly in the first place. tac_lite should be used as a fine-grain access management control module, not as a general control service. I doubt very much that this was ever the intention of its author.

The truth is there will never be a service that controls access in an absolute secure way based on the individual properties of a document (which is what taxonomy does: it ads a property to a document). With Drupal, you have to model your website so that it uses roles to control access to its different sections, be it forums or blogs, articles, or any other document structures that you put up for view. Use taxonomy-based access control to refine access within those sections only where roles become irrelevant or unmanageable (which should be the same anyways).

If role-based access could be bypassed by handling some URL parameter, this would be a very serious flaw. Even if it was possible to bypass taxonomy-based acces with such a hack, it should only have minor implications. Much like if Joe Bloe walking down the sidewalk has access to your room and personal belongings, then your home security system has serious flaws. But if your wife and kids can open the door to your room and browse through your underwear, it shouldnt be that big of a deal.

Ok, I'm kidding, but you get the idea... ;-)

efolia

This is a significant problem.

I don't see how you can say that it's an implementation problem - how we design the system.

I want to simply hide forums from unauthenticated users. Nothing fancy and certainly a very common requirement. Yet if a person gets an URL to a forum or a forum post - per this thread, they're going to be able to see it whether they should or not. I'm failry certain this will not be acceptable for my client and we will not deploye forums - a shame.

The issue though as you say may go to a deeper Drupal level. I have a few posts on the subject:

http://drupal.org/node/89826
http://drupal.org/node/88420

If necessary, I think this should be addressed at a core drupal level issue in the next significant release. At least that's my opinion...

I agree with the last poster. This is a critical issue. I, and I'm sure many other people, would like to be able to restrict access to certain nodes.

This issue has caught my eye and I am interested to get some clarification. I just recently installed TAC_lite and I thought I was successful in implementing proper access rights based on terms and user rights. I've tried the above steps to duplicate the problem but was not able to raise the same result.

Am I missing something here?

Can you really access a tac_lite protected content just by simply typing it's URL? Can someone please clarify if this is correct?

I'm seeing similar behavior but with an additional corollary.

Let's say we have 3 roles, A, B, C.

I create a taclite rule that says all users can see all terms in a given category, *except* term 'foo', which is only viewable by role A.

It works fine if every user has only one role. But users with both roles B and C can now directly access the supposedly protected content by going to the URL directly, though they still will not see the node in listings.

Not sure if this is reproducible for others, would be nice if folks could try this scenario and verify.

I apologize for being silent on this issue for so long. I only now learned of it's existence.

I suspect the problem is not caused by tac_lite, but by some other permissions causing a hook_access to grant access to the node. You see, modules like tac_lite cannot DENY access to nodes, they can only GRANT it. I suspect tac_lite is not granting the user rights to view the node, but something else is.

I would appreciate it if someone reproducing this problem could install devel_node_access (comes with devel module), enable the devel_node_access block and tell me what it says when viewing the node in question. For more info see this video: http://www.dave-cohen.com/node/1170

I am using tac_lite with 4.7.4.
It is working as expected with no security isssues (kudos).

An observation here.
With the exception of the reference to forums, I don't see what modules people are testing this on or what version of drupal is being used.

I wrote my own my module and at first was exhibiting the same issue. I made one change to the hook_menu in my module. See below.

New line:
'access' => node_access('view', $node),
Old line:
'access' => user_access('dump spreadsheet'),

Full snippet for clarity.
$items[] = array('path' => 'my/dump/' . $node->nid,
'title' => t('my dump'),
'callback' => 'my_dump',
'callback arguments' => array('node' => $node),
// 'access' => user_access('dump spreadsheet'),
'access' => node_access('view', $node),
'type' => MENU_CALLBACK);

I don't if this could factor into it or not. But it might be helpful to know this.

I just enabled devel node access and went to a BOOK page that is supposed to be limited to one specific role.
The access showed "node realm gid view update delete | Board of Directors Only | all 0 1 0 0"
I then updated and save the page.
The access showed exactly the same - UNPROTECTED.

My site is now on hold again!

And, as far as having to go and update every single node in my site, this is not acceptable - I have over 1,000 images alone. And TAC_lite was installed BEFORE they were loaded.

I assure many of my pages were created AFTER installing TAC_Lite, but this is what Devel says:

node_access summary
All Nodes Represented

All nodes are represented in the node_access table.
Access Granted to Some Nodes

The following realms appear to grant all users access to some specific nodes. This may be perfectly normal, if some of your content is available to the public.
Public Nodes realm public nodes
all 898

To nancyw, which version of drupal are you using? Have you configured tac_lite to let it know which vocabularies affect privacy? Have you assigned one of those terms to your node?

When configured properly, you should see a row with realm value 'tac_lite' in the devel_node_access block.

I am using 5.1. I did find that somehow the taxonomy associations got broken. After I fixed that everything is working correctly. Whew!!!

If this is really an issue, someone change it's status back to active. And please tell me how to reproduce, because I've never seen it.

jeeze, this gave me a bit of a fright when i saw the thread :) testing it shows no such issues however!

Access denied
You are not authorized to access this page.

Perhaps we can change the title to "(SOLVED) In fact, it doesn't control access?" in order to avoid having people read all the threads which is a bit of a waste of time :)

PS: LOVE the TAC_LITE!!! works GREAT :) please please please keep up the good work!

Or, we just close it. Bye-bye issue.