[Meta] Users

[netsensei]

This is a meta issue. This issue groups all issues regarding the "Users" (user management, user creation, login/logout, etc.)

Detailed description

Support for users is only partially implemented in version 1.0.0. We need to revise and overhaul the entire User component in order to make it work properly.

Possible implementation

The issues below this list are related to users. Check them off after closing each issue individually. When all issues are closed, this meta issue can also be closed.

General discussion about this component happens here, concrete implementation of features / bugfixes in separate issues.

• [x] User management overview page
• [x] Deleting a user as an administrator does not work
• [ ] Manage OAuth per user
• [x] Create new users as an administrator
• [x] Edit an existing user as an administrator
• [x] Confirm registration as a newly registered user
• [x] Login as a registered user
• [x] Logout as a registered user
• [x] Request a new password as a registered user
• [x] View my profile as a registered user
• [x] Edit my profile as a registered user

[netsensei]

Integrate FOS UserBundle profile support

Detailed description

The Datahub uses FOS User Bundle which comes with /profile route (and subroutes) which allows the current logged in user to change their own mail address and password. Currently, the interface doesn't link to those paths and neither the forms / views on those paths are themed.

It would be a good, userfriendly enhancement to include them in the Datahub.

Context

• Userfriendly way of changing your own profile details, password, etc.
• Extensible to include other features we might want to include in the long term future.

Currently, we roll our own interfaces via a UsersController in DataHub\UserBundle. The goal of this issue should be to:

• revamp this bundle and integrate more cleanly with FOSUserBundle.
• Provide functional tests (PHPUnit in tests/) for all custom interface elements we add.

Possible implementation

User support is already partly build into the Datahub. We should try to reuse as much as possible of what is already implemented by extending and improving. There are a few conventions that need to be adhered to:

• All views are stored in app/Resources/FOSUserBundle/
• All functional tests are stored in tests/FOSUserBundle/
• The logic itself (services, controllers, ODM model) is stored in src/UserBundle/

[netsensei]

Research in the past few weeks concludes that FOSUserBundle isn't the right tool within this context. It's a great bundle to quickly wire up a basic authentication system for a simple application. But it doesn't scale well in a fully fledged durable application.

See: https://jolicode.com/blog/do-not-use-fosuserbundle

In the context of this project: Adding separate user management through an administrative user interface would require us to implement a separate bundle that wires up or overrides parts of FOSUser (controllers, actions, templates,...) to the point where the whole thing becomes unmaintainable.

Instead, implementing User Management / Authentication / Authorization via Symfony/Security and the standard Symfony toolbox would gives us more control and flexibility to create a clean, maintainable architecture which plays nicely with other components such as FoS OAuth:

See: https://knpuniversity.com/screencast/symfony-security

Conclusion: We need to yank out FOSUserBundle and replace it entirely with our own implementation.

[netsensei]

Finally got round merging the "users" branch into master.

The biggest change is successfully removing FOSUserBundle integration for a custom implementation based on the Symfony Guard Authorization component.

So, this overhaul contains functionally:

• Proper user management (create, edit, delete users)
• User login with "request new password" functionality with a confirmation e-mail.
• First time login for new users with confirmation e-mail.
• Assign roles to users (Consumer, Manager)
• A first-time installer which will create an administrator with a custom password
• A proper "view" user profile per user.

A lot of time has been sunk in writing functional tests for this component in order to assure to cover most of the complexity which lurks beneath the hood.

There's still some finishing that needs to happen:

• Properly designed HTML and text versions of the e-mails.
• Proper finishing of the display of roles on the profile and overview pages of users.
• Translation of the interface (i10n)
• Proper design of the "profile" menu in the navigation bar.
• Proper pentesting of the login functionality (security)