Question

Non readable attributes in an XPath constraint of an access rule.

2

Should it be possible to use unreadable attributes in an XPath constraint of an access rule? For example: A user can read tasks with [State='published'] but can not read the state itself?

asked 2012-02-29

Chris de Gelder

3 answers

Michel Weststrate · Answer 1 · 2012-03-20

(Finally understand the question, first thought the constraint was on the security)

This is working as intended; if you are not allowed read the costs of a project, you should not be able to query things like project[costs > 50000] because then you would still be able to determine the project costs....

Same holds for your states, if a user is not allowed to read the state, but is able to query on it, he could easily query Task[State = 'published'] and would still know the state...

Sebastiaan van den Broek · Answer 2 · 2012-02-29

Edit: Misread your question. Yes you can define a security constraint on an attribute that the user cannot read, the user himself won't be able to query on that attribute though.

Everything that he queries on will be limited by that constraint even though he can't read that attribute.

Jelle Blaauw · Answer 3 · 2012-03-20

I tried to simulate the issue that you have and I had the following results:

When attribute1 in entity security was set to nothing (neither read nor read & write) the form gave an error and did not open (even though attribute1 was not in the form itself, but was, however, in the form's xpath-constraint).

When I set attribute1 to 'read' in entity security, the form did not crash and the data was shown as usual.

So the fact that you need read access on the xpath constraint is definitely true. I do not know whether this is done intentionally, but I honestly think it's a bug.