There was an interesting race when we cleared the
inBuffer after the WS upgrade. Since during the
upgrade we also transfer the socket to the DocBroker,
which has its own poll thread, the DocBroker poll
could trigger a POLLIN event if data comes
while the handler (that is handling the WS upgrad
and transfer to DocBroker) hasn't got to the point
where it clears the inBuffer of the data we just
read (i.e. the HTTP GET request). Even if not
the case, after transfering a socket to another
poll thread the socket buffers should not be
touched.
Here we move the inBuffer clearing to be as soon
as we have successfully parsed the request and
are ready to process it.
Also, we don't clear the full buffer, in case
we had read into the buffer both the requst
and the first message, if the thread was switched
out right after getting the POLLIN but before
reading from the socket, giving enough time to
receive more data and reading it together with
first read (which is the request).
Change-Id: I9888d4c2b70d2e433824818bbe7f69f13742486c
Reviewed-on: https://gerrit.libreoffice.org/36326
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Apparently pinging was enabled only when
_not_ WebSocket upgraded, which is wrong.
Removed sending ping immediately after
upgrading to WS as it's superfluous.
Change-Id: Ic8103bab063d87f58d371f0eab49f7b7530e2374
Reviewed-on: https://gerrit.libreoffice.org/36322
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Don't think it is necessary/useful to have this header at other places.
This is the most important and perhaps the only where presence of this
header is required and seems sensible to prevent potential attacks.
Change-Id: Iad318e4b83264ac83620b86a40a49e7384e4015e
No idea why it was here in the first place, but download requests are
only made from frames with same origin, so there should be no need to
specify such headers which allow anyone (with other origins) to make
download requests to us.
Change-Id: I314a7ad4c6df8664b1d191cb88ae42c4248ff517
We need to be able to create iframes sometimes with same origin as ours,
eg: when loading the 'loading' page during slideshow or downloading the
file (in different formats). The 'blob:' is only used for printing
purposes.
Change-Id: I93666ee45e707997969e151af5142efeeca0d177
insertfile post requests should be made only from our origin.
Mentioning a '*' against allow-access-allow-origin allows other origins
to be able to make requests to insertfile too provided the attacker
knows the doc key which is not very hard to guess/get.
Change-Id: If98351df48935cfcdc18d6879167c0ac6089796c
Remove unnecessary checks
Rename preprocessFile -> preprocessAndSendLoleafletHtml and
Rename isAdminLoggedIn -> tryAdminLogin
so that their name matches the actual reality of what these
function really does.
Change-Id: I549eae31f8ab0a320bb3ff8ecd17a282b8f91e1a
ie/edge ignores frame-ancestor directive of CSP (yet). Mention X-Frame-Options
for them. Similary, X-Frame-Options allow-from attribute is not
supported by Chrome:
(see https://bugs.chromium.org/p/chromium/issues/detail?id=511521)
In that case, we already have frame-ancestor CSP directive for it.
Change-Id: Ide00c4db88c438de5e9c679360b3da6f4eb4a1be
Unfortunately, our dependencies (various plugins etc.) still make heavy
use of inline event handlers, so not possible get rid of all of them in
our bundled js. This is the reason we still have to use 'unsafe-inline'
in our CSP.
Change-Id: I519dec0834606ab3c56e090c882a93160ddcb52c
None of the subclasses override it, and if they would, it would be
problematic, since e.g. the StreamSocket dtor calls it (and virtual
calls during dtors are a problem).
Change-Id: Ie0891349808a81539078fd1f2d95a55a4ce5107a
Tests should have sensible limits so they don't
go overboard and fail needlessly causing noise.
Change-Id: Idd556c348cc0e97e38c710fdbf76fe20c76d8f9b
Reviewed-on: https://gerrit.libreoffice.org/36241
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Plenty of time to do that next time around the cleanup.
We should still, really be doing the majority of the timeout work
inside the DocumentBroker poll itself.
First reason is that compression is very slow, and we re-compress the
files again and again.
Another reason is that IE/Edge doesn't work well with deflate turned on.
Related: https://connect.microsoft.com/IE/feedbackdetail/view/950689
The documents are not loaded at all with current code snapshot modulo
this patch.
Change-Id: I1fdd85856f448dc4ce02e1ab79e9c7474c3bb7f3
LO core doesn't output any change tracking information for spreadsheets
which results in sending an empty 'commandvalues: ' message to
loleaflet. While the actual fix for it would go in LO core, lets handle
this empty case for now in loleaflet, so that we don't throw any runtime
JS exceptions.
Change-Id: Id2b66b8e7f1c87b074d3e72168e0ca3c3c0d345d
