[ckan-dev] Auth changes - branch 2939

Fri Oct 12 13:57:33 UTC 2012

On 12 October 2012 13:49, Sean Hammond <sean.hammond at okfn.org> wrote:

> > This means that now all authorization occurs through the logic.auth
> > functions.
>
> This sounds good to me. I'm not sure I totally understand the
> consequences of removing Authorizer, check_access_old(), publisher auth
> functions, etc. I think that's a sign that the old auth system(s) were
> too complex.
>
It is quite hard to study them and get a feeling that you
> understand them completely. Everything going through ckan/logic/auth/
> sounds like an easy to understand solution.
>
> > the permissions and current defaults are
> >     'anon_create_dataset': False,
> >     'create_dataset_if_not_in_organization': True,
> >     'user_create_groups': False,
> >     'user_create_organizations': False,
> >     'create_user_via_api': False,
>
> Also seems good to me and we can add more of these (or not) as
> required.
>

I think maybe the names can be improved prior to 2.0

>
> Clearly beyond the scope of this organization's branch, but I think we
> could go further with overhauling the authorization system and I think
> the direction you've pointed with this patch looks good.
>
> - Not everything goes through /logic/auth/, I still see places where
>   controllers are calling new_authz directly
>

This is due to needing to filter the group/org lists into the ones someone
has permissions to view - It could hopefully be improved

>
> - We still seem to be using the roles, rights and actions
>
> could you clarify?  Do you meant the ones in new_authz?

> What I'd like to see is a really simple and consistent auth system where
> every time a controller wants to do something it just calls a
> /logic/action function, and every time an action function wants to check
> if something is authorized it just calls a /logic/auth/ function.
>
> So the auth system is just a simple list of functions in /logic/auth/,
> one auth function for each action that requires auth. Very easy to
> understand and we can make CKAN's default auth behaviour as broad or as
> fine-grained as we want this way.
>

I agree with this strategy

>
> If people want to customise the auth behaviour, they just use
> IAuthFunctions to override some of the default auth functions (or add
> new ones).
>
> We'd lose the ability which the current system has, where you can
> customise the auth very powerfully using ini file settings and the paster
> rights and paster roles commands.
>
> But we could get some of this back by adding simple boolean ini file
> settings for the most commonly requested changes, like the ones you have
> anons_can_create_datasets, create_dataset_if_not_in_organization, etc.
> All these settings do is make it quick and easy to do certain auth
> customisations without having to write an IAuthFunctions plugin.
>
> yeah, although it might be nice to have them database overridable like the
admin config options - but that is for another day

> I think this would be a great system, the implementation is simple,
> you can still do some customisation in the ini file and the
> customisation is much easier to understand than roles/actions/objects,
> and if you want to go beyond the provided ini file options you have full
> power by using an extension and IAuthFunctions.
>
> Doing this would of course break loads of tests
>
> I strongly feel that we need a thorough review rewrite of many tests but
not sure how funding would work out

> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20121012/3e156304/attachment-0001.html>