passwordless.CreateMagicLinkByEmail doesn't pass along response.OK.CodeLifetime

[gwd]

When overriding a hook for sending an email as part of the auth workflow, not only the link but also the lifetime of the link is provided, allowing the email (or whatever presentation) to tell the user how long to expect the link to work.

However, when creating a link outside of the normal auth flow with CreateMagicLinkByEmail, the CodeLifetime is discarded, meaning it's impossible (without making assumptions) to tell the user how long the lifetime will last.

[rishabhpoddar]

That is true, however, the lifetime is statically defined in the core config anyway, so the golang code can use the same value (though yea, you would be repeating that value in two places, which is not ideal).

We can change this func to return the link and the lifetime, however, this will be a low priority task for us.

[gwd]

Low priority for sure. I wouldn't mind sending you a PR if I had an idea the approach you wanted to take -- whether to change the function signature of CreateMagicLinkByEmail (a breaking change -- technically OK in a pre-1.0 library, but still not something to do lightly), or introduce a new function with a new signature; and whether to just return more values, or to return a structure (which could then be extended if more things were added). That would be relatively low priority for me as well. 😄

In support of the motivation: You can't really "use the same value" in both places, as it's not necessarily available in the other place. You could hard-code it based on what you know the server is set up to use (which is what I'm doing now), but that's not terribly robust: What if the default changes at some point? Or what if you add the ability to change the expiration length?

As you say, not huge priority, but definitely worth fixing to avoid little issues down the road.

Let me know if you're open to a PR, and if so, what approach you'd prefer.

[rishabhpoddar]

We would want to change the func signature of CreateMagicLinkByEmail and other similar functions. Surely open for a PR. This would also involve a change in our docs though (wherever CreateMagicLinkByEmail is being used in it)