Do not pass object without __toString for token generator

[phan7om]

May be it's good for those who implements that receipt from cookbook to prevent them from this trap.

[linaori]

It's clearly documented in the signature of the object though: https://github.com/symfony/security-core/blob/master/Authentication/Token/UsernamePasswordToken.php#L29

I don't think a comment like this would help much though, maybe it would be better to add it to a ..note: or something? @xabbuh this would be a nice case to 'annotate' code as I mentioned some time ago 😉

[xabbuh]

If we want to add such a warning it would imo better be placed in http://symfony.com/doc/current/cookbook/security/guard-authentication.html#create-a-user-and-a-user-provider and http://symfony.com/doc/current/cookbook/security/custom_provider.html.

[phan7om]

I think it's better to place it in custom_password_authenticator article because there are some other cautions present. And for those who started using this guide from that page would be easer to avoid pitfalls.

[wouterj]

I'm sorry, but I'm 👎 on this change. For a couple of reasons:

• This applies to the user object in the complete security systems. It's more usefull to talk about such things in the articles where we create user objects or user providers.
• If you create a security user, you should implement UserInterface and the problem is fixed
• I've a code branch locally that removes the double functionality of tokens (both before and after the user is authenticated). This means users always are objects implementing UserInterface and we no longer have this strange thing.

[javiereguiluz]

@phan7om we recently revamped Symfony Docs so we can no longer merge your original pull request. Besides, I agree with the reviewers comments, so I've created #6837 and #6838 taking this pull request as inspiration. Thanks!

[xabbuh]

Thank you for starting this @phan7om. I am closing here in favour of #6837 and #6838.