-
Notifications
You must be signed in to change notification settings - Fork 0
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
Api key implementation #466
base: master
Are you sure you want to change the base?
Conversation
Co-authored-by: DioFun <[email protected]> Co-authored-by: Nymous <[email protected]> Co-authored-by: AliasXoX <[email protected]> Co-authored-by: Molymawk <[email protected]>
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #466 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 26 31 +5
Lines 337 414 +77
Branches 35 44 +9
=========================================
+ Hits 337 414 +77 ☔ View full report in Codecov by Sentry. |
@@ -0,0 +1,21 @@ | |||
# API Authentication |
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.
For API authentication with API key, we usually do the authentication only with the Authorization header, and we would include it in all the requests. We don't have an authentication endpoint for APIs.
Why did you decide to use session? Maybe it was discussed somewhere else and I'm just not aware
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.
Sorry for the late reply, I came to this conclusion because I didn't really know how to make the difference between a request coming from a regular user and an API key bearer because they both eventually end up making a GET request to access the website. I'll think of another way to recognize an API call to make it more conventional.
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 should rework the way API is functionning. At first, there were a will of having the same link for API and normal pages. But, actually, it would be easier to have special path for api (/api/...).
def initialize(api_key) | ||
return if api_key.blank? | ||
|
||
can :read, :all |
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'll need in a near future to refine the permissions of each key, maybe by listing all the endpoints when creating one and let the user select which he wants the bearer to access (read, create, update, destroy), and change the permissions in the edit view.
|
||
def index | ||
@api_keys = ApiKey.accessible_by(current_ability) | ||
authorize! :index, @api_keys |
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.
note: differs from how we manage index in user_controller
|
||
private | ||
|
||
def still_authenticated? | ||
log_out if should_log_out? | ||
end | ||
|
||
def api_auth | ||
return unless request.path[0, 5] == '/api/' |
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.
Surely useless comment, but there is hard-coded text right here
def log_in_api(bearer) | ||
reset_session # For security reasons, we clear the session data before login | ||
session[:api_key_id] = bearer.id | ||
session[:expires_at] = Time.current |
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.
Can't understand why it's done this way
|
||
def current_ability | ||
@current_ability ||= if !session[:api_key_id].nil? | ||
|
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.
@@ -1,6 +1,7 @@ | |||
# frozen_string_literal: true | |||
|
|||
class SessionsController < ApplicationController | |||
include ApiKeyAuthenticatable |
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.
include ApiKeyAuthenticatable |
I'm not sure this is still useful
# Path to login via api key | ||
AUTH_API_PATH = '/auth/api' | ||
|
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.
# Path to login via api key | |
AUTH_API_PATH = '/auth/api' |
I think it's an artifact of the previous version that uses full connection and not Authorization header
resources :users, controller: :users, as: 'api_users' | ||
resources :api_keys, controller: :api_keys, as: 'api_api_keys' | ||
resources :machines, controller: :machines, as: 'api_machines' |
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.
Surely things to do about these endpoints but that's not the goal of this PR
@api_key = api_keys(:FakeRadius) | ||
@real_key = '5fcdb374f0a70e9ff0675a0ce4acbdf6d21225fe74483319c2766074732d6d80' | ||
|
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.
Is this necessary ?
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.
Maybe test if a wrong api key is provided ?
This pull request implements a new authentication method for lea5 using API Keys.
The authentication procedure using an API key has been documented.
Here's an overview of the changes coming with this pull request :
https://keygen.sh/blog/how-to-implement-api-key-authentication-in-rails-without-devise/
)