Site access problem with 3.7.3

Author Message

Marc Boon

Sunday 22 January 2006 9:45:31 am

After a clean install of 3.7.3 using the 'Plain' site without any extra modules, I can't add any more site accesses. Every siteaccess named differently than the two specified during the install (the admin and user site names) is denied public access.
Even when I simply rename the public site access of the standard install, I get this message. For example:

/settings/override/site.ini.append.php after install:

[SiteSettings]
DefaultAccess=test
SiteList[]
SiteList[]=test

[SiteAccessSettings]
CheckValidity=false
AvailableSiteAccessList[]
AvailableSiteAccessList[]=test
AvailableSiteAccessList[]=ezadmin

When I change this in:

[SiteSettings]
DefaultAccess=test2
SiteList[]
SiteList[]=test2

[SiteAccessSettings]
CheckValidity=false
AvailableSiteAccessList[]
AvailableSiteAccessList[]=test2
AvailableSiteAccessList[]=ezadmin

and also rename the directory /settings/siteaccess/test to /settings/siteaccess/test2, the site 'test2' is no longer accessible (you get a Access Denied message with a login screen).

You should be able to rename a siteaccess, not? And at least be able to manually add more siteaccess.

Hans Melis

Sunday 22 January 2006 10:10:31 am

Hi Marc,

This should be a simple permissions problem. eZ publish always has an active user, either someone who has logged in or the "anonymous user" in other cases (most notably a public site). If you say user, you also say role. There is an anonymous role which is by default assigned to the anonymous user group. It's modified to reflect the names you entered during setup, but any changes afterwards need to be done by you.

So if you rename a siteaccess or you add one, you need to change the anonymous role if you want the siteaccess to be public. The policy that allows access is: User | Login | SiteAccess( xx ). Edit it to reflect the changes and public access should be possible again.

Hans
http://blog.hansmelis.be

Marc Boon

Sunday 22 January 2006 11:58:22 am

Ok, this sounds reasonable, but when I look at the Anonymous User in the admin site, I see this:

Assigned Roles [1]
Name:Anonymous Limitation:No Limitation

Assigned Policies [4]
Name:Anonymous Module:content Funtion:read Limitation:Section(Standard)
Name:Anonymous Module:content Funtion:pdf Limitation:Section(Standard)
Name:Anonymous Module:rss Funtion:feed Limitation:No Limitations
Name:Anonymous Module:user Funtion:login Limitation:SiteAccess()

To me, this means that any anonymous user can view all content as long as it is in section standard, which it is (IndexPage=/content/view/full/2), no matter the name of the site access. So what do I need to change exactly?

Also, I didn't have this problem with 3.7.2, and I didn't expect a major change in a bugfix release like 3.7.3.
I really need to understand this fully!
Thanks a lot for explaining.

Marc Boon

Sunday 22 January 2006 12:13:14 pm

OK, I got it working, by changing the user/login policy for Anonymous. Still, I don't understand why this was needed, since I have the following in my siteaccess/site.ini:

[SiteAccessSettings]
RequireUserLogin=false
</code.

Hans Melis

Sunday 22 January 2006 1:09:15 pm

I'll answer this in steps to cover your subquestions.

1) The original role said Siteaccess() because you renamed the original siteaccess. The access selected in that policy no longer existed so the system didn't display it anymore. Never look at empty braces as a wildcard in the role system. Empty braces mean that the selected values for the limitation are no longer valid.

2) If you are not allowed to log in on a siteaccess, the system will bail out even before any read policies are considered. The read rights for the standard section are valid provided you can use a siteaccess.

3) This is certainly not a major change. It has always been that way.

4) RequireUserLogin is irrelevant in this case. All it does is forcing people to log in or not. It doesn't influence the role system. If login is required, an unauthenticated user will be shown a login screen. After logging in, the user can use the chosen siteaccess if his roles allow him to.

If logging in is not required, people can still log in but it's optional. If they don't log in, the system will see them as "Anonymous User" and it will use the roles associated with that account.

Hans
http://blog.hansmelis.be

Marc Boon

Sunday 22 January 2006 2:06:07 pm

This was very informative, thank you!

Now I understand why my previous 3.7.2 manual installation behaved differently. After a manual installation, the user/login policy for Anonymous is set to SiteAccess(Any). I was unaware of these policies, so I didn't bother to change them, hence I could freely add siteaccesses without seeing any login dialogs (RequireUserLogin=false). For the admin siteaccess, I had RequireUserLogin=true. I didn't realize that in this situation also the Anonymous user could login to the admin site, provided he/she entered the default password which is written to the database by the cleandata.sql script.

George Michaelides

Monday 23 January 2006 12:59:54 am

Well I was about to raise a forum message when I saw the solution here!

I upgraded from 3.6.0 to 3.7.3 and had the exact same problem - made the database changes and replaced the relevant custom files to find out that everything worked apart from the site access. So I included the correct site in the user/login policy and it worked ok.
I still don't quite understand why it was ok before; I don't remember the user/login policy setting I had to be honest.

On a further note, is there a guide as to which update scripts one must run on an upgrade? I gather that not all scripts have to be run and in this instance I didn't run any at all and it seemed ok.

George

www.jegodesigns.com
www.jegodesigns.eu

Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2014 eZ Systems AS (except where otherwise noted). All rights reserved.