Merge lp://staging/~xaav/wikkid/auth-provider into lp://staging/wikkid

This is sort-of done, but a bit messy.

I think the idea of an authorization provider is a good idea. But not convinced on determining authorisation based on view name. I feel that it could end up with a lot of different authorisation checks needed.

How do you feel this would be used?

What about some general roles? Like View and Edit? I was considering the possibility of having "locked" pages, using the first line of of the wiki page, a little like he way moin does it.

>
> How do you feel this would be used?

Basically wikkid would just verify whether an action was allowed or not, and
if not display an access denied page.

What about some general roles? Like View and Edit? I was considering the
> possibility of having "locked" pages, using the first line of of the wiki
> page, a little like he way moin does it.

The way it is now is that it is up to the authorization provider to manage
roles, allowing the most flexibility.

I sort of need to clean this up, the way it is now it's sort of hackish.

On Tue, Jun 14, 2011 at 5:59 PM, Tim Penhey <email address hidden>wrote:

> I think the idea of an authorization provider is a good idea. But not
> convinced on determining authorisation based on view name. I feel that it
> could end up with a lot of different authorisation checks needed.
>
> How do you feel this would be used?
>
> What about some general roles? Like View and Edit? I was considering the
> possibility of having "locked" pages, using the first line of of the wiki
> page, a little like he way moin does it.
> --
> https://code.launchpad.net/~xaav/wikkid/auth-provider/+merge/63755
> You are the owner of lp:~xaav/wikkid/auth-provider.
>

On Wed, 15 Jun 2011 13:31:04 you wrote:
> > How do you feel this would be used?
>
> Basically wikkid would just verify whether an action was allowed or not,
> and if not display an access denied page.
>
> What about some general roles? Like View and Edit? I was considering the
>
> > possibility of having "locked" pages, using the first line of of the wiki
> > page, a little like he way moin does it.
>
> The way it is now is that it is up to the authorization provider to manage
> roles, allowing the most flexibility.

Well... we probably don't want that entirely.

If you think about what we want people to do, there isn't really much.

Pretty much just View and Edit.

By passing through the View name, we are expecting all providers to handle all
views, and by adding a view this would require a change to all providers.

We don't want that.

>
> By passing through the View name, we are expecting all providers to handle
> all
> views, and by adding a view this would require a change to all providers.

That's the "hackiness" that I was referring to.

On Tue, Jun 14, 2011 at 8:55 PM, Tim Penhey <email address hidden>wrote:

> On Wed, 15 Jun 2011 13:31:04 you wrote:
> > > How do you feel this would be used?
> >
> > Basically wikkid would just verify whether an action was allowed or not,
> > and if not display an access denied page.
> >
> > What about some general roles? Like View and Edit? I was considering
> the
> >
> > > possibility of having "locked" pages, using the first line of of the
> wiki
> > > page, a little like he way moin does it.
> >
> > The way it is now is that it is up to the authorization provider to
> manage
> > roles, allowing the most flexibility.
>
> Well... we probably don't want that entirely.
>
> If you think about what we want people to do, there isn't really much.
>
> Pretty much just View and Edit.
>
> By passing through the View name, we are expecting all providers to handle
> all
> views, and by adding a view this would require a change to all providers.
>
> We don't want that.
>
> --
> https://code.launchpad.net/~xaav/wikkid/auth-provider/+merge/63755
> You are the owner of lp:~xaav/wikkid/auth-provider.
>

On Wed, 15 Jun 2011 14:13:27 you wrote:
> > By passing through the View name, we are expecting all providers to
> > handle all
> > views, and by adding a view this would require a change to all providers.
>
> That's the "hackiness" that I was referring to.

OK, how about a slight change then.

What about an expected "permission" attribute to the base view class.
Initialised to something boring like None

The view registration code then makes sure that the permission is set.

We use 'view' and 'edit' for now, and add the appropriate permission to all
the views.

I changed it so that the authorization was removed from the base view and added to each individual view.