Projet

Général

Profil

Amélioration #4746

[UserToken] Non prise en compte du contexte

Ajouté par Charles Bonnissent il y a environ 5 ans. Mis à jour il y a plus de 2 ans.

Statut:
Intégré
Priorité:
Urgent
Assigné à:
Version cible:
Début:
25/04/2014
Echéance:
% réalisé:

100%

Version source:
Solution proposée:

Plusieurs moyens d'envisager le problème :

  • Préciser la notion de contexte dans le code en indiquant clairement l'usage qui va en être fait,
  • Utiliser le contexte dans le cadre du processus d'authent pour restreindre les conditions d'utilisation de l'action,

De toute façon, il faut préciser la documentation qui est pour l'instant trop succincte pour être utile.

Principaux fichiers impactés:
Wiki Détail:
Contrôle:
Jalons: 3.2 R17

Description

Lors de la déclaration d'un token d'authentification (https://docs.anakeen.com/dynacase/3.2/dynacase-doc-core-reference/website/book/core-ref:9edc8f2e-6929-11e2-8610-0021e9fffec1.html#core-ref:9edc8f2e-6929-11e2-8610-0021e9fffec1), il est demandé plusieurs paramètres :

  • Application => application à laquelle le token ouvre un accès,
  • Action => action à laquelle le token ouvre un accès,
  • Utilisateur => utilisateur au nom du quel l'action sera exécuté lorsque le token est utilisé,
  • Context => le contexte d'utilisation de l'action (paramètres passés à l'action)

Lors de l'utilisation du token, l'application, l'action et l'utilisateur sont bien pris en compte, le contexte n'est lui pas utilisé (Class.openAuthenticator.php), on peut passer le paramétrage que l'on veut à l'action il sera utilisé => la notion de contexte lors de la déclaration du token apporte donc un faux sentiment de sécurité.


Demandes liées

Lié à Core - Amélioration #4741: [Echec d'authentification/authtype=open] Lors d'un échec d'authent par token le code http renvoyé est 200 Résolu 24/04/2014
Lié à TEngine Client - Anomalie #6625: Test de configuration - accès par token échoue Intégré 13/10/2016
Lié à Core - Anomalie #6994: Corruption table `usertoken` par `CORE_premigr_3.2.23` et `API/updateclass` Intégré 01/06/2017

Historique

#1 Mis à jour par Marc Claverie il y a environ 5 ans

  • Version source changé de 3.1.16 à 3.1.15
  • Priorité changé de Normal à Urgent
  • Assigné à mis à Éric Brison
  • Statut changé de Nouveau à À analyser
  • Version cible mis à 3.1.16

#2 Mis à jour par Éric Brison il y a environ 5 ans

la vérification du contexte n'est pas réalisée par le provider mais par les préconditions d'exécution de l'action.

En effet, le provider n'a pas encore connaissance des caractéristiques de l'action.

Voir méthode : Action::execute().

#3 Mis à jour par Charles Bonnissent il y a environ 5 ans

  • Solution proposée mis à jour (diff)

#4 Mis à jour par Marc Claverie il y a environ 5 ans

  • Version cible changé de 3.1.16 à 3.3#Maintenance
  • Tracker changé de Anomalie à Amélioration

#5 Mis à jour par Éric Brison il y a plus de 2 ans

  • Version cible changé de 3.3#Maintenance à 3.2.23
  • Statut changé de À analyser à Assigné

#6 Mis à jour par Éric Brison il y a plus de 2 ans

  • Lié à Anomalie #6625: Test de configuration - accès par token échoue ajouté

#7 Mis à jour par Éric Brison il y a plus de 2 ans

  • % réalisé changé de 0 à 50

#8 Mis à jour par Éric Brison il y a plus de 2 ans

  • Statut changé de Assigné à Intégré
  • % réalisé changé de 50 à 100

Appliqué par commit internal-platfrom:commit:ca267ec893477eb6b9ab59f9b7d75d9855ba8b4c.

#11 Mis à jour par Jérôme Augé il y a presque 2 ans

  • Lié à Anomalie #6994: Corruption table `usertoken` par `CORE_premigr_3.2.23` et `API/updateclass` ajouté

Formats disponibles : Atom PDF