Session Authenticator and the checkAction method #1182
-
I've been reworking the code in my project grimpirate/halberd which is an authentication action for shield that allows two-factor authentication using TOTP. I've made a series of changes that I'm unsure as to whether or not they constitute a "best practice" approach. The system works, but there is one part of it that I'm having a real hard time digesting as reasonable. In the verify method of the Halberd action, in order to validate the TOTP, I pass an copy of the user's identity with the ->secret set to whatever the TOTP should be along with the postedToken to the identity model's checkAction method. Use of this method seems unavoidable to ensure proper session cleanup/initialization (based on my understanding of the source of the method). Overwriting the secret to perform this check is a hack and gives me pause. Secondly, the checkAction method itself deletes the identity on success, so I have to create a new identity with the true secret after successful verification for subsequent logins. This is obviously dangerous. A failed database update could mean the secret is lost forever. There are workarounds for this sure... but that just seems like more hacks. I want the google_2fa identity type that I created to exhibit persistent behavior like the email_password identity, wherein the values are overwritten rather than deleted/created. Prior, I would create three identities: google_2fa (permanent), halberd_register (temporary) and halberd_login (temporary). That seemed unnecessarily complicated when I could control the login/register states by utilizing the ->extra field of the identity for each situation, respectively. To sum it all up, what is the approach for a persistent identity like email_password, when implementing the ActionInterface, that doesn't result in deletion of the identity when verifying the token? Is this even possible or should I instead be trying to extend an ActionController? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Nvm, I now provide a custom TOTP Authenticator which overwrites the checkAction method with custom logic. Furthemore, instead of using the extra field I've changed the Authentication Action to an Activator to distinguish between the register/login states and display the respective view. |
Beta Was this translation helpful? Give feedback.
Nvm, I now provide a custom TOTP Authenticator which overwrites the checkAction method with custom logic. Furthemore, instead of using the extra field I've changed the Authentication Action to an Activator to distinguish between the register/login states and display the respective view.