Community
Participate
Working Groups
So far we can store only rules like: - '/file/A' meaning that all URIs prefixed by that rule like '/file/A/a.txt' may be accessed by the user However if we add a rule like /users/test to indicated that a user 'test' may access his own profile, he will be actually able to access profiles of all users with names started with 'test' i.e. 'test1', 'test2' etc. We need to fix that. The simplest thing we can do is to introduce wildcards. If we have that: - a rule '/file/A' would mean that the user may access just this URI - to access all files under '/file/A' we would need to add a rule '/file/A/*' What do you think? Any better ideas?
I think it's a good idea provided that 1.'/file/A/*' would match '/file/A' (as you wrote) 2. '/file/A/' would match both '/file/A' and '/file/A/' (this is not an exact wildcard match, '/' in the end should be ignored) 3. the comparison should be case insensitive (currently they are not) I have one important question: what about current rules that are already defined? would we like to migrate them? If we don't everyone would need to remove and create users again, or modify users manually. But I don't think it's a good idea releasing any code that would support backward compatibility to pre-released changes.
Created attachment 187291 [details] Solution After a short conversation we decided that it's best to use [ "/file/A", "/file/A/*"] if we want to add rights to "/file/A" and all its sub-locations. This patch adds necessary wildcard paths in every place were rights are added in the code so far. It also adds rights for the user to view/update his own personal information when new user is created.
Fixed
