Adds OneTimeTokenSettings

[R4N]

Provided to OneTimeTokenService constructors to customize expire time when generating OneTimeToken

We've started implementing OneTimeTokenLogin after it's recent inclusion in Spring Security and appreciate this great feature addition.

During testing, the default expiration time (5 minutes) seems to be sufficient. As we move towards production usage we've started considering more scenarios which we think may warrant increasing it: delayed mail delivery, user doesn't check the email right away, etc. Because of this, we're planning on increasing the expiration time slightly (to 10 or 15 minutes).

We've switched over to using JdbcOneTimeTokenService for production, but when looking for a spot to modify the expiration time, we saw that there wasn't an option present to do so.

After consulting the documentation, there is mention of modifying the one-time token expire time by creating a Custom OneTimeTokenService.

A full custom implementation to only override the expire time is potentially risky as it requires implementing/duplicating the majority of the logic (in JdbcOneTimeTokenService) which doesn't need to change in order to fulfill this type of behavior.

This PR includes:

• A new class: OneTimeTokenSettings which has a property for the OneTimeToken timeToLive Duration
• Overloaded Constructors for InMemoryOneTimeTokenService and JdbcOneTimeTokenService which take OneTimeTokenSettings as a parameter to set as a private field. If OneTimeTokenSettings isn't provided to the constructors, the default one is used (5 minutes timeToLive)
• Both classes' generate implementations now use the OneTimeTokenSettings timeToLive Duration value when establishing the expire time
• Tests in InMemoryOneTimeTokenServiceTests + JdbcOneTimeTokenServiecTests using oneTimeTokenServices with non-default OneTimeTokenSettings to confirm generation, consumption, expiration of OneTimeTokens with custom expirations based on OneTimeTokenSettings

Submitted on behalf of Zetetic, LLC

[franticticktick]

@R4N thanks for suggestion. This is probably not something we would like to add to the framework now. At the same time, we need to think about more flexible possibilities for customizing the API of the oneTimeTokenLogin components. Could you close this PR and open a separate ticket? We will be able to discuss this task with community members and maintainers.

[R4N]

Will do, closed favor of this ticket with a few different implementation ideas for discussion: #16291