http://localhost/ticket/1094 <p> Here are some proposed changes related to CKAN's authorization system - they aren't very big, but should provide for some forthcoming use cases including <a class="closed ticket" href="http://localhost/ticket/787" title="task: Auth API (closed: fixed)">#787</a>. </p> <p> Two man reasons for the changes are: </p> <ul><li>We have a completely refactored architecture now which introduces a logic layer. These Auth changes are designed to better support the way we work with that layer. </li></ul><ul><li>Different CKAN extension apps may need radically different authentication/authorisation so we need to allow whatever we have to be override-able. </li></ul><p> The first two changes revolve around the is_authorized method, which is called by the logic layer to ask whether a particular user (e.g. Bob) is allowed to do a certain action (e.g. edit) on a certain object (e.g. Package). </p> <ol><li>The first thing the is_authorized method is a hook to a plugin </li></ol><p> which *overrides* the current call with its own implementation (note: in previous discussions we have considered allowing a chain of plugins, no longer!) </p> <p> Reason: authorization can be completely delegated to another system (or partially) </p> <ol start="2"><li>is_authorized method currently takes (username, action, object) </li></ol><p> but for action=create_package, the object supplied is System, and for action=edit the object supplied is the package. Instead action should always be the string name of a function in the logic layer and object should always be the object passed to that function. This means our auth system is based around the actual actions we are performing (rather than a model them) and with the actual data that forms the action (rather than a related object). You never need a System object in this model. </p> <ol start="3"><li>Rename these two classes to better reflect what they are <ul><li><a class="missing wiki">AuthorizationGroup?</a> -&gt; <a class="missing wiki">UserGroup?</a> </li><li>Group -&gt; <a class="missing wiki">PackageGroup?</a> </li></ul></li></ol><ol start="4"><li>Rename the Editor role to <a class="missing wiki">PriveledgeUser?</a> since Editors sometimes can't edit. </li></ol><p> Although this sounds a bit radical we already have auth extensions. </p> <h2 id="Read-onlyCKANWebUI">Read-only CKAN Web UI</h2> <p> (Additional requirement from <a class="closed ticket" href="http://localhost/ticket/764" title="enhancement: Read-only CKAN Web UI (closed: duplicate)">#764</a>) </p> <p> Whilse using CKAN web interface, you are not tempted to edit stuff: </p> <ul><li>You know at all times this CKAN is read-only </li><li>All editing facilities are still seen but greyed-out with an indication why it is. </li></ul> en-us http://assets.okfn.org/p/ckan/img/ckan_logo_shortname.png http://localhost/ticket/1094 Trac 0.12.3 rgrp Mon, 18 Apr 2011 12:27:50 GMT http://localhost/ticket/1094#comment:1 http://localhost/ticket/1094#comment:1 <p> See also comments on the mailing list. </p> <p> Item 1 seems fine (what is difference from current extension mechanism?) </p> <p> Item 2: concerns here. What about list views? What about editing 'permissions'? I also think getting rid of System object isn't really a benefit (if anything may be a cost). </p> <p> Item 3: feel this may be better as part of big domain model change (also gives us time to really dig into this -- this is an important requirement/conceptual issue). </p> <p> Item 4: No objections but seems very minor gain for fairly significant migration work. </p> Ticket johnlawrenceaspden Mon, 02 May 2011 16:33:56 GMT http://localhost/ticket/1094#comment:2 http://localhost/ticket/1094#comment:2 <p> <a class="missing wiki">UserGroup/PackageGroup?</a> might also be confusing. </p> <p> A <a class="missing wiki">PackageGroup?</a> is *just* a group of packages. </p> <p> A <a class="missing wiki">UserGroup?</a> is both a group of users, and a thing affecting authorizations. </p> <p> Perhaps <a class="missing wiki">PackageGroup?</a> and <a class="missing wiki">UserAuthorizationGroup?</a>? Or <a class="missing wiki">PackageGroup?</a> and <a class="missing wiki">AuthorizedUserGroup?</a>? </p> <p> I was quite confused by all this at first. </p> <p> I think I understand how the whole thing works pretty well now, and I still can't think of good names for the two concepts, although I can already feel the normal English meanings of the words changing to what I now know they are for. </p> <p> We should be a little wary of this. Things that are even slightly difficult to understand end up being understood by very few people. Would any of us be prepared to sit an exam on exactly how UNIX file permissions work, even though we all use them? </p> Ticket thejimmyg Fri, 08 Jul 2011 13:46:39 GMT http://localhost/ticket/1094#comment:3 http://localhost/ticket/1094#comment:3 <ul> <li><strong>summary</strong> changed from <em>Refactor the Auth System</em> to <em>[super] Refactor the Auth System</em> </li> </ul> Ticket dread Fri, 08 Jul 2011 14:08:34 GMT http://localhost/ticket/1094#comment:4 http://localhost/ticket/1094#comment:4 <ul> <li><strong>description</strong> modified (<a href="/ticket/1094?action=diff&amp;version=4">diff</a>) </li> </ul> Ticket thejimmyg Wed, 20 Jul 2011 14:54:09 GMT http://localhost/ticket/1094#comment:5 http://localhost/ticket/1094#comment:5 <ul> <li><strong>status</strong> changed from <em>new</em> to <em>closed</em> </li> <li><strong>resolution</strong> set to <em>duplicate</em> </li> </ul> <p> Merging with <a class="closed ticket" href="http://localhost/ticket/1065" title="enhancement: [super] Change Authorization System (closed: fixed)">#1065</a> and closing. </p> Ticket