PDF export, signing and upload needs to be done in one operation
as PDF doesn't change the current document. The workflow is just
a bit different to the ODF / OOXML that it needs a change in
behaviour.
Change-Id: I752b293494a2d677fa7f12f2317954cfcf47859b
Unfortuantely it still fails, but this is not regression. Now
with the new patch in Core the exception is caught and so at least
the binary survives (and the API returns 0).
New unit-test added in Core to help track the issue down and fix.
Also, free the memory allocated by the API.
Change-Id: I5d788a2ee0383de1c323af4cd6b39b8615a35baf
This shows what the current document status is in the signing
infobar.
When logging in into vereign we need to check the current document
as we have all the needed certificates avaliable.
Change-Id: I7fb4420d0b80a6d0fa553fca2f0be7b6dec6249f
Reviewed-on: https://gerrit.libreoffice.org/64333
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Save document to a input format (either PDF, ODT, DOCX) and send
the document to Vereign using WOPI protocol.
Change-Id: If9a7d88e91d07c7f1f831c01793f0f73d7a98131
Reviewed-on: https://gerrit.libreoffice.org/63839
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
And also:
* Hint the compiler to warn about the missing callbacks.
* Add few missing ones.
* Update the bundled headers.
Change-Id: I8d31363eaaea289e8a517c0b9b1142b33ce3027e
In addition:
- add methods to transport the certificate chain, signing
certificate and signing certificate to WSD
- add conversion of PEM cert. format to DER
- add transporting the certificate chain to the LO core
- run the signing function with the signing cert. and the
private key
Change-Id: I1a005e88cacbd81144df40d315197561401db427
Reviewed-on: https://gerrit.libreoffice.org/63156
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
This adds handling of signature status (manually request for the
status or as a callback) in WSD.
In addition prepare support for signing of document, but don't yet
trigger the actual LOKit function (needs the JS building blocks
set up first to know how to handle the payload - certificate and
private key)
Change-Id: Ic76baa5847bb52adde616338187d5979e0093c6d
Reviewed-on: https://gerrit.libreoffice.org/62533
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Also support anonymization of downloadas documents
and renaming of documents.
Reviewed-on: https://gerrit.libreoffice.org/57541
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
(cherry picked from commit 78248a542c9ca31bf9ad4cad9b55d78690384395)
Change-Id: I81a80e6290217659987d73f625e5f0fb81cb7ef2
Re-think the plumbing between the different parts of the C++ Online
code. Do try to have it work more like in real Online on all but the
lowest socket level. Except that we don't have multiple processes, but
threads inside the same process. And instead of using actual system
sockets for WebSocket traffic between the threads, we use our own
FakeSocket things, with no WebSocket framing of messages.
Reduce the amount of #ifdef MOBILEAPP a bit also by compiling in the
UnitFoo things. Hardcode that so that no unit testing is ever
attempted, though. We don't try to dlopen any library.
Corresponding changes in the app Objective-C code. Plus fixes and
functionality improvements.
Now it gets so far that the JavaScript code thinks it has the document
tiles presented, and doesn't crash. But it hangs occasionally. And all
tiles show up blank.
Anyway, progress.
Change-Id: I769497c9a46ddb74984bc7af36d132b7b43895d4
We already use a suffix "Interface" for SocketHandlerInterface, so
rename IDocumentManager to DocumentManagerInterface.
Naming "interface" classes with an "I" prefix is C# and COM style.
Sure, that is a convention as good as any other, but let's try to be
consistent within this rather small code-base.
Change-Id: I9c356df327debd780f23ed2b2e6d6e630328861e
The app is unimaginatively called "Mobile" for now.
Runs but crashes pretty quickly after loading the document by the LO
core. Will need some heavy changes to get a ClientSession object
created in there, too, to handle the (emulated) WebSocket messages
from the JavaScript. It would then handle some of these messages
itself, and forwards some to the ChildSession, which in this case is
in the same process. Now the messsages from the JavaScript go to a
ChildSession, which is wrong. As the assertion says, "Tile traffic
should go through the DocumentBroker-LoKit WS"
Although, at least for me, after calling LOK's saveAs with an
intentionally bogus file extension 'file:///user/docs/u0.frobozz'
retrying with 'file:///user/docs/u0.frobozz.odt' does not work either.
Actually, I am not sure how useful this retry feature is as it is now.
If the user tries to save as some unsupported format, why can we
assume that maybe they want to save in some other format instead, and
possibly overwrite an existing file? Maybe the retry should be done
only if the file name to saveAs was without extension? But that was
already discussed in gerrit, I see.
Change-Id: I8bd4fbf241cb492d9654ae893af4baaf28b6b3a0
This already worked for normal save, but not for convert-to.
Depends on core.git commit 0518bb5c3a98d973c3675fdd4cb8c52a669a3507
(desktop lok: handle NoFileSync in saveAs(), 2018-03-26).
Change-Id: Iec1a92fba2094f3954cc1a4ed6ee3372076fddc5
What LibreOffice sees as a save destination is just a temporary output
from the outside, so there is no point in doing fsync for that file.
This depends on core.git e90a16d71cdcfbd785401613a2e5a29cb1167acf (sfx2
store: handle NoFileSync for Save (not SaveAs), 2018-01-15).
