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>
* fix: collaboration service name
* change: do not use app name in service name
* feat: make collaboration service name configurable
* test: fix test config
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.
This will allow multiple collaboration services to target 2, 3 or more
different WOPI apps. It's expected that each different collaboration
service is deployed in a different container or host