Expose (partial) person data for unauthorised users
Closed, ResolvedPublic

Description

Currently, any call to fetch person data when not authorised will return a 101 person not found error. While it is understandable that things such as email are not given out without authorisation happening, to avoid scraping and the like, it would be very handy to have less critical information (very specifically names, avatar and homepage) exported even when not authorised.

So, two options here:

  1. Simply remove the requirement for authorisation on the persondata call
  2. Retain the protection for the complete data set, and only send out the following information when not authorised: personid, firstname, lastname, homepage, avatarpic, avatarpicfound, bigavatarpic, bigavatarpicfound, description, and profilepage

I'd of course prefer option 2, because privacy is important...

leinir created this task.Jul 3 2019, 10:55 AM

I also think that the second option sounds better. I think we do it that way.
However, we have to agree exactly what should be publicly available. Following your suggestion and considering our website we would make the following attributes public:

  • username
  • avatar
  • website

We discuss the topic in our team and clarify when and how quickly we can implement it.

leinir added a comment.Jul 3 2019, 1:12 PM

I also think that the second option sounds better. I think we do it that way.
However, we have to agree exactly what should be publicly available. Following your suggestion and considering our website we would make the following attributes public:

  • username
  • avatar
  • website

    We discuss the topic in our team and clarify when and how quickly we can implement it.

Just thought i'd throw in a couple of comments for the discussion as well, since of course i'm not there in person :)

The reason for at least having at least the first name would be to allow us to not show usernames in the UI unless we have to (which is always nice, because the username tends to be more... technical than the name they chose to put into the chosen name field, and because the username can't be changed, while the other name fields can, which is very much an important thing this day and age)

Having the profilepage field filled would be quite important for engagement purposes (so people can be pointed to the store page showing that user's details) - the website is not quite as important, but of course still useful (but having the profilepage as a fallback is important, because not everybody will have the website field filled in)

Thanks for the quick response, too! In the meantime, i have implemented functionality in the WIP patch on D21721 that just sort of expects some of this information to be available, which will make it easy to adapt it when you've got it implemented at your end, but which also has sensible fallbacks so that when the information is not (such as is the case at the moment) it will still look acceptable :)

How's this coming along? :) (i can't finish up the work i'm doing in D21721 without this and T11142 being done)

Just a quick poke, because i kind of need this to happen... how's it coming along? Thanks in advance! :)

ronaldv moved this task from To Do to Work in Progress on the KDE Store board.Aug 23 2019, 9:56 AM
ronaldv added a comment.EditedAug 23 2019, 1:34 PM

OK, some person data are now public:

  • username
  • firstname
  • avatar
  • homepage
  • profilepage

Example:

<ocs>
  <meta>
    <status>ok</status>
    <statuscode>100</statuscode>
    <message/>
  </meta>
  <data>
    <person details="summary">
      <personid>leinir</personid>
      <privacy>0</privacy>
      <privacytext>public</privacytext>
      <firstname>Dan Leinir</firstname>
      <lastname/>
      <gender/>
      <communityrole/>
      <homepage>leinir.dk</homepage>
      <company/>
      <avatarpic>
        https://www.pling.com/member/avatar/a09fca73524dca1a850c3004ebee86fe/800
      </avatarpic>
      <avatarpicfound>1</avatarpicfound>
      <bigavatarpic>
        https://www.pling.com/member/avatar/a09fca73524dca1a850c3004ebee86fe/800
      </bigavatarpic>
      <bigavatarpicfound>1</bigavatarpicfound>
      <birthday/>
      <jobstatus/>
      <city/>
      <country/>
      <latitude/>
      <longitude/>
      <ircnick/>
      <ircchannels/>
      <irclink/>
      <likes/>
      <dontlikes/>
      <interests/>
      <languages/>
      <programminglanguages/>
      <favouritequote/>
      <favouritemusic/>
      <favouritetvshows/>
      <favouritemovies/>
      <favouritebooks/>
      <favouritegames/>
      <description/>
      <profilepage>https://www.pling.com/u/leinir</profilepage>
    </person>
  </data>
</ocs>

This also is looking great! If we could make avatarpicfound be 1 and 0 (rather than true and false), that would be super handy, as that would allow me to not have to change attica's parser, which expects something which can be converted into an integer.

(it's also what the spec suggests, though reasonably we would probably want to ensure that both the string and numeric style boolean values are supported for future use)

Thank you very much :) i shall follow up with a screenshot when i've got it all happy :)

And there we go, ain't it a lovely thing ;)

Looks wonderful indeed! :)

alexanderschmidt closed this task as Resolved.Oct 9 2019, 12:35 PM