Why the User Endpoint not include email ?

Issue #8570 wontfix
samuel hints
created an issue

.

I for to register user in my application send two request. One by /api/1.0/user for receive username and another by /api/1.0/users/username/emails.

This can only to be one request. for example :

"user": {
        "username": "1team",
        "first_name": "1 Team",
       ******** HERE *********
         "email" : {
             "active": true,
             "email": "1team.bb@gmail.com",
             "primary": true
         },
       ******** /HERE *********
        "last_name": "",
        "is_team": true,
        "avatar": "https://secure.gravatar.com/avatar/24b6be68b53e383c5d42bab4fe
0bde2b?d=https%3A%2F%2Fdwz7u9t8u8usb.cloudfront.net%2Fm%2Fcc0a0a43301e%2Fimg%2Ft
eam_no_avatar_32.png&s=32",
        "resource_uri": "/1.0/users/1team"
    }

Comments (11)

  1. Erik van Zijst staff

    Thanks for the suggestion.

    Email addresses are very deliberately not disclosed through our UI or API. It would make it trivial to harvest them by spammers.

    The 1.0 APIs are no longer further developed and so we won't be making changes to them anymore.

    The 2.0 API on the other hand uses consistent object representations across different endpoints. What that means is that a user object always looks the same, regardless where it was returned.

    Since email addresses are never accessible for any user, except your own account, it we couldn't really add them to the user object, as it would just be empty the entire time, except when requesting your own user.

    So having your email addresses (and all other properties relevant to your own account) in separate resources is intentional.

  2. samuel hints reporter

    .

    About repositories we have two type repo, one is public and another is private. public repo's are public for all even without authenticate, but private repo's are public only for application's and base oauth.

    So, we can use this scenario for emails, the user endpoint return email only for application's and base oauth and not for all .

  3. Erik van Zijst staff

    So, we can use this scenario for emails, the user endpoint return email only for application's and base oauth and not for all .

    I'm afraid I don't think I understand what you mean.

  4. samuel hints reporter

    .

    A bitbucket application have to access to private and public repositories, emails and more. So , the user endpoint can to like this :

    Request: /api/1.0/user/

    Show for all :

    "user": {
            "username": "1team",
            "first_name": "1 Team",
           ******** Without Primary Email *********
    
           ******** /Without Primary Email *********
            "last_name": "",
            "is_team": true,
            "avatar": "https://secure.gravatar.com/avatar/24b6be68b53e383c5d42bab4fe
    0bde2b?d=https%3A%2F%2Fdwz7u9t8u8usb.cloudfront.net%2Fm%2Fcc0a0a43301e%2Fimg%2Ft
    eam_no_avatar_32.png&s=32",
            "resource_uri": "/1.0/users/1team"
        }
    

    ..........................................................................................

    Show for bitbucket applications or own user :

    "user": {
            "username": "1team",
            "first_name": "1 Team",
           ******** Public only for bitbucket app's and own user *********
             "email" : {
                 "active": true,
                 "email": "1team.bb@gmail.com",
                 "primary": true
             },
           ******** /Public only for bitbucket app's and own user *********
            "last_name": "",
            "is_team": true,
            "avatar": "https://secure.gravatar.com/avatar/24b6be68b53e383c5d42bab4fe
    0bde2b?d=https%3A%2F%2Fdwz7u9t8u8usb.cloudfront.net%2Fm%2Fcc0a0a43301e%2Fimg%2Ft
    eam_no_avatar_32.png&s=32",
            "resource_uri": "/1.0/users/1team"
        }
    
  5. Erik van Zijst staff

    Ah yes, we definitely could. However a client would then need to anticipate that this data is not always there (in fact, it's practically never there, except for this one exception).

    The same reasons for adding personal account information to a user object could then set a precedent for other types of information. Maybe your SSH keys could be added too? Your plan information, or connected OAuth apps?

    I think it's reasonable to not include an ever growing list of data in an object, but instead to try and find a balance between the number of object elements and their relevance.

    In case of email addresses that we do not expose to anyone but the account holder, we've decided to keep that out of the user object.

  6. samuel hints reporter

    Now, I have another problem.

    The /api/2.0/users/khosroblog request is include the user website, but the /api/1.0/user request is not.

    I think the user endpoit is very usefull for developers, because it is current user.

  7. Log in to comment