Two problem types:
- non-final class has virtual functions but no virtual dtor -> mark the
class final
- abstract class has no virtual dtor -> add a virtual dtor
Change-Id: Iae208b65c774e6da7a3dda5e725fe07d4d589e4f
File extensions marked as view (as opposed to edit)
in discovery.xml are now forced to be read-only,
regardless of what the client tries to request.
Change-Id: I3eb00c33ff716800dc317f7377281c6d5f0909d7
Reviewed-on: https://gerrit.libreoffice.org/38480
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
There is one known problem still - after any user decides to overwrite
the file to storage, other users are not informed, so their dialog keeps
hanging on the screen until they press the cancel or reload button.
Change-Id: I6dad1585e4c53eeed79cd38316892a7f239d44ef
Introduce a new header X-LOOL-WOPI-Timestamp
This is a WOPI header extension to detect any external document change. For
example, when the file that is already opened by LOOL is changed
in storage.
The WOPI host sends LastModifiedTime field (in WOPI specs) as part
of the CheckFileInfo response. It also expects wsd to send the
same timestamp in X-LOOL-WOPI-Timestamp header during WOPI::PutFile. If
this header is present, then WOPI host checks, before saving the
document, if the timestamp in the header is equal to the timestamp of
the file in its storage. Only upon meeting this condition, it saves the
file back to storage, otherwise it informs us about some change
to the document.
We are supposed to inform the user accordingly. If user is okay
with over-writing the document, then we can omit sending
X-LOOL-WOPI-Timestamp header, in which case, no check as mentioned above
would be performed while saving the file and document will be
overwritten.
Also, use a separate list of LOOL status codes to denote such a change.
It would be wrong to use HTTP_CONFLICT status code for denoting doc
changed in storage scenario. WOPI specs reserves that for WOPI locks
which are not yet implemented. Better to use a separate LOOL specific
status codes synced across WOPI hosts and us to denote scenario that we
expect and are not covered in WOPI specs.
Change-Id: I61539dfae672bc104b8008f030f96e90f9ff48a5
userextrainfo is a json array that contains
extra user-specific links.
Currently 'avatar' is assumed to hold the
image url for the user's avatar.
'mail' and other links can also be added.
Change-Id: I37c4c68bfa0b7ee659e017b4867dcb8cf5c2ca2f
Reviewed-on: https://gerrit.libreoffice.org/38120
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Turns out this introduces two calls to the CheckFileInfo which is not really
what we should be doing; instead, let's do a kind of cannonicalization in the
WOPI host directly.
This reverts commit ec2fd0844f.
Change-Id: I311bf8a45b706ed9a4d8cd00db0a990ac6d461b4
The docKey creation moved to Storage where we first
invoke WOPI (if/when it's a WOPI-hosted doc and WOPI enabled)
and see if the user has access to the document at all.
If they do, we expect the server to give us a
unique ID to use for identifying the host regardless
of hostname aliases.
If a unique ID is not returned (i.e. empty or missing)
we use the hostname and port in its place as fallback.
This will break hostname aliases, but it will still work.
Change-Id: I407b0087395f9df6ad9cc6e037570487999be4a4
Reviewed-on: https://gerrit.libreoffice.org/37697
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
...but in combination with the appropriate session's access_token to always
authenticate against the same instance of the WOPI host.
Change-Id: Ic94dfa8fcb226a2d134272b22edc1f8f76c24e34
Detection of modified documents used the
directory path rather than the document
path, which obviously wasn't correct.
Change-Id: I4a054a9ce2b64d70cd7a0a1c488dcc38ef46a581
Reviewed-on: https://gerrit.libreoffice.org/35526
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
And not as the current time. The getLocalFileInfo() and
getWOPIFileInfo() functions will reset it anyway.
Change-Id: Ief821482cf789113cecd85e5d59afecf6ad2c3ab
It would be another thing if it would be abstract and overridden in
the concrete derived classes. But now it just returns the _fileInfo
field that is set by the separate getLocalFileInfo() and
getWOPIFileInfo() functions. Possibly this should be re-designed
and/or stuff re-named for clarity.
Change-Id: I30d01277ac0c6bd4b9daa317aade319b6ef39342
using these WOPI protocol extensions: DisablePrint,
DisableExport, DisableCopy. All assumed to be false if not
provided.
Change-Id: I415597d710107f9d8cbb8757f361365cc2a88eb1
