Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allow passing a $secretSize when generating a secret #204

Open
wants to merge 1 commit into
base: 11.3.x
Choose a base branch
from

Conversation

browner12
Copy link

Target branch: 11.3.x
Resolves issue: none

  • It is a Bug fix
  • It is a New feature
  • Breaks BC
  • Includes Deprecations

this will allow the user to set their own secret length, but allow the package to still handle the creation of the string. I think this is a better interface for the user, as this is most likely a large chunk of the reasons someone would want to have a custom secret over the default.

It also helps avoid a (likely) implicit dependency in user code. We are currently using TOTP::createFromSecret(Base32::encode(Str::random(16)))->getSecret() to generate a shorter random secret than the default. Here we are using the Base32 class from ParagonIE, even though it is not an explicit dependency in our code. We probably should be, rather than implicitly depend on it. I'm guessing other people may make this mistake as well.

If there's a better architecture way to handle this, open to suggestions.

this will allow the user to set their own secret length, but allow the package to still handle the creation of the string.  I think this is a better interface for the user, as this is most likely a large chunk of the reasons someone would want to have a custom secret over the default.

It also helps avoid a (likely) implicit dependency in user code. We are currently using `TOTP::createFromSecret(Base32::encode(Str::random(16)))->getSecret()` to generate a shorter random secret than the default. Here we are using the `Base32` class from `ParagonIE`, even though it is not an explicit dependency in our code. We probably should be, rather than implicitly depend on it. I'm guessing other people may make this mistake as well.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant