|
|
Rank: Newbie
Joined: 11/8/2006
Posts: 5
|
I just wondered if this is by design, a bug or maybe i missed something... Just tried to protect a page with access to member groups "a" and "b". Later down the tree i tried to remove "b" so anyone in group "a" and "b" can access the top pages but some documents down the tree are only accessible for "a".
Removing group "b" first seemed to work but "a" and "b" still have access. The topmost access restriction seems to be valid for all lower level trees without a chance to do a break in there.
Anyone with an idea?
Many thanks,
Marcus
|
|
Rank: Newbie
Joined: 11/8/2006
Posts: 5
|
Just for a better understanding, what I tried to accomblish is: User A = Member of Group a+b, User B = Member of Group a. User A should get access to /protected-pages/secret but User B is only allowed to access /protected-pages. My problem is that protecting /proteced-pages for Group A+B also protects /protected-pages/secret with these groups and I found no way to remove Group B from /protected-pages/secret.
Thanks for your ideas,
Marcus
|
|
Rank: Umbracoholic
Joined: 9/8/2006
Posts: 1,831
Location: MA, USA
|
Marcus, thanks for asking this question. I have seen the same thing (version 2.1.4). Curiously, if you remove protection from the topmost level you will get the protection you wanted at the next-lower level. So Umbraco *is* maintaining the protection information properly for each node but there must be a bug that it doesn't check for it properly, simply using the protections of the top-most node with protection. Like you, I want a commonly protected area (client login, in my case) that has information appropriate to all clients (but not to general visitors). Within the client area I also want a page (or pages) for individual clients that have information unique to that client. I got this far in the "debugging" process and got sidetracked with other issues and haven't gotten back to this, but I need it to work. Please keep us posted with what you find out! cheers, doug.
MVP 2007-2009 - Percipient Studios
|
|
Rank: Newbie
Joined: 11/8/2006
Posts: 5
|
Douglas Robar wrote:
Curiously, if you remove protection from the topmost level you will get the protection you wanted at the next-lower level. So Umbraco *is* maintaining the protection information properly for each node
Yes, looks like some query got messes up at this point. So far I had no time to take a deeper look at the umbraco source and my VS2003 web dev environment is totaly messed up anyway (I always hoped i can wait until v3 for VS2005 is ready) but as I need this feature working I will take a look at the code. I'll come back with my findings as soon as i got time looking at the code. I would be glad if someone has an idea on where to start searching within the code tree (2.1.4) so I can start without the VS2003 working for debuging... Thanks, Marcus.
|
|
Rank: Newbie
Joined: 11/8/2006
Posts: 5
|
doug, I guess the problem is in cms\businesslogic\web\Access.cs, method getProtectedPage(). I can't verify this as I am absolutly new to the umbraco source and my VS2003 is messed up so maybe someone that is more in the code can verify this: All access configuration is stored in access.xml. The code below walk trough a list of page id's and I assume these are the id's for the requested path in path order. In case this is true, the code would return the first match and not the "best match" as it shoudl be (see the break in the foreach loop). Am I right with this? Code:
private static int getProtectedPage(string Path)
{
int protectedPage = 0;
foreach(string id in Path.Split(",".ToCharArray()))
{
if (getPage(int.Parse(id)) != null)
{
protectedPage = int.Parse(id);
break;
}
}
return protectedPage;
}
private static XmlNode getPage(int documentId)
{
XmlNode x = AccessXml.SelectSingleNode("/access/page [@id=" + documentId.ToString() + "]");
return x;
}
An access.xml looks like: Code:<access> <page id="1113" loginPage="1053" noRightsPage="1054" simple="False"> <group id="1081" /> </page> <page id="1244" loginPage="1243" noRightsPage="1243" simple="False"> <group id="1250" /> <group id="1251" /> </page> <page id="1247" loginPage="1243" noRightsPage="1243" simple="False"> <group id="1081" /> </page> </access> Cheers, Marcus
|
|
Rank: Newbie
Joined: 11/8/2006
Posts: 5
|
YEEES, that's it! Just remove the break; in the foreach and anything works as intended!
Where do patches go to, the SVN is ro so where to send this?
Marcus
|
|
Rank: Devotee
Joined: 7/20/2006
Posts: 89
|
Hi Marcus,
I am having the same problem, using 2.1.6, did you get this in the soruce code?
If not could you help me out?
Thx, Len.
|
|
Rank: Devotee
Joined: 7/20/2006
Posts: 89
|
I applied the fixed mentioned above, it really works, should put it on the svn code.
|
|
|
Guest |