Enhancements to Studio authentication

[vic0824]

I have a couple of related ideas for enhancing the Studio authentication:

1. currently the authentication status (i.e. whether a user is authenticated in Studio) is lost after a page reload; this might be intentional or it might be simply a side-effect of the design choice of using the globalCredentials global JavaScript variable; storing the information in the session storage is a possible enhancement that would eliminate the need to repeat the login after a page reload and it would open up interesting possibilities (see bullet 2 below)
2. I think it would be useful to allow the front-end of a custom http plugin to share the authentication with Studio, i.e. if the user has logged in to Studio, he is considered also logged in the custom plugin, and vice versa if the user has logged in to the custom plugin, he is considered logged in also in Studio

I think feature 2 could be implemented rather easily if feature 1 is implemented, but there could be other ways of doing it that are better from a different point of view.
Comments and suggestions are welcome.

[lvca]

I like this proposal, but being not a security expert, is the browser's local storage a safe place to store a password?

[vic0824]

I'm not a security expert either, but I know that storing the password in the localStorage is bad a idea, because it can be accessed by other web pages. I'm suggesting to store it in the sessionStorage, which is only accessible by the page in which the web app runs, and it is automatically cleared when the current page is closed.
Using basic authentication with plain http is inherently insecure, it should only be used with https, so all other security considerations are pretty much irrelevant.
Storing the password in the session storage is not 100% secure, but it is not more insecure than the current design, because anybody can open the developer tools in the browser, open the console, and type console.log(globalCredentials) to obtain the value of the password stored in the globalCredentials variable.
I have read an interesting article on the various options for persisting sensitive data in the browser (it is about storing auth tokens, but I believe the principles apply also to passwords): https://blog.ropnop.com/storing-tokens-in-browser/
We should also bear in mind that it is possible to access any ArcadeDB database through the console (connecting to a local db file), by-passing the server security altogether, so in the end the design should be the result of a risk assessment of the various use cases, rather than aiming at maximum security.
Is the ArcadeDB server supposed to be installed on a DMZ? If it is only supposed to be installed on a private LAN, not accessible from the Internet, the security risks are much lower and there is no need to get paranoid about security.
Having said that, it is probably better to get the opinion of a web security expert.
The security team at the office freaks out if https is not used, but for everything else (authentication method, where are password stored), they don't ask many questions.

[lvca]

I didn't realize we keep the credentials in a js variable, so storing in the sessionStorage sounds not a downgrade to me.

ArcadeDB should be installed where it's not exposed to a public network, and I believe this is a recommendation valid for any DBMS out there.

[lvca]

Just created an issue from this discussion: #904

[lvca]

Now that #1691 is done, we could actually login and logout from Studio. The session will live up to 30m (configurable) after the last operation. Does this solves the issue?

[lvca]

Implemented in #904!