developer.jelix.org is not used any more and exists only for history. Post new tickets on the Github account.
developer.jelix.org n'est plus utilisée, et existe uniquement pour son historique. Postez les nouveaux tickets sur le compte github.

Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#1051 closed new feature (fixed)

JAuth : Ajout de 2 évènements AuthErrorLogin et AuthBeforeLogin

Reported by: sylvain261 Owned by: sylvain261
Priority: normal Milestone: Jelix 1.2 beta
Component: jelix:auth Version: trunk
Severity: normal Keywords: jauth events
Cc: Blocked By:
Blocking: Documentation needed: no
Hosting Provider: Php version:

Description

Afin de permettre d'étendre plus facilement jAuth, l'idée et de créer 2 nouveaux évènements dans jAuth :

Levé en cas d'erreur de login / mot de passe. Typiquement une application se servira de cet évènement pour historiser en base ou ailleurs les erreurs de connexions. jAuth n'attend aucune valeur de retour de la part des listener.

Levé avant même de vérifier le login/mot de passe. Typiquement une application se servira de cet évènement pour s'assurer que l'IP utilisée n'est pas blacklistée ou autre.. JAuth attend en retour de la part des listener un paramètre processlogin passé à true. Si ce n'est pas le cas, jAuth ne vérifiera pas le login/mot de passe et ne connectera pas l'utilisateur (tout comme si le login / mot de passe était erroné).

Sauf commentaire particulier, le patch arrive d'ici peu.

Attachments (3)

lib.diff (2.8 KB) - added by sylvain261 10 years ago.
new Events for jauth
lib.2.diff (3.2 KB) - added by sylvain261 10 years ago.
Oubli du fichier jauth/events.xml.
lib.3.diff (2.4 KB) - added by sylvain261 10 years ago.

Download all attachments as: .zip

Change History (13)

Changed 10 years ago by sylvain261

new Events for jauth

Changed 10 years ago by sylvain261

Oubli du fichier jauth/events.xml.

comment:1 Changed 10 years ago by sylvain261

  • review set to review?

comment:2 Changed 10 years ago by laurentj

Pour l'évenement AuhtErrorLogin?, je suis ok. Pour l'autre, je suis plus sceptique. Cela ne risque-t-il pas de préter à confusion avec AuthCanLogin? ?

De plus, je ne suis pas partisan de passer le mot de passe à ces deux évènements, d'une part parce que je n'en vois pas l'utilité (ton listener dans le module jauth ne sert à rien à mon avis), et d'autre part, vu que n'importe quel module peut écouter, j'ai peur que cela ouvre une possibilité à des trous de sécurité. Aurais-tu des exemples concrets d'utilité de ce mot de passe ?

à la limite, pour AuthErrorLogin?, cela pourrait permettre de logger et de voir quel type d'attaque (si il y a attaque). Mais pour AuthBeforeLogin?...

comment:3 Changed 10 years ago by sylvain261

Je comprend tes arguments concernant le mot de passe à ne pas passer aux évènements, je n'avais pas pensé à cela. OK pour moi. Par contre ca me parait important de passer le login afin par exemple de de pouvoir logger les choses.

Concernant l'utilité de AuthBeforeLogin? :
AuthBeforeLogin? me parait indispensable. En effet, pour ceux qui implémenteront via AuthErrorLogin? un système de blacklistage en cas d'erreur de login répété (c'est mon cas), AuthBeforeLogin? va permettre de voir si justement l'IP et/ou le compte est blacklistée. Si c'est blacklisté on ne rentre même pas dans le processus de login. C'est vrai que ca peut porter à confusion avec AuthCanLogin?. Je n'ai néanmoins pas trouvé de nom qui serait plus approprié.
Tu me répondras probablement que cette vérification pourrait être effectuée dans AuthCanLogin?. Effectivement elle pourrait l'être, mais il ne me parait pas opportun d'aller faire une vérification de login/pwd à chaque tentative de login si en fait on est dans un cas ou l'utilisateur est blacklisté :

  • pour des raisons de charge serveur (évite des traitements inutiles, évite de laisser la porte ouverte à des attaques de type de Deny Of Service)
  • pour des raisons de sécurité: Dans le cas où l'utilisateur est blackisté, il ne faut lui laisser aucune chance de savoir si le mot de passe saisi est bon ou pas. Le plus sûr pour cela et de ne pas vérifier le login/mot de passe plutôt que de dépendre de l'implémentation du listener authCanLogin (qui potentialisent, d'une manière ou d'une autre peut donner des indications à l'utilisateur).

comment:4 Changed 10 years ago by laurentj

  • Resolution set to fixed
  • review changed from review? to review-
  • Status changed from new to closed

Par contre ca me parait important de passer le login afin par exemple de de pouvoir logger les choses.

bien entendu :-)

Pour le reste ok.

Donc en recapitulant : le patch corrigé enlevera l'envoi du password pour les deux évènements, et le listener dans le module jauth.

comment:5 Changed 10 years ago by laurentj

  • Resolution fixed deleted
  • Status changed from closed to reopened

Changed 10 years ago by sylvain261

comment:6 Changed 10 years ago by sylvain261

  • review changed from review- to review?

comment:7 Changed 10 years ago by laurentj

  • review changed from review? to review+

comment:8 Changed 10 years ago by laurentj

  • Resolution set to fixed
  • Status changed from reopened to closed

comment:9 Changed 10 years ago by laurentj

  • Documentation needed set
Note: See TracTickets for help on using tickets.