returning SignupResult.USER_CREATED doesnt send verification email about play-authenticate HOT 3 OPEN

Returning USER_CREATED means that there is no verification, e.g. the email is not needed - why would you want the user to verify his/her email address, if you allow that person to log in without that verification anyways?
Passing the context down would be an option, making sendVerifyEmailMailing protected is a bad idea I think because then there is virtually no API any more, but just a shell of a provider that can be used to do virtually anything.

Are you aware that you can write your very own login provider completely decoupled from any provider code that is implemented and shipped with Play! Authenticate already? If you have very special needs regarding the flow in your application that might be the easier way to go.

from play-authenticate.

Your right about making my own provider. I didn't take this approach as I
just needed a small correction with the default one.

In my use case, I still want users to verify their emails, however, I want
them to be able to have a seamless workflow when they signup and not be
bothered with verifying until later on. I still wanted to send out an
email when a user signs up which makes passing down the Context useful.

After your response, I will be making my own provider to do exactly what I
want, although passing the context down could be a good change if you're
willing to make a breaking change. Otherwise, I have what I need to
correct my code.

On Sun, Mar 3, 2013 at 3:30 PM, Joscha Feth [email protected]:

Returning USER_CREATED means that there is no verification, e.g. the
email is not needed - why would you want the user to verify his/her email
address, if you allow that person to log in without that verification
anyways?
Passing the context down would be an option, making sendVerifyEmailMailingprotected is a bad idea I think because then there is virtually no API any
more, but just a shell of a provider that can be used to do virtually
anything.

Are you aware that you can write your very own login provider completely
decoupled from any provider code that is implemented and shipped with Play!
Authenticate already? If you have very special needs regarding the flow in
your application that might be the easier way to go.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/61#issuecomment-14354526
.

from play-authenticate.

To be honest I'd rather not make a breaking change if it's not really needed, because lots of people just upgrade to the latest version without reading the release notes :-O and then it won't work any more. However I think this can be changed in a backwards compatible manner by overloading with a protected method and then calling the one that is implemented in the subclass without context, so if you are willing to provide a pull request that does just that, I'd consider merging it - if you are going to implement your own provider though, I'd recommend to let the interface be stable :)

from play-authenticate.