Add more WOPI extensions for this - HidePrintOption,
HideSaveOption, HideExportOption. Setting HideExportOption to
'true' in WOPI CheckFileInfo response would hide the 'Download
as' option from the File menu.
Change-Id: Ia2259ee9525cc6c4331a52e2221af4df188eab07
This implements a new feature 'OwnerTermination' for WOPI based
hosts. WOPI hosts now have to enable this feature by mentioning
'EnableOwnerTermination' as 'true' in their CheckFileInfo
response. If the OwnerId of the file matches that of the UserId
of the session, this session would be able to terminate all other
sessions currently editing the same document.
The reason for this kind of document termination is sent to all
sessions in a new application-level 'close:' message. This new message is
similar to the CLOSE frame of WebSocket protocol which doesn't
seem to work across all browsers as of now. Eg: Chrome -
https://bugs.chromium.org/p/chromium/issues/detail?id=426798
After receiving this 'close: ' message, loleaflet acts
accordingly and tells the WOPI host why the websocket was closed
via post message API.
Change-Id: I997aa2e7805157ed599a3946a877fd32477cee1b
The idea, for now, is to call the storage specific fileinfo
functions (getLocalFileInfo, getWOPIFileInfo) which returns the
file + user specific data for given URI. By user specific, it
means data which is token (provided in URI) dependent.
For WOPI, it would mean various user permissions
(editable/viewable etc.)
For our current storages, these calls also include the basic file
information which is common across all tokens. This can be
retreived by calling getFileInfo on the storage object.
Change-Id: Ibbd3b74b011d8bb6fe4730c33276ef9ac6c47103
permission= parameter in URL is still supported, but overridden
by UserCanWrite parameter.
Also, introduce a new protocol message, perm: which dictates
loleaflet about the permission rather than the other way around
(only in case of WOPI)
It is to be noted that by default loolwsd assumes very
restrictive permissions, so not providing UserCanWrite in WOPI
implementation by a WOPI host would lead to opening of only
readonly session.
Change-Id: I2013c1661fd491c79bb367a41e1a7036fa03f984
Use the previously unused UnauthorizedRequestException for this, and
throw a such in StorageBase::create() when the WOPI host doesn't match
any of those configured.
In a developer debug build, without access to any real WOPI
functionality, you can test by setting the FAKE_UNAUTHORIZED
environment variable and attempting to edit a plain local file:
URI. That will cause such an exception to be thrown in that function.
Catch that UnauthorizedRequestException in
ClientRequestHandler::handleGetRequest(), and send an 'error:
cmd=internal kind=unauthorized' message to the client. Handle that in
loleaflet in the same place where the 'error: cmd=internal
kild=diskfull' message is handled, and in the same fashion, giving up
on the document.
Actually, using exceptions for relatively non-exceptional situations
like this is lame and makes understanding the code harder, but that is
just my personal preference...
FIXME: By the time StorageBase::create() gets called we have already
sent three 'statusindicator:' messages ('find', 'connect', and
'ready') to the client. We should ideally do the checks we do in
StorageBase::create() much earlier.
Also consider that ClientRequestHandler::handleClientRequest() has
code that catches UnauthorizedRequestException and
BadRequestException, and tries to set the HTTP response in those
cases. I am not sure if that functionality has ever been exercised,
though. Currently, we upgrade the HTTP connection to WebSocket early,
and only after that we check whether the WOPI host is authorized
etc. By that time it is too late to return an HTTP response to the
user. If that even is what we ideally should do? If not, then we
probably should drop the code that constructs HTTP responses and
attempts to send them.
Also, if I, as a test, force an HTTPResponse::HTTP_BAD_REQUEST to be
sent before the HTTP connection is upgraded to WebSocket, loleaflet
throws up the generic "Well, this is embarrassing" dialog anyway. At
least in Firefox on Linux. (Instead of the browser showing some own
dialog, which I was half-expecting to happen.)
Reduces the number of WOPI calls made during a document load. Earlier
effort was made in edfd3266f8
This commit cleans up and uses better approach for the same.
Other than that, access token of each session is now correctly
used when interacting with the storage. Earlier, we used to
use the same access token for each upload to storage which means
that irrespective of who clicked the save button, changes to the
document were only made on behalf of one person (of whom the
access token is used). This is fixed now.
Also includes minor cleanup left and right.
Change-Id: Id32702ff02aea4f63b7cc6afa9f62664807bb57d
Reviewed-on: https://gerrit.libreoffice.org/29931
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
This reduces the number of fileinfo calls made to storage. These calls can
be expensive in storage such as WOPI where loolwsd needs to
interact with another server to get the file information. Use the
same storage object once created so that fileinfo can be
cached and returned quickly for subsequent such calls.
3 GetFileInfo WOPI calls are now merged into 1.
Change-Id: I56c3d23d3d6d7dc3a4b42433f51304dac28a12e8
This saves us from encoding/decoding mess of URIs. Poco::URI is
flexible enough and can give encoded or decoded version whenever
required, so lets avoid storing the URI in std::string where we
have no information about whether its encoded or not.
Change-Id: I4a6979e13b20d9f56fc5a0baa630cb1b35ca33b0
URI::getPath() returns a _decoded_ path which was then being used
for the requests. This leads to failure for WOPI urls having
space in them.
Change-Id: I47bef643b09a919c56f9f0ec7b4dee8604dde089
Reviewed-on: https://gerrit.libreoffice.org/29536
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Sends the same 'error: cmd=internal kind=diskfull' message as when
disk space for LOOL's own needs is getting full, but only to the
user(s) of that document. We can't in general know whether one
document in the Storage abstraction is located even close to another.
Hopefully useful in general, but currently I need this to see if view
ids are mapped to the correct user names even with file:/// URLs.
Change-Id: Iec7d552ee0b0d53738040d868e49ecb7e9c10843
SSL support is enabled by default, it can be disabled by passing the
`--disable-ssl` switch on the command line or by setting `ssl.enable`
property in loolwsd.xml config file.
It is still possible to build loolwsd with no SSL support at all.
Change-Id: I00f952edc64f87f61505af44fdc2a715780dc44c
Reviewed-on: https://gerrit.libreoffice.org/27288
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
README suggests not using an initial underscore for those. Rename the
few cases which don't respect this recommendation.
Change-Id: If36a36da9374597f6b9090e7f81a1b3fb2f23647
A source file (.cpp) must include its own header first.
This insures that the header is self-contained and
doesn't depend on arbitrary (and accidental) includes
before it to compile.
Furthermore, system headers should go next, followed by
C then C++ headers, then libraries (Poco, etc) and, finally,
project headers come last.
This makes sure that headers and included in the same dependency
order to avoid side-effects. For example, Poco should never rely on
anything from our project in the same way that a C header should
never rely on anything in C++, Poco, or project headers.
Also, includes ought to be sorted where possible, to improve
readability and avoid accidental duplicates (of which there
were a few).
Change-Id: I62cc1343e4a091d69195e37ed659dba20cfcb1ef
Reviewed-on: https://gerrit.libreoffice.org/25262
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Since auto-discovery is problematic, this patch implements
support for both regex patterned hostnames/IPs to allow,
and those to block/deny.
A hostname/IP must be both allowed, and not denied, to
be accepted.
By setting ranges of allowed hostnames/IPs, and others
to block/deny, an admin can configure Online with
great flexibility.
Defaults updated with same values, but not exhaustive.
Change-Id: Iedfcafe41d07d905b549fb450c3fe625ad44599e
Reviewed-on: https://gerrit.libreoffice.org/24233
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
