-
Notifications
You must be signed in to change notification settings - Fork 108
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
Initial implementation of Pbench user model and associated APIs in server #1937
Initial implementation of Pbench user model and associated APIs in server #1937
Conversation
This pull request introduces 1 alert when merging bfeccfd into 82c193a - view on LGTM.com new alerts:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A comment left over from the other day that I forgot to actually submit...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a little curious why you haven't hooked up the endpoint to your new class yet, but I'm not objecting to "slow and steady" either.
This pull request introduces 1 alert when merging a9be97c into a86cbb6 - view on LGTM.com new alerts:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great progress, Nikhil!
A bunch of architecture/structure comments, most of which shouldn't radically change what you have.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First pass set of review comments ...
This pull request introduces 1 alert when merging db53a4a into 659d90d - view on LGTM.com new alerts:
|
This pull request introduces 1 alert when merging 4fabf2c into 659d90d - view on LGTM.com new alerts:
|
This pull request introduces 1 alert when merging dbdd077 into ad3e4d3 - view on LGTM.com new alerts:
|
This pull request introduces 2 alerts when merging 3b2fd36 into ad3e4d3 - view on LGTM.com new alerts:
|
This pull request introduces 2 alerts when merging cd922c3 into ad3e4d3 - view on LGTM.com new alerts:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's put this one in the can; we've got important things to put on top of it. There are a few of the issues brought up during discussions that deserve consideration in a follow-up.
# check if the user is already logged in, in case the request has a an authorization header included | ||
# We would still proceed to login and return a new auth token to the user | ||
if user == self.auth.token_auth.current_user(): | ||
self.logger.warning("User already logged in and trying to re-login") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We've had some discussions about how to handle this, and I think some changes are warranted but not in this PR ... when you do that, if this comment survives, I just spotted a typo: "has a an authorization header". ;-)
# Make sure all the models are imported before this function gets called | ||
# so that they will be registered properly on the metadata. Otherwise | ||
# metadata will not have any tables and create_all functionality will do nothing | ||
|
||
Database.Base.query = Database.db_session.query_property() | ||
|
||
engine = create_engine(Database.get_engine_uri(server_config, logger)) | ||
Database.Base.metadata.create_all(bind=engine) | ||
Database.db_session.configure(bind=engine) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another area that could use some cleanup in a follow-on PR. (I assume that you'll move on to finish your metadata PR #2049, so that's a possibility if not handled separately.)
Operationally; if we can do anything here to ensure/detect that everything's good, that would be excellent. If not, let's at least clean up the comment to describe the assumptions and current implementation, providing a simple and actionable warning about the impact of changes on those assumptions ... rather than a vague and disturbing warning with no actionable mitigation.
Oh; and (sigh) you now need a rebase before we can merge. |
This implements 5 basic user APIs 1. Register User Handles Pbench User registration via JSON request POST /v1/register 2. Login User: POST /v1/login Returns a valid pbench auth token User is allowed to issue multiple login requests and thus generating multiple auth tokens, Each token is stored in a active_tokens table and has its own expiry User is authenticated for subsequest API calls if token not expired and present in the active_tokens table 3. Logout user: POST /v1/logout Deletes the auth_token from the active_tokens table. Once logged out user can not use the same auth token for other API access. 4. Get User: GET /v1/user/<string:username> Returns the user's self information that was registered, the username must be provided in the url If the Auth header does not belong to the username, reject the request unless auth token belongs to the admin 5. Delete User: DELETE /v1/user/<string:username>" An API for a user to delete himself from the pbench database. A user can only perform delete action on himself unless the auth token belongs to the admin user. 6. Updare User: PUT /v1/user/<string:username> An API for updating the User registration fields, the username must be provided in the url Update is not allowed on registerd_on field
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know how to figure out what has changed in the last three hours, and I don't have it in me to review this whole thing from scratch, so I'm going to just assume that, at this point, it's all good....
Nothing changed in last 3 hours, it just got rebase :) |
Then I'm sure that it's all good. ;-) |
Yeah, we really need to consider doing merge commits in the future. Or just rely on GitHub to automatically squash and merge so at least we can see the real changes up to the last moment. |
Having the review feedback incorporated as separate commits which then get squashed (somehow) would be a huge step forward (at least as long as we continue to rely on GitHub for doing reviews). Having GitHub do the squash as part of the merge is perfectly acceptable in many, many cases. Having it do a rebase as part of the merge is fine, too, so long as we want to retain the individual the commits in the PR, but we probably won't in most cases. (Sadly, there is no "rebase AND squash" option.) And, having it create merge commits is a very good idea, but only in a fairly small set of cases, so I'd rather focus on easing review and then squashing. |
This includes more change than it should, because I'd originally segregated the database files into a `db` directory while Nikhil went with `database`.
This includes more change than it should, because I'd originally segregated the database files into a `db` directory while Nikhil went with `database`.
This includes more change than it should, because I'd originally segregated the database files into a `db` directory while Nikhil went with `database`.
This includes more change than it should, because I'd originally segregated the database files into a `db` directory while Nikhil went with `database`.
…system-analysis#1937) This implements 5 basic user APIs 1. Register User Handles Pbench User registration via JSON request POST /v1/register 2. Login User: POST /v1/login Returns a valid pbench auth token User is allowed to issue multiple login requests and thus generating multiple auth tokens, Each token is stored in a active_tokens table and has its own expiry User is authenticated for subsequest API calls if token not expired and present in the active_tokens table 3. Logout user: POST /v1/logout Deletes the auth_token from the active_tokens table. Once logged out user can not use the same auth token for other API access. 4. Get User: GET /v1/user/<string:username> Returns the user's self information that was registered, the username must be provided in the url If the Auth header does not belong to the username, reject the request unless auth token belongs to the admin 5. Delete User: DELETE /v1/user/<string:username>" An API for a user to delete himself from the pbench database. A user can only perform delete action on himself unless the auth token belongs to the admin user. 6. Updare User: PUT /v1/user/<string:username> An API for updating the User registration fields, the username must be provided in the url Update is not allowed on registerd_on field
Initial framework to build Pbench user authentication:
This implements 6 basic user APIs
Register User:
POST
/v1/register
Login User
POST
/v1/login
however, in the future there will be limit on the number of auth token a user can generate.
active_tokens
table in our db.active_tokens
table.Logout User
POST
/v1/logout
active_tokens
table.Get User
GET
/v1/user/<string:username>
Authorization
header does not belong to the username provided in the url, we reject the request unless theAuthorization
token belongs to the admin user.Delete User
DELETE
/v1/user/<string:username>"
headers={Authorization: Bearer <Pbench authentication token (user received upon login)>
}
DELETE
action on another account if the presented auth token belongs to an admin user.Authorization
header does not belong to the username provided in the url, we reject the request unless theAuthorization
token belongs to the admin user.Update User
PUT
/v1/user/<string:username>
Authorization
header does not belong to the username provided in the url, we reject the request unless theAuthorization
token belongs to the admin user.registered_on