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

Get a authentification token instead of allowing only the login/password for queries #1691

Open
ExtReMLapin opened this issue Aug 16, 2024 · 6 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@ExtReMLapin
Copy link
Contributor

Hello,

At the office, we're working on an application and ArcadeDB is the only database we want to rely on.

As we need a JWT token, we decided to use the ArcadeDB user system instead of using LDAP or ActiveDirectory.

Login and registration endpoints works correctly as it execute user registration using root account and login using user provided creditentials.

Issue is that, after being connected, the client will execute a query on endpoint /do_something JWT token will report user as being user "Ben" but as it need to executes queries in it's name (Because if the database visibility/rights system is in place in arcadeDB, no need to re-code it on our side) we need to send a query using the user password.

And this is where we're stuck, we CANNOT (should not, actually) store the user password in the JWT temporary database.

However, if ArcadeDB was returning a token for authentification, we could with no much worry store this temporary token in the JWT database and the user password would be safe.

TL;DR :

In our application user system is literally using ArcadeDB user's accounts system, which means that for each action on the database that is executed by the application need to be done in the user's name, which requires the username/password to be saved after login, during the whole token time of life.

Adding a token system for authentification would help a lot.

We only use the HTTP/REST API.

Thanks.

@ExtReMLapin
Copy link
Contributor Author

As a clarification, we could do all actions using "root" account, but we would need to implement in a quite few places "Btw does [cur user] has access to this database ?" check.

@lvca
Copy link
Contributor

lvca commented Aug 18, 2024

You could execute a command with theuser/password (like a select 1), save the session token in the response header as arcadedb-session-id, and send back to further requests.

If the token is present and the session is still valid, the user and password are not needed.

@lvca lvca self-assigned this Aug 18, 2024
@lvca lvca added the question Further information is requested label Aug 18, 2024
@lvca lvca added this to the 24.8.1 milestone Aug 18, 2024
@ExtReMLapin
Copy link
Contributor Author

Thaks for the answer, looks like i should have ctrl-f’ed « session » and not « token ».

will implement today and get back here with my solution

@ExtReMLapin
Copy link
Contributor Author

So I have a try with POSTMAN, and

  1. When executing a simple query (for example SELECT 1) it doesn't return me a transaction/session id, the only way to get a transaction ID is to use the /begin endpoint.
  2. So I decided to give a try with the /begin endpoint but it still waits for a login:password.

I have a set of unit tests in python for arcadedb, including transactions (begin, commit, rollback, etc).

Since then, we always sent the root:password in our arcadedb requests, in the code that sends extra headers, we always sent the root:password,

After your message, I added a check to omit the login:password if the header arcadedb-session-id was there and it ALWAYS return a code 401.

Also in the documentation example even with the transaction id, login:password is sent.

curl -I -X POST http://localhost:2480/api/v1/commit/school \
       -H "arcadedb-session-id: AS-ee056170-dc9b-4956-8d71-d7cfa01900d4" \
       --user root:arcadedb-password

@lvca
Copy link
Contributor

lvca commented Aug 19, 2024

I guess we inherit the "session" name from OrientDB, but it's more a transaction id than a session id. ArcadeDB is basically stateless until you begin a transaction.

Ok, I see we'd need a /login endpoint that gets the credentials and returns a session token that can be used by all the commands to bypass authentication.

This could also speed up commands in general because the credentials don't need to be checked every time.

@lvca lvca added enhancement New feature or request and removed question Further information is requested labels Aug 19, 2024
@ExtReMLapin
Copy link
Contributor Author

Thanks for the quick update.

Right now we opted for a full "root" interractions policy, but i'll be happy to move to a safer arcade-token as soon as it's ready.

@lvca lvca modified the milestones: 24.10.1, 24.11.1 Oct 12, 2024
@lvca lvca modified the milestones: 24.11.1, 24.11.2 Nov 5, 2024
@lvca lvca modified the milestones: 24.11.2, 24.12.1 Dec 9, 2024
@lvca lvca modified the milestones: 24.12.1, 25.1.1 Dec 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants