Page permissions

[rantaaho]

Are there any plans for implementing page permissions, i.e. restrict access to page for some users or user groups?

Since Django doesn't support row level permissions, this has to be done in PyLucid. I think that it is not possible to implement permissions without changing Page-model.

I need permissions, and I can do some coding for it. But since it includes more than just writing a plugin, I would like to do it so, that it could be accepted to PyLucid codebase. Thus all suggestions and guidance are very wellcome.

My target is to restrict some of the pages to some user groups. Thus, I was planning to add to the Page-model a ManytoMany-relationship with Django groups. So that if a Page has some related groups, user has to belong at least one of them to see the page. Adding that check to page rendering and main_menu shouldn't be that hard, or?

[jens]

Yes, there exist no real page permissions.

You can edit the bool "PermitViewPublic" in the django panle under the TAB "Advanced options"... So you can limit the access to users how are logged-in.

There exist the Point "PermitViewGroup" and "PermitEditGroup"... But these Values aren't working. Its not complete implemented...

The Problem is: I don't need this features really. So i not work active on this stuff...

If you will implement a page permission systems, it's very welcome But i think this is a Feature for v0.8.1 and not for v0.8, that i will release soon...
_________________

http://www.jensdiemer.de | http://www.htfx.de | http://www.python-forum.de

[rantaaho]

Ok, I hadn't found PermitViewGroup et al.

I will check what I can do for permissions.

[jens]

The first Problem is, the view method must check the PermitViewGroup. But this is not implemented.

The "PermitViewGroup check" can be places in here:
http://trac.pylucid.net/browser/trunk/pylucid/PyLucid/system/detect_page.py#L66

I think this can be done in a few lines...
_________________

http://www.jensdiemer.de | http://www.htfx.de | http://www.python-forum.de

[rantaaho]

Thanks for the pointer.

The obvious next questions are: which exception should it raise: AccessDeny, Http404, or should we have a separate Http401?
Where these exceptions are supposed to be handled? There doesn't seem to be code for that in index.py. For 404 and 500 the default seems to be Django.

[jens]

Very good question

I don't known whitch the best choice... From http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html :

401 Unauthorized
403 Forbidden

btw. we have a own 404 and 500: http://trac.pylucid.net/browser/trunk/pylucid/PyLucid/templates_PyLucid

The other way: A redirect to the login page... But it's not implemented a way back to the page, after the login was successful...
_________________

http://www.jensdiemer.de | http://www.htfx.de | http://www.python-forum.de

[rantaaho]

From RFC 2616:

[jens]

[jens]

I have applied your Patch from ticket http://trac.pylucid.net/ticket/148 - Thanks!

But there is still something to do. Please look search for "FIXME" here: http://trac.pylucid.net/changeset/1416

And we need a unittest for this, see: http://trac.pylucid.net/ticket/149

btw. i like DocStrings
_________________

http://www.jensdiemer.de | http://www.htfx.de | http://www.python-forum.de

[rantaaho]

Thanks,

You were faster in fixing one of the FIXMEs.

I will write an unittest for permitViewPublic. But could you describe the unittest system of PyLucid little bit. It doesn't follow the standard Django system. The unittest's are under dev_scripts/unittests, right? Some other test scripts under dev_scripts/local_tests and something under pylucid/tests, what are these?

Is there somewhere a script to run all unittests? Shouldn't it be called pylucid/PyLucid/tests.py so that "django-admin.sh test" would work?

[jens]

[rantaaho]

Ok, thanks.

Now it makes more sense.

[jens]

I have a new problem detected. I think its related to the changes here.

http://trac.pylucid.net/ticket/156
_________________

http://www.jensdiemer.de | http://www.htfx.de | http://www.python-forum.de

[jens]

I changed the "next_url" behavior: