2016-10-19 03:11:36 +00:00
# Copyright (C) 2012-2016 Zammad Foundation, http://zammad-foundation.org/
2016-07-28 10:09:32 +00:00
class UserAccessTokenController < ApplicationController
2020-03-19 09:39:51 +00:00
prepend_before_action { authentication_check && authorize! }
2016-07-28 10:09:32 +00:00
2018-08-16 11:13:20 +00:00
= begin
Resource :
GET / api / v1 / user_access_token
Response :
{
" tokens " : [
{ " id " : 1 , " label " :" some user access token " , " preferences " : { " permission " : [ " cti.agent " , " ticket.agent " ] } , " last_used_at " :null , " expires_at " :null , " created_at " :" 2018-07-11T08:18:56.947Z " }
{ " id " : 2 , " label " :" some user access token 2 " , " preferences " : { " permission " : [ ticket . agent " ]}, " last_used_at " :null, " expires_at " :null, " created_at " : " 2018 - 07 - 11 T08 : 18 : 56 . 947 Z " }
] ,
" permissions " : [
{ id : 1 , name : " admin " , note : " Admin Interface " , preferences : { } , active : true , ... } ,
{ id : 2 , name : " admin.user " , note : " Manage Users " , preferences : { } , active : true , ... } ,
...
]
}
Test :
curl http : / / localhost / api / v1 / user_access_token - v - u #{login}:#{password}
= end
2016-07-28 10:09:32 +00:00
def index
Refactoring: Clarify complex Permission queries
This commit was prepared to facilitate a larger refactoring assignment
as part of the Pundit migration.
As a bonus, it includes some SQL query optimizations!
=== Why was this refactoring necessary?
It's not, strictly speaking.
But the Pundit migration involves taking complex querying logic
and moving it into Scope classes as appropriate,
and deciding where things belong is really difficult
when you can't see what they're doing.
=== So how does this refactoring fix the problem?
* It replaces raw SQL queries with Ruby-esque ActiveRecord queries.
* It replaces complex, procedural code
that's full of loops and obscure local variable assignment
with compact, cleanly-formatted code
that follows Ruby idioms and uses meaningful variable names.
In my opinion, it's much faster and easier
to understand what the code does this way.
=== What kinds of SQL query optimizations are included?
* n+1 query: user_access_token#index instantiated all active permissions
and then called current_user.permissions? on _every single one._
A fresh installation of Zammad contains 57 permissions,
so this was a lot of unnecessary queries.
The method has been rewritten to make only one query instead.
* User#permissions? used to query the DB once
for each argument it was given.
Now, it only queries the DB once, even when given many arguments.
* We had a couple SQL queries that used both #select and #pluck.
(When using #pluck, #select is redundant.)
Removing #select from these calls did not improve performance,
but it did clean up unnecessary code.
2020-07-07 11:14:58 +00:00
tokens = Token . select ( Token . column_names - %w[ persistent name ] )
. where ( action : 'api' , persistent : true , user_id : current_user . id )
. order ( updated_at : :desc , label : :asc )
base_query = Permission . order ( :name ) . where ( active : true )
permission_names = current_user . permissions . keys
ancestor_names = permission_names . flat_map { | name | Permission . with_parents ( name ) } . uniq -
permission_names
descendant_names = permission_names . map { | name | " #{ name } .% " }
permissions = base_query . where ( name : [ * ancestor_names , * permission_names ] )
descendant_names . each do | name |
permissions = permissions . or ( base_query . where ( 'permissions.name LIKE ?' , name ) )
2017-10-01 12:25:52 +00:00
end
2016-08-16 07:09:09 +00:00
Refactoring: Clarify complex Permission queries
This commit was prepared to facilitate a larger refactoring assignment
as part of the Pundit migration.
As a bonus, it includes some SQL query optimizations!
=== Why was this refactoring necessary?
It's not, strictly speaking.
But the Pundit migration involves taking complex querying logic
and moving it into Scope classes as appropriate,
and deciding where things belong is really difficult
when you can't see what they're doing.
=== So how does this refactoring fix the problem?
* It replaces raw SQL queries with Ruby-esque ActiveRecord queries.
* It replaces complex, procedural code
that's full of loops and obscure local variable assignment
with compact, cleanly-formatted code
that follows Ruby idioms and uses meaningful variable names.
In my opinion, it's much faster and easier
to understand what the code does this way.
=== What kinds of SQL query optimizations are included?
* n+1 query: user_access_token#index instantiated all active permissions
and then called current_user.permissions? on _every single one._
A fresh installation of Zammad contains 57 permissions,
so this was a lot of unnecessary queries.
The method has been rewritten to make only one query instead.
* User#permissions? used to query the DB once
for each argument it was given.
Now, it only queries the DB once, even when given many arguments.
* We had a couple SQL queries that used both #select and #pluck.
(When using #pluck, #select is redundant.)
Removing #select from these calls did not improve performance,
but it did clean up unnecessary code.
2020-07-07 11:14:58 +00:00
permissions . select { | permission | permission . name . in? ( ancestor_names ) }
. each { | permission | permission . preferences [ 'disabled' ] = true }
2016-08-16 07:09:09 +00:00
render json : {
Refactoring: Clarify complex Permission queries
This commit was prepared to facilitate a larger refactoring assignment
as part of the Pundit migration.
As a bonus, it includes some SQL query optimizations!
=== Why was this refactoring necessary?
It's not, strictly speaking.
But the Pundit migration involves taking complex querying logic
and moving it into Scope classes as appropriate,
and deciding where things belong is really difficult
when you can't see what they're doing.
=== So how does this refactoring fix the problem?
* It replaces raw SQL queries with Ruby-esque ActiveRecord queries.
* It replaces complex, procedural code
that's full of loops and obscure local variable assignment
with compact, cleanly-formatted code
that follows Ruby idioms and uses meaningful variable names.
In my opinion, it's much faster and easier
to understand what the code does this way.
=== What kinds of SQL query optimizations are included?
* n+1 query: user_access_token#index instantiated all active permissions
and then called current_user.permissions? on _every single one._
A fresh installation of Zammad contains 57 permissions,
so this was a lot of unnecessary queries.
The method has been rewritten to make only one query instead.
* User#permissions? used to query the DB once
for each argument it was given.
Now, it only queries the DB once, even when given many arguments.
* We had a couple SQL queries that used both #select and #pluck.
(When using #pluck, #select is redundant.)
Removing #select from these calls did not improve performance,
but it did clean up unnecessary code.
2020-07-07 11:14:58 +00:00
tokens : tokens . map ( & :attributes ) ,
permissions : permissions . map ( & :attributes ) ,
2016-08-16 07:09:09 +00:00
} , status : :ok
2016-07-28 10:09:32 +00:00
end
2018-08-16 11:13:20 +00:00
= begin
Resource :
POST / api / v1 / user_access_token
Payload :
{
" label " :" some test " ,
" permission " : [ " cti.agent " , " ticket.agent " ] ,
" expires_at " :null
}
Response :
{
" name " :" new_token_only_shown_once "
}
Test :
curl http : / / localhost / api / v1 / user_access_token - v - u #{login}:#{password} -H "Content-Type: application/json" -X PUT -d '{"label":"some test","permission":["cti.agent","ticket.agent"],"expires_at":null}'
= end
2016-07-28 10:09:32 +00:00
def create
if Setting . get ( 'api_token_access' ) == false
raise Exceptions :: UnprocessableEntity , 'API token access disabled!'
end
2017-11-21 14:25:04 +00:00
if params [ :label ] . blank?
2016-07-28 10:09:32 +00:00
raise Exceptions :: UnprocessableEntity , 'Need label!'
end
2018-10-09 06:17:41 +00:00
2017-11-21 14:25:04 +00:00
token = Token . create! (
2016-08-12 16:39:09 +00:00
action : 'api' ,
label : params [ :label ] ,
persistent : true ,
user_id : current_user . id ,
2016-08-30 14:26:27 +00:00
expires_at : params [ :expires_at ] ,
2016-08-12 16:39:09 +00:00
preferences : {
permission : params [ :permission ]
}
2016-07-28 10:09:32 +00:00
)
render json : {
name : token . name ,
} , status : :ok
end
2018-08-16 11:13:20 +00:00
= begin
Resource :
DELETE / api / v1 / user_access_token / { id }
Response :
{ }
Test :
curl http : / / localhost / api / v1 / user_access_token / { id } - v - u #{login}:#{password} -H "Content-Type: application/json" -X DELETE
= end
2016-07-28 10:09:32 +00:00
def destroy
token = Token . find_by ( action : 'api' , user_id : current_user . id , id : params [ :id ] )
raise Exceptions :: UnprocessableEntity , 'Unable to find api token!' if ! token
2018-10-09 06:17:41 +00:00
2017-11-21 14:25:04 +00:00
token . destroy!
2016-07-28 10:09:32 +00:00
render json : { } , status : :ok
end
end