You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, cortex has no authentication for its workers. Any message that has a correct zmq envelope signed for service "X" will be accepted as a valid request/response for that service.
That is fine for the single-deployment situation we've had so far, but is unrealistic in practice. I would like to extend with:
An external developer uses the Cortex UI to register via an external account management service -- since I don't want to implement account management in cortex. (Decided on Google OAuth as the biggest / easiest to setup provider).
The cortex admin should have a minimal dashboard matrix where each GitHub-registered name has a checkbox against each corpus, and also a separate matrix for each service. The cortex admin can then grant corpus rights and service rights to individual accounts.
OAuth2-based workers
- a registered external developer uses the web UI to receive a secret, added to the configuration of the workers.
- The workers will then request session tokens based on the secret from the server, and pass them on in the zmq interchange, to prove their legitimacy to the dispatcher
- The dispatcher should be able to reject invalid requests/responses silently and instantly, to be robust against various (largely accidental) attacks, where the protocol gets flooded with noise.
Linux service that can auto-start the cortex frontend and dispatcher on system boot, or at least having a single command (currently dispatcher and frontend get started separately, but in most demo deployments they will be on the same machine and can have a simple unified bootup).
Preview captchas should be configurable on/off, since only arXiv requires this level of strictness. Also, the captcha guard needs to be configurable, as currently it is linked to my personal token.
Registration, extension, removal, of corpora needs to be possible through the web UI
Creation of services, as well as registering/removing them from specific corpora needs to be possible through the UI.
Clear documentation for first-time installation and configuration, with a minimal number of steps - at the very least the arXiv-to-HTML setup needs to be provided as an example set of steps from downloading cortex to finishing a full latexml run.
This about covers my expectations for a 1.0 release. Wanted to record so that there is a clear path forward - and if anyone is interested in using cortex for their own projects, feel welcome to comment and contribute!
The text was updated successfully, but these errors were encountered:
Currently, cortex has no authentication for its workers. Any message that has a correct zmq envelope signed for service "X" will be accepted as a valid request/response for that service.
That is fine for the single-deployment situation we've had so far, but is unrealistic in practice. I would like to extend with:
- a registered external developer uses the web UI to receive a
secret
, added to the configuration of the workers.- The workers will then request session tokens based on the secret from the server, and pass them on in the zmq interchange, to prove their legitimacy to the dispatcher
- The dispatcher should be able to reject invalid requests/responses silently and instantly, to be robust against various (largely accidental) attacks, where the protocol gets flooded with noise.
This about covers my expectations for a 1.0 release. Wanted to record so that there is a clear path forward - and if anyone is interested in using cortex for their own projects, feel welcome to comment and contribute!
The text was updated successfully, but these errors were encountered: