Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-29847

Granulated access to user data

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: InputQ
    • Priority: High
    • Resolution: Unresolved
    • Affects Version/s: 1.7.8, 1.13.4, 2.2.3, 2.3.2
    • Fix Version/s: None
    • Labels:

      Description

      User data can be divided into 3 categories, by accessibility required for normal function:

      1. User name (and photo), as is displayed when the user is the author of public content. Other users have no data in this category. Should be publicly accessible when the user has authored public content, in the display of that content, otherwise not.
      2. All other user data. Should be accessible to the user themself and those who have read access to the User content. Except...
      3. Password hash, should be accessible to no-one except the code that validates passwords.

      Currently, when someone is granted read access to User content, they can access all of these (to be verified) through the API. On the other hand, if they don't have this access, they can't see who is the author of public content, unless special measures has been taken for this, like fetching it with sudo(), or cloning the author info into a separate content, or field in the public content. This is not ideal.

      If any site admin gives anonymous users access to read User content (in order to make it easier to display content authors) then they are opening up a major security hole - the API might then allow anyone to harvest user emails, physical location / home address if that's registered, possibly even password hashes. It's the responsibility of the site admin not to do this, but is the current API encouraging this bad setup?

      Can we make the access more granulated, so that it works more like expected?

      • First priority would be ensuring that password hashes cannot be read by anyone.
      • Second priority would be making author profiles accessible without read access to the content - though this is a major task, it means overriding our content security system and could open up new security holes. Or it can be done with field-based permissions, if we develop that. Can it be resolved with good documentation of sudo and other approaches, instead?

      CC Gaetano Giunta Gaetano Giunta Andrzej Longosz André Rømcke

        Attachments

          Activity

            People

            Assignee:
            Unassigned
            Reporter:
            gunnstein.lye@ez.no Gunnstein Lye
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated:

                Time Tracking

                Estimated:
                Original Estimate - 0 minutes
                0m
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 1 hour, 30 minutes
                1h 30m