There were this error in the console:
> The association Wallabag\CoreBundle\Entity\SiteCredential#user refers to the inverse side field Wallabag\UserBundle\Entity\User#site_credentials which does not exist.
When a user login using the form we know log an error level information with information about the user:
- username used
- IP
- User agent
For example:
> Authentication failure for user "eza", from IP "127.0.0.1", with UA: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36".
It’ll allows server admin using fail2ban to configure it to block these people if they generate too much failure authentication.
While creating a new user using the API, we also create a new client for the current user.
So the app which just create the user can use its newly created client to configure the app.
That new client is only return after creating the user.
When calling the endpoint /api/user to get user information, the new client information won’t be return.
The only ugly things is how we handle error by generating the view and then parse the content to retrieve all errors…
Fix exposition fields in User entity
When resetting the password, the overriden template we used wasn’t well spelled.
And since we are using a locked version of FOSUser (on a custom commit), the translation of `resetting.check_email` is wrong in any language but english.
We are injecting CraueConfig service when we only need to retrieve one or two values from it.
Instead I discovered we can directly inject a value from a service in the service definition!
When a user register itself AND the wallabag instance is configured to send a confirmation email, the user is disabled when the listener (which create the config) receive the event.
There were a check (don't know why) if the user is enabled we create the config. But the user is disabled when confirmation email is actived.
