Uploaded image for project: 'XWiki Platform'
  1. XWiki Platform
  2. XWIKI-19559

The fact that a user is inactive is far from being taken into account everywhere

    XMLWordPrintable

Details

    • Integration
    • Unknown
    • N/A
    • N/A

    Description

      Currently, a disabled user is still authenticated and set in the standard context and only really taken into account in XWiki#prepareDocuments which generate an exception for all actions but only

      if (!((action.equals("skin") && (doc.getSpace().equals("skins") || doc.getSpace().equals("resources")))
                      || ((action.equals("skin") || action.equals("download") || action.equals("ssx") || action.equals("jsx"))
                          && getRightService().hasAccessLevel("view", XWikiRightService.GUEST_USER_FULLNAME,
                              doc.getPrefixedFullName(), context))
                      || ((action.equals("view") && doc.getFullName().equals("XWiki.AccountValidation"))))) {
      

      But it's not taken into account in the REST API (or all resource reference handler which require an authenticated user) which means the user can pretty much do anything it wants (including enabling itself I think, unless there is a listener to protect that).

      IMO, the user should be authenticated but should not be set as context user and instead be set in a special property storing the disabled user so that things related to disabled user can check it. That way, the access is safe by default (most of the code will see the context as not being authenticated) and only if you want to do something special with disabled user (like a process to be granted access again) you still have the info.

      Reproduction steps:

      • Create a user Foo and disable it
      • Send following request with Foo authentication headers:
        curl -X PUT -i 'http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/XWiki/pages/Foo/objects/XWiki.XWikiUsers/0/properties/active' --data 1
        
      • Login with Foo on the wiki

      Expected result:

      • Foo should still be disabled and the CURL request should not work

      Obtained result:

      • Foo is now enabled

      Attachments

        Issue Links

          Activity

            People

              surli Simon Urli
              tmortagne Thomas Mortagne
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: