Is your feature request related to a problem? Please describe.
No issue, just an observation. Configured with commit 8 years ago, which I am guessing was so access tokens could be used like "personal access tokens" with backed applications/scripts, which do not have a user auth flow.
So just wanted to make a note and ask the question, keeping in mind when most apps/tokens are used only for authentication (to then receive the user's info).
Alternative solutions would need to be thought up so that scenarios where scripts/servers need can continue to work with the API to (ie. create users for Fab Academy, make reports on labs, etc).
Have a custom button on the OAuth application page
that just manually, creates an access token with no expiry date
(inc. tmp show token once, table list existing, revoke token, etc)
Probably the easiest (more or less one line to create a token in doorkeeper controller)
Enable Doorkeepers' "refresh access token" mode
then scripts need/can be updated to use that token to fetch a new access_token every time one needs to work with API. (part of OAuth spec).
Not sure on side effects vs no expiry date. More work for the 3rd-party scripts
Create a new personal access token setup
simple model/table,
adding an auth check method to the API controller (on top of doorkeeper).
Maybe Rails has a default setup (or gem) backed-in to do this.
Additional context
Need to process and report on the current NGINX logs of the API/APP to see if any existing API calls are relaying on this setting (outside Fab Academy). For example, I quickly noticed, that there were calls to the /api/2/labs endpoint by a client. So, we can look into the impact.
Only security related issue I currently see is if access tokens would leak/stolen (from 3rd parties). Though tokens are assigned to a user, if an admin token would leak. The API access is depended on the token's users' existing access rights.
Is your feature request related to a problem? Please describe.
No issue, just an observation. Configured with commit 8 years ago, which I am guessing was so access tokens could be used like "personal access tokens" with backed applications/scripts, which do not have a user auth flow.
So just wanted to make a note and ask the question, keeping in mind when most apps/tokens are used only for authentication (to then receive the user's info).
Related Doorkeeper gem config: https://github.com/fablabbcn/fablabs.io/blob/752b938a27ad5b6ab5f71ec2b44cd135532fc6b0/config/initializers/doorkeeper.rb#L31-L33
Doorkeeper docs: https://github.com/doorkeeper-gem/doorkeeper/wiki/Customizing-Token-Expiration#access-token
Describe alternatives you've considered
Alternative solutions would need to be thought up so that scenarios where scripts/servers need can continue to work with the API to (ie. create users for Fab Academy, make reports on labs, etc).
Additional context Need to process and report on the current NGINX logs of the API/APP to see if any existing API calls are relaying on this setting (outside Fab Academy). For example, I quickly noticed, that there were calls to the
/api/2/labsendpoint by a client. So, we can look into the impact.Only security related issue I currently see is if access tokens would leak/stolen (from 3rd parties). Though tokens are assigned to a user, if an admin token would leak. The API access is depended on the token's users' existing access rights.