Segnalazione #863
Aggiungere permission checking a operation e API
0%
Related issues
Associated revisions
Start checking permissions for operations. refs: #863
Fix some tests and code errors. refs: #863
Start testing permissions. refs: #863
Further permission tests. refs: #863
Permissions on remaining ops. refs: #863
Permission checking on sync and async methods. refs: #863
Further webapi permissions. refs: #863
Override the user if passed by js in decoded. refs: #863
Use @wraps on decorators. refs: #863
Move checking for permissions to a common place. refs: #863
Merging t863 into master. Refs: #863
History
Updated by Elena Grandi over 5 years ago
- Blocked by Segnalazione #856: interfaccia con LDAP asincrona per tornado added
Updated by Elena Grandi about 5 years ago
- Blocked by deleted (Segnalazione #862: form/view di login)
Updated by Elena Grandi about 5 years ago
- Status changed from Nuovo to Commenti
- Assignee changed from Elena Grandi to Enrico Zini
Ripasso il ticket per review e merge.
Mi pare ci sia quasi tutto, solo non sono sicura se aggiungere in tests/test_webserver.py
un test in più per le operations che testi un'operation che richieda permessi, perché non son sicura che funzioni correttamente (sospetto che al momento non dia un forbidden, ma un 500 o simili).
Updated by Enrico Zini about 5 years ago
- Assignee changed from Enrico Zini to Elena Grandi
Bel branch, mi piace molto!
Alcuni commenti piú o meno estetici.
In manager/ops.py:58
, suggerisco un decoded.pop("user", None)
per buttar via 'user' se viene passato per sbaglio da javascipt, altrimenti il costruttore di Op
lanca un'eccezione per un parametro passato due volte.
In alternativa, forse meglio, un override pari pari: decoded["user"] = user
.
Nel decoratore permission_required
, in caso user sia None
, possiamo dare per scontato che il permesso non ci sia, e quindi semplificare i vari getattr
successivi, o c'è la possibilità che vengano assegnati permessi all'utente None
?
Nei decoratori, aggiungi un functools.wraps
, cosí vengono preservati gli attributi della funzione originale nella funzione wrappata: https://docs.python.org/3.5/library/functools.html#functools.wraps
Visto che il controllo dei permessi è replicato nei due decoratori di ops e di webapi, propongo di spostarlo in una funzione unica in perms.py
, cosí quella parte, abbastanza security sensitive, rimane in un posto solo per testarla, fare code review, e sistemare bug.
Updated by Elena Grandi about 5 years ago
Enrico Zini wrote:
In
manager/ops.py:58
, suggerisco undecoded.pop("user", None)
per buttar via 'user' se viene passato per sbaglio da javascipt, altrimenti il costruttore diOp
lanca un'eccezione per un parametro passato due volte.In alternativa, forse meglio, un override pari pari:
decoded["user"] = user
.
fatto con l'alternativa override
Nel decoratore
permission_required
, in caso user siaNone
, possiamo dare per scontato che il permesso non ci sia, e quindi semplificare i varigetattr
successivi, o c'è la possibilità che vengano assegnati permessi all'utenteNone
?
Mi pare realistico che l'utente None
possa avere ReadonlyBaseAccess.
Nei decoratori, aggiungi un
functools.wraps
, cosí vengono preservati gli attributi della funzione originale nella funzione wrappata: https://docs.python.org/3.5/library/functools.html#functools.wraps
fatto
Visto che il controllo dei permessi è replicato nei due decoratori di ops e di webapi, propongo di spostarlo in una funzione unica in
perms.py
, cosí quella parte, abbastanza security sensitive, rimane in un posto solo per testarla, fare code review, e sistemare bug.
fatto, anche questo.
Updated by Enrico Zini about 5 years ago
- Status changed from Commenti to Chiuso
- Resolution set to fixed
Perfetto, mergiato in master, chiudo.
Pass user informations to operations. refs: #863