-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow Remote avatars #14856
Allow Remote avatars #14856
Conversation
@LukasReschke passing the share token around is not a problem I assume since we do it as well to initiate s2s shares? CC @PVince81 |
Mhm. Thinking twice about it in my opinion it's also okay to not require any share token at all and just expose all avatars. That would allow other use-cases as well. But that would then need to be documented somewhere. I can take care of that… |
That would be simpler indeed. |
Generally speaking: Exposing information is okay as long as we don't give a full list of users to unauthenticated 3rdparties and it is documented and can so be considered part of the threatmodel. |
return new DataResponse([], Http::STATUS_BAD_REQUEST); | ||
} | ||
|
||
return $this->getAvatar($userId, $size); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add a check for $size
to avoid problems when someone tries to fool us?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the getAvatar function already checks size
If we will allow all avatars to be fetched anyway this PR is obsolete. Since then everybody could just use the default avatar interface. However, this would make it possible to get the entered name of the user if no avatar is set. Is this acceptable? |
rescheduling this for 8.2 - we are entering freeze for 8.1 tomorrow |
@rullzer @schiesbn what’s the status here? This is pretty cool for federated sharing. :) |
@jancborchardt the status is 8.2 is less important then 8.1 at the moment ;) |
@jancborchardt well it should not be hard. Howeverer,
Just serving the image is easy... the other stuff might need some discussion. Also not that hard but choices have to be made :) |
I'd like to continue this. So that 8.2 can have awesome remote avatars! The code now has tests! @DeepDiver1975 the current path is: index.php/avatar///remote?token= is that fine or should that be modified? For me it makes sense to have all the avatar routes grouped @LukasReschke should I switch back to 1 response code to make it harder to get info? |
/** | ||
* Return an avatar for remote shares. If userA shares with userB there are multiple scenarios | ||
* - userB did not yet accept the share. userB can retrieve avatar of userA with the token | ||
* - userB accepts the share. Now userA can retrieve the avatar of UserB |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem with this is, that the activity app can therefor not make any use of remote avatars at all?
Or we need to make two requests: 1. check if the image is served and then embed the code for the avatar 2. load the avatar
Are avatars really so secret, that we can not allow displaying them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well it would make the code easier of course. And indeed make avatars also better usable for other apps.
I don't think they are that secret. But maybe other people do...
Thinking about this again I'd just expose |
@LukasReschke ok that should be easier. Of course it then could also expose the full name (if no avatar is set). I'll modify the PR. Should get a lot simpler. |
That is better. avatar#getAvatar is public now.
Pretty simple really. Review time. |
Review time: @LukasReschke @MorrisJobke @PVince81 @Xenopathic @nickvergessen should not be hard. |
@@ -84,12 +84,18 @@ public function __construct($appName, | |||
|
|||
/** | |||
* @NoAdminRequired |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PublicPage implies this. Redundant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed :)
Besides my remark: Should be good to go 👍 |
so this is supposed to be a public api - right? |
OCS can per definition not serve arbitrary binary content. We really do not want to go base64 encode data for this purpose. WebDAV, well… would require some more insight on the plans here first. |
|
hmmm |
So probably best to wait with this PR until after the conference where @DeepDiver1975 will present us his idea's for more webdav related stuff. |
@jancborchardt this is the PR for the avatars |
... and it needs a rebase ;) |
A new inspection was created. |
Works 👍 |
why was this merged? there are open todos and the approach is still questionable |
@DeepDiver1975 Any news about this PR? |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
PR for #14564
Added a function to the avatar controller to deal with remote avatar calls. This function takes as input the userId, size and the share token.
This share token is used to retrieve the share, It is then matched against the userId. There are two possible scenario's.
If userA (on instance A) shares with userB (on instance B).
Still todo:
Future work: