how cookies generated?

  • Hi forum,
    Quick question, I've noticed that after user login to system, there are many cookies written to browser, one of them is token=token_string, which is the Redis token I assume? Can you please share me how the authentication is invoked, e.g. - is this POST request to some service with params users\pass, or it is something else? My goal is to generate token from 3rd party script, with credentials, and then extract this cookie.

    Thanks, L.

  • One more question, what about security? Redis can die with 'flush all' command, what if some1 will touch the internal layer? Can redis be replaced by other DB? Interesting

  • @julien-f can you answer that please?

  • Hey @ltex , not sure I understand the question but here's how it works:

    1. when the user access XO, the server (xo-server) checks whether the user has a valid token in its cookies
      • if yes, it will server the web application (xo-web)
      • otherwise it will present the user a sign in page and when the credentials are validated, it will create a authentication token (by using the XO API method token.create()) and store it in the user's cookies
    2. the web application (xo-web) is served and it will use the token to sign in in the XO API using the token (session.signIn({ token: '<value of the token>' }))

    Tokens have a validity of once month, and no, it's not possible to store them somewhere else than in Redis for now.

  • Thanks, the problem is that REDIS is quite 'unsecured' system, and 'flushall' can destroy all the user keys. REDIS is mean to be internal for only trusted usage.. And I feel a little confused that all the orchestration depends on such weak protection. E.g. person who gains access to CLI of the system (ubuntu or debian OS), can start redis-cli without any permission, reset passwords, and destroy all DC.

  • I don't see your point. If someone got root access on your system, your are owned, because in any case it can read your RAM or do whatever it likes (removing any file, or any database existing in the world). XOA is not meant to be accessed on a root shell.

    Redis DB is not accessible from outside, that's what matters. Or maybe I didn't understand your point?

  • you can run cli-redis without root privs.

  • XOA got only one user (root) so it doesn't matter: it's not meant to be run on a shared system. It's built as an appliance. But you can protect it with a password if you need.

  • If you want to I think you can add a password to Redis:

    It may works so I have never tested it.

Log in to reply