Same holds true for cache files, so there should be no problem anymore with installs where the static folder is not writable.
Also introduced two new devel config vars to disable merging and minifying of the assets, solved the empty-less-bundle problem and made sure babel knows about the jinja extension.
Actual test whether key is provided or not happens in before_request handler of flask app, hence the more granular processing in the decorator was unecessary since around november '14. Adjusted to only do the actual processing necessary to replicate login_required behaviour/login users if necessary.
Closes#516 (actually, that was solved since introduction of the before_request handler which took that work off the hands of the decorator, but now it's properly documented too)
That is the first step towards downloadable (and separately managed) translation packages, decoupled from the software's release cycle and source control. Since it will be impossible to properly maintain all languages concurrently with OctoPrint's releases, decoupling that will hopefully increase the user experience through preventing broken translations (or stalling releases due to having to wait for the translations to be updated).
f98ebaaf moved the passive_logon code to a new function from
api/__init__.py to util/flask.py. Before that move any fallthrough
would hit return NO_CONTENT, but now it returns nothing which makes
flask complain.
Index page will now be cached for up to five minutes, unless the
request contains "_refresh" in the query or the Cache-Control header
contains no-cache
In order to solve the initial handshake problem with apps, OctoPrint now supports so called app session keys which are basically API keys with a limited validity. Obtaining those keys is based on a handshake procedure backed by RSA signatures. OctoPrint needs to be aware of apps and their associated public keys (with the AppPlugin there exists a mechanism to add additional recognized apps by installing a plugin). Apps perform the handshake by first requesting a temporary key with very limited validity, then sending a message back to OctoPrint containing their id, version, the temporary key and a signature created with their private key over these three pieces of data. OctoPrint then tries to verify the signature and if successful unlocks the key to be used as a fully recognized API key.
Major refactoring of octoprint.server.util (divided into smaller submodules), extended Tornado to allow for request-specific max content lengths, introduced settings parameters to configure maximum upload size, maximum request body size and file suffixes
See #455
