The summer is coming to an end. August is almost here. But we are still making progress and have just finished yet another version. This time we continue to focus on the exporting capability due to its significance for future features. But we have also made automatic deployment part of our build pipeline, allowing us to publish a live version of Doksi that you can checkout without having to deploy it locally.
Live demo
You can finally checkout a live version of Doksi at doksi.herokuapp.com.
As part of our pipeline we are now publishing Doksi on Heroku on every tag. This should currently be considered just a demo environment, which may be purged at any time. In the future we may promote this to a more permanent environment.
Improved exporting
Version 0.5.0 comes with several improvements related to export of documents. More formats, support for encrypted documents and asynchronous operations allowing users to follow the progress step by step.
Export to ePUB and HTML
Last version we added the ability to export to PDF. This is done by assembling the ReST files of all blocks, and run them through Sphinx to build the document.
In this version we extend that to support the other two formats that are included with Sphinx: ePUB and HTML. Since HTML is made up of multiple files we run them through an archiver which will package the HTML folder with Zip (because it’s available on every platform), Tar with Gzip and Tar with Xz.
Asynchronous exporting
Since the export process takes a while, especially if the document is large with many cross references, we have made the export API asynchronous. The first request to the /documents/:id/export endpoint will return a job ID. Including this ID in subsequent requests to the same endpoint will return the current status of the export job. When the job if finished the result will include the full document encoded in base64.
Export of encrypted documents
Lastly, we were previously unable to export encrypted documents since the server has no knowledge of the passphrase that is required to decrypt every block of the document.
To solve this we made it possible to send the passphrase as a parameter to the /documents/:id/export endpoint. This comes with a few risks, since it means that the passphrase is sent to the server, but required since we need to actually decrypt the document in order to build it.
To minimize the risk we have taken a few precautions:
- The passphrase is sent over HTTPS to protect it against a network based attacker.
- The passphrase is only kept in memory and never stored on disk. This includes masking it in any log files.
- The build files and decrypted RST-files are purged as soon as the build if finished and we have read the resulting file into our job cache (so that the client can retrieve it later).
- The job cache containing the exported document is cleared within one hour.