Add UserExtraInfo (avatar + mail) to the WOPI CheckFileInfo response for
authenticated, non-public-share users.
UserExtraInfo format (per Collabora SDK):
https://sdk.collaboraonline.com/docs/advanced_integration.html#userextrainfo
```json
{
"avatar": "http://url/to/user/avatar",
"mail": "user@server.com"
}
```
After this change, CheckFileInfo returns:
```json
{
"BaseFileName": "Pedro-filled-hazcom.docx",
"UserFriendlyName": "Admin",
"UserId": "346364...39323030",
"UserCanWrite": true,
"UserCanRename": true,
"IsAdminUser": true,
"EnableInsertRemoteImage": true,
"EnableInsertRemoteFile": true,
"EnableOwnerTermination": true,
"UserExtraInfo": {
"avatar": "https://host:9300/wopi/avatars/{userID}?access_token={wopiToken}",
"mail": "admin@example.org"
},
"PostMessageOrigin": "https://localhost:9200",
"message": "CheckFileInfo: success"
}
```
Avatars are served via a new /wopi/avatars/{userID} endpoint on the
collaboration service, authenticated by the WOPI token. The endpoint
calls the Graph service directly (bypassing the proxy) using the reva
access token via x-access-token header.
All tests pass:
go test ./services/collaboration/... ./services/graph/... ./services/proxy/...
Signed-off-by: Pedro Pinto Silva <pedro.silva@collabora.com>
MD5 will make the token shorter. The timestamp will help to prevent
collisions since the tokens must be generated at the same nanosecond
(assuming the md5 sum generates the same hash, which is unlikely).
Using MD5 shouldn't be a security issue. The "real" access token is
already encrypted, and it's visible and accessible if short tokens
aren't used.
The "real" access token will be stored using the short token as key.
This short token will be sent to the clients to be used as access token
for the WOPI server.
This is configurable, and requires a store in order to keep the tokens.
We're using the file id from the access token, so changing the file id
in the URL shouldn't matter. However, the file id must represent a
single file.
It will also help to detect unwanted changes in the URL.
