This site has been archived and you can no longer log in or post new messages. For up-to-date community resources please visit

eZ Community » Forums » General » anonymous user id to restrict site...

anonymous user id to restrict site access

anonymous user id to restrict site access

Thursday 02 April 2015 5:56:33 am - 7 replies

hi there,

Google is always dredging up inappropriate "look and feel" combinations for the 4 sites which are all on my Ezpublish 4.1.3 single DB installation.

 It has been suggested that I make 4 new anonymous ids for my 4 sites, and edit the site.ini.append.php in each site-access and tell them which id to use.

I thought I would just copy the current anonymous id to another, and delete the appropriate permissions for the sites I wanted to hide.

When I did this, it deleted the "limitations" from all of my anonymous ids !

I have rechecked this. If I delete "limitations" from the new anonymous id, it deletes it from the original anonymous id. 

If I create a new anonymous user, it comes with all of the permissions, without me doing a thing which makes me think they are being applied elsewhere.

So if I look I see that anonymous users lives in an anonymous users "user group"

Users/Anonymous Users/Anonymous User

The original role seems to be applied to everything in the  Anonymous Users group .

Do I need to create a new Anonymous user "Role" for each site access? 
Currently, editing one role effects the whole site.  


Thursday 02 April 2015 11:02:37 am

Hello Cousin,

Normally this issue is solved by using the root node settings to isolate the siteaccess content tree usage which is a better solution for new users who do not need to share content tree content between siteaccesses.

But with an existing site or sites I can see why you would not want to spend more time rebuilding the site and potentially related templates.

I have a couple of specific suggestions which I think will help you quickly implement the solution you have in mind.

Remember that the changes you wish to make will take time to complete and test and will likely prevent normal use of the user siteaccesses while you make these changes. You must backup your database first! You should also consider performing these steps during a non-peak maintenance window.

The following solution uses best practices and should solve the problem you describe. Though you may need to undo / revert your previous attempt at making these changes (which did not work and caused problems; specifically default 'Anonymous' role / policy changes) before attempting the following.

The setup

First, Create 4 copies of the default anonymous user in the anonymous user group, admin/Users/Anonymous-Users/Anonymous-User

These should be named uniquely so you can at a glance know which siteaccess specific anonymous user is which. Here is an example: Anonymous-User-GNS, Anonymous-User-NH, Anonymous-User-XYZ, Anonymous-User-ABC.

Then document the User account User IDs (Remember UserID is always equal to ObjectID) for each new anonymous user. Do not modify or remove the existing default Anonymous-User object (as this is not needed or a good idea in general).

Remember that the 'Anonymous' role (and it's policy permissions) are by default only assigned to the admin/Users/Anonymous-Users user group by default, I will return to what this means in greater detail in a moment.

Second, on admin/role/list page, You need to create 4 copies of the default 'Anonymous' role named, 'Anonymous-GNS', 'Anonymous-NH', 'Anonymous-XYZ', 'Anonymous-ABC'. Do not remove or make any change to the default 'Anonymous' role or it's policy permissions.

Third, You will need to navigate to the role 'view' page of each of these new roles, 'Anonymous-GNS', 'Anonymous-NH', 'Anonymous-XYZ', 'Anonymous-ABC' and assign each one of the individually to the "Anonymous-User" content object they relate to NOT the Anonymous-User Group.

Fourth, Navigate to admin/role/view/1 and use the 'Users and groups using the <Anonymous> role (3)' section in the middle of the page to remove the assignment of this role to the 'Anonymous-Users' user group by checking the checkbox and clicking the 'Remove selected' form button. 

Now at this point (I think) your user siteaccesses will error when trying to view any content.

Fifth, You will need to edit each of your siteaccess site.ini.append.php settings files and add the following settings block (please remember to use the right new userID number in the settings instead of our placebo text:

# The ID of the anonymous user, this user will
# be used for everyone who is not logged in.
# Default now disabled: AnonymousUserID=10

Sixth, Clear all caches to restore regular website content access to all siteaccesses!

Seventh, Edit each of your new siteaccess specific 'Anonymous' roles policy permissions and alter each of them uniquely to restrict content read policy permissions as needed to prevent each siteaccess from accessing another siteaccesses content tree content.

I would suggest using section based restrictions but these may not be a practical option based on your unknown content tree configuration and existing section usage. Alternately subtree based content, read control policy may be more flexible and simpler to implement.

Eighth, Logout of all user siteaccesses and reload each siteaccesses testing normal site provided content access and then try to test the undesired content access test cases you describe in your previous posts. With any luck you should have solved the problem(s)!

Ninth, While the above addresses the anonymous user access of content tree content through role policy permissions successfully it may not address the (Google) search engine results problem. To solve that problem you may additionally need to use custom mod_rewrite rules and custom search engine path indexing exclusions rules configuration robots.txt files (per siteaccess/site) to ensure that the search engines to not index and present the users searching to receive these search result entries. Basically in each siteaccess specific robots.txt you want to add rules to exclude each of the other the content tree subtree base uri(s). This would probably be at least 3 specific robot.txt entries per siteaccess to exclude the content tree subtrees used by the other siteaccesses. So 4 robot.txt files in total with only one being available by default per siteaccess which would need to be controlled again via custom mod_rewrite rules.

Please note the above is all recommendations on the best way to do what was previously suggested so generally. None of these instructions have actually been tested or proven. That said, in theory this should work as desired.

I hope this helps!


Modified on Thursday 02 April 2015 11:26:08 am by // Heath

Thursday 02 April 2015 12:05:13 pm

Thanks Heath.
That is a very thorough reply. I think I was on the right track, but as you say, there appears to be no gaurentee that google wont find this stuff without extensive work on robots.txt . Its very difficult when only using the one robots.txt file as I am currently!
I need to sit down with that beer and let this sink in. I appreciate the time you  have put into this response. 
Thanks again


Thursday 02 April 2015 12:50:09 pm

Hello Cousin,

Your welcome, I'm happy to help!

You can not solve this problem with just one robot.txt file at all as they are too basic by design.

Using multiple robots.txt is dead simple in mod_rewrite and even more simple if your using different hostnames for each siteaccess .. so simple I'll show you how!

In the end to solve the search problem you will have to use the multi-robot.txt file solution described above. I would suggest starting there first, as that, by default is the most serious problem your facing (per-say; i think).

If you still want / need to address the actual the anon user *could* do but without google exposing the content probably will never do ... you can do the work described above. That said it could be a problem that does not technically have to be solved .. depending on your own priorities and just how sensitive the content is.

Here is an tested and working mod_rewrite example which does the job:

RewriteEngine On

# The following was tested and works perfectly! Your results may very ;)
RewriteCond %{HTTP_HOST} ^(www\.)?example1\.com$ [NC]
RewriteRule ^/robots\.txt /robots-example1-com\.txt [NC,L]
RewriteCond %{HTTP_HOST} ^(www\.)?example2\.com$ [NC]
RewriteRule ^/robots\.txt /robots-example2-com\.txt [NC,L]
RewriteCond %{HTTP_HOST} ^(www\.)?example3\.com$ [NC]
RewriteRule ^/robots\.txt /robots-example3-com\.txt [NC,L]
RewriteCond %{HTTP_HOST} ^(www\.)?example4\.com$ [NC]
RewriteRule ^/robots\.txt /robots-example5-com\.txt [NC,L]

Enjoy your beer and I hope things calm down. I did not mean to overwhelm you.

I hope this helps!


Modified on Thursday 02 April 2015 1:14:43 pm by // Heath

Thursday 02 April 2015 1:00:29 pm

Hello Cousin,

I took a minute to show an example siteaccess specific robot.txt file configuration for user siteaccess. Save this in a file named to match your above mod_rewrite rules usage, robots-naturalhazards-org-nz.txt

User-agent: *
Disallow: /Home*
Disallow: /ContentTreeRootURIForSiteaccess2*
Disallow: /ContentTreeRootURIForSiteaccess3*

Naturally you will need to customize the disallow uri wildcard rules but this is just a simple example based on the limited information you have shared previously

I hope this helps!


Monday 20 April 2015 4:27:33 am

Hi Heath,thanks for your sound examples with respect to the robots.txt
I had tried another technique a few months earlier and had no luck so had given up. 

I had to add the "new" robot file's name further down in the hosts file too, or it wouldn't be recognised. I should have remembered that.
RewriteRule ^/robotsgns\.txt - [L]

That omission got me started on a very bad footing and had me needlessly tweaking stuff looking for other solutions that weren't there, or needed. It's certainly an easier path than the multiple roles one.If we eventually move to ezpub 5 or 6 I will be sure to start with all of our sites at the same level next time. When we started we were not planning on have 4 sites in total.

Thanks again.

Tuesday 21 April 2015 8:46:21 am

The separation with 4 different anonymous user ids works perfectly if your 4 sites has different content trees

ezroot (2)

  • siteA_contenttree (59)
  • siteB_contenttree (60)
  • siteC_contenttree (70)
  • siteD_contenttree (80)

If your anonymous users are

  • anonymous user siteA (10) (default)
  • anonymous user siteB (1000)
  • anonymous user siteC (1001)
  • anonymous user siteD (1002)

And you have an anonymous user role

Role 'Anonymoud' witt policy

'content read  folder/article'


Than you can assig these Anonymous role with subtree limitation for example

For SiteA you will assign Role Anoynmous with subtreelimitation 59 to User anonymous user siteA

For SiteB you will assign Role Anoynmous with subtreelimitation 60 to User anonymous user siteB


Make sure that you insert the correct anoymous user id in the siteaccesskonfiguration.

If all is working

you can not access content from SiteA over the url of SiteAccessB. To test this  call  content/view/full/ nodeId for a specific node.


Cheers Felix




Modified on Tuesday 21 April 2015 8:47:13 am by Felix Woldt

Wednesday 22 April 2015 11:02:29 am

Hello Cousin,

I'm happy you were able to solve the problem, if only the part of the problem which needed to be solved (re: search engine indexing control).

I am sorry you had so much trouble (at first) with the existing mod_rewrite rules getting in the way of adding new rules, I forgot to warn you about that, sorry.

I hope this thread helps others in the future solve this same type of problem! happy.gif Emoticon

Take it eZ!



You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from