UI needs to support auth tokens

[jessesuen]

Taking the liberty of filling this in. We have a few options:

1. Set and parse cookies server-side. These cookies could contain the JWT required by Argo CD. This has the advantage of being secure and we can set the HttpOnly flag on them since the client-side JavaScript won't need to (and, indeed, cannot) interact with them. A tradeoff is that logout require server-side action to delete the cookie.

2. Generate tokens server-side (as above), but send them to the client. This is the current implementation for token generation. The client can use JavaScript to create a cookie from the token, then look that cookie up before sending the token to the server. This is less secure since JavaScript can access the cookie (i.e., no HttpOnly flag), but JavaScript can be used for the logout process. To ensure safe access and encryption, probably best to use a secure cookie and avoid HTML5 local storage.

As a side note, a best practice is for all cookies to be secure cookies, at least in production.

For the first option, the frontend integrates by having an API endpoint for login (already done!) that needs to set a cookie in the response (not yet done), rather than returning the token. Logout requires a second endpoint to delete the cookie.

For the second option, I believe that everything is in place for implementation right now.

@alexmt, interested in your thoughts.

[jessesuen]

I am in favor of setting cookies from the server, but this is just what I am used to. I think relying on client-side logic makes it inflexible for other types of HTTP clients/tooling such as Postman.

[merenbach]

Server-side cookie support will be added with #96.

[merenbach]

Server-side cookie support is now present. @alexmt to support client-side:

Login

Issue an HTTP POST to /api/v1/session with a JSON payload as follows:

{
    "username": "USERNAME_GOES_HERE",
    "password": "PASSWORD_GOES_HERE"
}

The JSON response will look like:

{"token": "TOKEN_GOES_HERE"}

Please feel free to ignore this response entirely, as the HTTP response also sets a cookie, which should automatically grant access. It is possible that this cookie will "just work" for future requests (suggest trying that way first unless you know otherwise). It may also be that your XHR/AJAX framework may need to maintain (and pass for future requests) a shared cookie context.

Logout

Issue an HTTP DELETE request to /api/v1/session with no JSON payload. The response will be an empty JSON object ({}), which can be completely ignored.

[alexmt]

Thank you @merenbach ! UI changes had been implemented.