Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CorTeX 1.0 #43

Open
2 of 8 tasks
dginev opened this issue Apr 4, 2019 · 0 comments
Open
2 of 8 tasks

CorTeX 1.0 #43

dginev opened this issue Apr 4, 2019 · 0 comments

Comments

@dginev
Copy link
Owner

dginev commented Apr 4, 2019

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant