[ckan-dev] Auth changes - branch 2939

[Sean Hammond]

> 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.

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

- We still seem to be using the roles, rights and actions

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.

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.

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