[IMPLEMENTED] Disclosing admin panel user email addresses

Feature Requests Implemented Features
1

I have…

  • [ x ] Read the following guideline: Troubleshooting and Support | Squidex. I understand that my support request might get deleted if I do not follow the guideline.
  • [ x ] Used code blocks with ``` to format my code examples like JSON or logs properly.

I’m submitting a…

  • Regression (a behavior that stopped working in a new release)
  • Bug report
  • Performance issue
  • [ x ] Documentation issue or request

Current behavior

user emails can be retreived by public clients

Expected behavior

Minimal reproduction of the problem

Environment

App Name:

  • [ x ] Self hosted with docker
  • Self hosted with IIS
  • Self hosted with other version
  • Cloud version

Version: 7.8.1

Browser:

  • Chrome (desktop)
  • Chrome (Android)
  • Chrome (iOS)
  • Firefox
  • Safari (desktop)
  • Safari (iOS)
  • IE
  • Edge

Others:

Clients with minimal read permitions via rest or graphql api can see user emails, ids and full names that do some work at admin panel.
We can see it in fields createdBy, createdByUser, lastModifiedBy, lastModifiedByUser. I cant hide/override this fields via scripting or roles. This client dont have user permitions. Just read contents and assets.
Any solutions?

Example GraphQL request:

{
  findPagesContent(id: "00000000-some-guid-0key-111111111111"){
    id
    flatData{
      code
      parent {
        id
      }
    }
    version
    createdBy
    createdByUser{
      id
      displayName
      email
      __typename
    }
    lastModified
    lastModifiedBy
    lastModifiedByUser{
      id
      displayName
      email
      __typename
    }
  }
}
2

There is already a “public” user endpoint, that is used to find users for the contributor list. But I understand the reason to change that. The question is, what would be the expected behavior. I am not sure if the solution is a permission on the app level.

3

In previous versions, the public endpoint only returned contributors with logins via external services like Google, GitHub, etc. It did not return contributors with password logins. But I think this endpoint should also use permissions.

As for the behavior, my guess is that permissions should be added to access contributors information that may or may not be added to some roles.
Disclosing members is not a high-stakes behavior, but in some cases they should be hidden from some clients. It’s a security issue.

4

Can we hide contributors information from clients in this squidex version(7.8.1) without code rewriting or it can be added only in new version?

5

There is only one user table, so I think this cannot be correct.

It is probably a code change, but I am not sure how it needs to look like.

6

Will you try to implement this somehow in the next version?
I think this article is already moving into the “Feature Request” category)

7

I am still not sure about the requirements. If you have the same information available via other endpoints, what is the purpose then. I think the behavior should be consistent and probably not based on permissions, because the other endpoint is not related to apps.

8

In particular, in our system one of the clients is public UI (anyone can find the token).
I think that in general for any system, behavior that reveals the email addresses of its internal employees is undesirable.
This should be regulated somehow. Unfortunately, in this case I can’t tell you how exactly.

9

I understand. I could add a permission for that, but it would not block content editors or other Squidex users from seeing that.

1 Like