Site access problem with 3.7.3

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.

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.

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

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