Hi Alex,
Our current proposal allows authorisation on person objects for those who want it, through maintainer objects
Does this mean that calling a maintained object will spit out a reference to a mntner: object which will spit out a ton of references to person: objects which are authorised to make changes on the original object? rgds, Sascha Luck
Hi Sacha,
On 17 Jun 2015, at 18:06, Sascha Luck [ml] <dbwg@c4inet.net> wrote:
Hi Alex,
Our current proposal allows authorisation on person objects for those who want it, through maintainer objects
Does this mean that calling a maintained object will spit out a reference to a mntner: object
Yes, that's unchanged. The mnt-* attributes are in the object output.
which will spit out a ton of references to person: objects which are authorised to make changes on the original object?
No, our idea was that the "auth:" attributes referencing persons would be filtered for unauthorised users. Just like we filter SSO emails and MD5 hashes today. Only *authorised* users would be able to see this, i.e. a user who is logged into web updates and who is authorised for this maintainer (i.e. has their SSO on this maintainer, or on a person object authorised for this maintainer). Similarly we would filter "auth:" attributes for person objects, unless the user looking at this is authorised. Typically that would be a user looking at their own credentials. Cheers Tim
On Thu, Jun 18, 2015 at 03:38:17PM +0200, Tim Bruijnzeels wrote:
No, our idea was that the "auth:" attributes referencing persons would be filtered for unauthorised users. Just like we filter SSO emails and MD5 hashes today.
Only *authorised* users would be able to see this, i.e. a user who is logged into web updates and who is authorised for this maintainer (i.e. has their SSO on this maintainer, or on a person object authorised for this maintainer).
Similarly we would filter "auth:" attributes for person objects, unless the user looking at this is authorised. Typically that would be a user looking at their own credentials.
Thanks, Tim, for this clarification. Certainly something I can live with. rgds, Sascha Luck
participants (2)
-
Sascha Luck [ml] -
Tim Bruijnzeels