MoinMoin ACL page is not updated after valid Launchpad team login

Bug #302911 reported by Andrew Glen-Young
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Moin OpenID module
Confirmed
Medium
Unassigned

Bug Description

The MoinMoin team/group ACL page is not updated after a user has successfully logged in using a valid Launchpad OpenID account and who is a member of a valid team.

This means that the user is logged in (or Known in MoinMoin terminology), but since there are explicit ACLs applied to the wiki and they are not a member of a valid team/group they cannot see the wiki content. (i.e. They are authenticated but not authorised).

Unfortunately, this bug is very intermittent and I have yet to reproduce. Whenever this error has occurred I have asked the user to try the workaround (shown below), while observing the logs, but I have not seen the error reproduced.

This maybe a problem with the way that we are dynamically updating/creating the ACL page during the login phase. But I would expect MoinMoin to at least throw some errors in the logs.

The steps and symptoms are listed below.

Relevant Moin config options:

    # Team to request.
    openidrp_authorized_teams = ['canonical']

    # Group page postfix.
    openidrp_acl_page_postfix = 'TeamACL'

    # Moin admin who can create *TeamACL group pages.
    openidrp_acl_admin = 'AclAdmin'

    # Give the AclAdmin admin rights.
    acl_rights_before = u"AclAdmin:read,write,delete,revert,admin"

    # Allow members of the canonicalTeamACL group page access.
    acl_rights_default = "canonicalTeamACL:read,write,delete,revert All:"

    # Group pages end with this postfix.
    page_group_regex = ur'(?P<all>(?P<key>\S+)TeamACL)$'

Steps to reproduce:

 Prerequisites:

  1. Ensure that you are not a member of the *TeamACL page (using the above example canonicalTeamACL)
  2. Ensure that you are logged out and do not have a valid MoinMoin cookie.
  3. Ensure that you are in a Launchpad team with access to the wiki (canonical team).

 Steps:

  1. Browse to the wiki and observe the authorisation message: 'You are not allowed to view this page.'
  2. Click the 'Login' link.
  3. Login using your valid Launchpad OpenID credentials.
  4. You should be redirected back to the wiki.
  5. Observe that you are logged in (you LP username is shown), but you do not see the wiki page and are still prompted with the above authorisation message.

  If I browse to the ACL page I can see that the user has not been added to the page.

 Workaround (I have annecodatal evidence that this works):

  1. Click the 'Logout' link.
  2. Follow the LP OpenID "dance" again.
  3. Once the user is redirected back to the wiki they see the pages as expected.

  If I browse to the ACL page I can see that the user has been added to the page.

Changed in canonical-bis-openid:
assignee: nobody → stuartmetcalfe
Revision history for this message
Stuart Metcalfe (stuartmetcalfe) wrote :

Also doesn't seem to prevent viewing the page on the logout request. Requires user to refresh the page in order to prevent access.

Changed in canonical-bis-openid:
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Stuart Metcalfe (stuartmetcalfe) wrote :

Additional step to reproduce:

4. Ensure user has not previously logged in to site (remove relevant file from {$wiki}/data/user/ and clear cache)

With this additional step I can reproduce the problem consistently. This occurs because OpenIDAuth._handle_verify_continuation() doesn't pass the teams data to OpenIDAuth._handle_name_continuation() if the user is not found by their openid url and would therefore require a new user to be created.

affects: canonical-bis-openid → moin-openid
Revision history for this message
Stuart Metcalfe (stuartmetcalfe) wrote :

I think I might have fixed this. Whoever picks this bug up should check that before starting work

Changed in moin-openid:
assignee: Stuart Metcalfe (stuartmetcalfe) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.