Implemented visuals for enabling/disabling user from admin user list.
Added the controller functions for enabling/disabling a user.
Added the route for changing user status (enabled/disabled) and added an additional route handler in the user controller.
Finished the visuals to reflect current user status and changed user status respectively.
Changed the single icon for enabling/disabling a user into a menu where deletion and state toggling of a user is selectable.
Added displaying of disabled user count.
Improved style of user action menu.
Added proper counting of disabled users.
Removed visual indicator for disabled users.
Moved pseudo-group detection for disabled users from frontend to the controller.
Changed units for newly introduced css values from em to px.
Removed unnecessary png and optimized svg with scour.
Changed the userlist template to display the user action menu with correct width.
Style fixes for better readability and coding style conformity.
Changed the icons for enabling, disabling and deleting a user in the action menu.
We do not want to have sensitive information in the URL and
therefore also not in the access log. Thus the GET request is
replaced by a POST request.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
When we test wheter action menus in the contacts menu close
when clicking other ones, we have to provide test data
that actually causes the view to render the menu.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
This implements the basics for the new app-password based authentication flow for our clients.
The current implementation tries to keep it as simple as possible and works the following way:
1. Unauthenticated client opens `/index.php/login/flow`
2. User will be asked whether they want to grant access to the client
3. If accepted the user has the chance to do so using existing App Token or automatically generate an app password.
If the user chooses to use an existing app token then that one will simply be redirected to the `nc://` protocol handler.
While we can improve on that in the future, I think keeping this smaller at the moment has its advantages. Also, in the
near future we have to think about an automatic migration endpoint so there's that anyways :-)
If the user chooses to use the regular login the following happens:
1. A session state token is written to the session
2. User is redirected to the login page
3. If successfully authenticated they will be redirected to a page redirecting to the POST controller
4. The POST controller will check if the CSRF token as well as the state token is correct, if yes the user will be redirected to the `nc://` protocol handler.
This approach is quite simple but also allows to be extended in the future. One could for example allow external websites to consume this authentication endpoint as well.
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
Morris Jobke
Thomas Pulzer
Jan-Christoph Borchardt
Nextcloud bot
Julius Härtl
Roeland Jago Douma
Lukas Reschke
Joas Schilling
Robin Appelman
Ivan Sein
Vincent Petry
Georg Ehrke
Christoph Wurst
Roeland Jago Douma