permission check for login_required now checks all ancestors for that attribute too #1112

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
5 participants
Contributor

evildmp commented Dec 9, 2011

No description provided.

@ojii ojii commented on the diff Dec 9, 2011

cms/views.py
@@ -92,13 +92,16 @@ def details(request, slug):
return HttpResponseRedirect(redirect_url)
# permission checks
- if page.login_required and not request.user.is_authenticated():
- if settings.i18n_installed:
- path = urlquote("/%s%s" % (request.LANGUAGE_CODE, request.get_full_path()))
- else:
- path = urlquote(request.get_full_path())
- tup = settings.LOGIN_URL , "next", path
- return HttpResponseRedirect('%s?%s=%s' % tup)
+ # check whether authenticated first; that we don't waste time doing anything else
+ if not request.user.is_authenticated():
+ # check this page and all its ancestors for login_required
+ if page.login_required or [ancestor for ancestor in page.get_ancestors() if ancestor.login_required]:
@ojii

ojii Dec 9, 2011

Collaborator

does "page.get_ancestors().filter(login_required=True).exists()" not work?

Collaborator

ojii commented Dec 21, 2011

this would really benefit from some sort of test case

@yakky yakky added a commit to yakky/django-cms that referenced this pull request Jun 9, 2012

@yakky yakky Test PagesTestCase.test_login_restriction to check for #1112 bug. b5d5ad6
Contributor

yakky commented Jun 9, 2012

Commit above is the test for this issue.
Confirms @evildmp report and proposed fix
page.get_ancestors().filter(login_required=True).exists()-variant of the patch works as well

Contributor

evildmp commented Jun 9, 2012

On Sat, Jun 9, 2012, Iacopo Spalletti reply+i-2501717-b194a3715bf84fc8fd66cc3e4f02b16b1f4ae3dc-86222@reply.github.co wrote:

Has the test already been written for this?

I started working on it in Züruch before I left, so it will be good to see your approach.

Daniele

Contributor

yakky commented Jun 9, 2012

I wrote the test before any answer was posted :)
Test is in commit yakky@b5d5ad6

Contributor

evildmp commented Jun 15, 2012

This appears to have been left out of the release candidate - was that deliberate, or an oversight?

Contributor

yakky commented Jun 16, 2012

I guess @ojii would like me to rework the test without Client object before merging :)

Collaborator

ojii commented Jun 20, 2012

Yes, this is targeted for a 2.3.1 release.

Contributor

beniwohli commented Jul 25, 2012

If I read the code correctly, this check adds one query per page view for unauthenticated users. We already are quite heavy on the database, I'm not sure if the trade of is worth it in this case.

How about propagating the login_required down the descendants chain on save? e.g.:

if self.login_required:
    self.get_descendants().update(login_required=True)
Collaborator

ojii commented Jul 25, 2012

while not 100% happy with the solution, I'm +1 on what @piquadrat suggested.

Contributor

yakky commented Jul 25, 2012

Looks like a really simple solution: any idea on how this could interact with moderation? I know it's in deprecated, but in 2.3 branch it's still supposed to work.

Collaborator

ojii commented Jul 25, 2012

@yakky was viewperms/login-required ever covered by moderation?

Contributor

beniwohli commented Jul 25, 2012

hrm, another problem with my update approach: it breaks the audit trail for the descendants. It's not possible anymore to figure out from the version history when a page was made login_required.

Contributor

yakky commented Jul 25, 2012

@ojii Not on the view side, but on the save side.
Just wondering if login_attribute is involved in moderation: I haven't really digged the moderator side of the code.
Test I wrote for this does not cover moderator ATM

Collaborator

ojii commented Jul 25, 2012

@piquadrat solution: create history objects? Or for-loop-save?

@yakky my concern is, if we want to make this moderator enabled, this ticket is dead.

Contributor

yakky commented Jul 25, 2012

@ojii Just thinking out loud.
I'm all for killing moderation and having something better: it's a mess to implement on a site and explain to the users, I can barely understand how messy is to maintain this.
Just updating moderation docs to explain this behavior should be fine: something like:

Please note that login restriction is immediately applied to the page and all its descendants

Contributor

beniwohli commented Jul 25, 2012

OK, how about this: if we get rid of another query in this execution path, we'll let this one in :)

I already turned this:

SELECT "cms_page"."id", "cms_page"."created_by", "cms_page"."changed_by", "cms_page"."parent_id", "cms_page"."creation_date", "cms_page"."changed_date", "cms_page"."publication_date", "cms_page"."publication_end_date", "cms_page"."in_navigation", "cms_page"."soft_root", "cms_page"."reverse_id", "cms_page"."navigation_extenders", "cms_page"."published", "cms_page"."template", "cms_page"."site_id", "cms_page"."moderator_state", "cms_page"."level", "cms_page"."lft", "cms_page"."rght", "cms_page"."tree_id", "cms_page"."login_required", "cms_page"."limit_visibility_in_menu", "cms_page"."publisher_is_draft", "cms_page"."publisher_public_id", "cms_page"."publisher_state" FROM "cms_page" LEFT OUTER JOIN "cms_page" T2 ON ("cms_page"."parent_id" = T2."id") INNER JOIN "django_site" ON ("cms_page"."site_id" = "django_site"."id") WHERE T2."id" IS NULL ORDER BY "django_site"."domain" ASC, "cms_page"."tree_id" ASC, "cms_page"."lft" ASC

into this:

SELECT (1) AS "a" FROM "cms_page" LEFT OUTER JOIN "cms_page" T2 ON ("cms_page"."parent_id" = T2."id") WHERE T2."id" IS NULL LIMIT 1

in get_page_from_path :)

Collaborator

ojii commented Jul 25, 2012

all I see a much shorter scroll bar on github, so that looks very nice to me

Contributor

beniwohli commented Jul 26, 2012

I'd like to cash in one of the roughly ten imperial bazillion[1] queries saved by #1362 to fix this the proper way.

[1] according to @ojii, 1 imperial bazillion == 3.

Collaborator

ojii commented Jul 27, 2012

go!

Member

digi604 commented Aug 14, 2012

what is the status of this PR?

Contributor

evildmp commented Dec 4, 2012

This can be closed now surely. I am not sure what has happened with the code, but certainly since 2.3.something it has not been possible to view - incorrectly - descendants of pages with view restrictions

evildmp closed this Dec 4, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment