We have cases in which app developers forget to delete user data when a user is being deleted. This could be problematic as future users with the same username could then access this data.
This mitigates this risk a bit by not allowing reusing of usernames. That said, we still need to fix occurrences of these issues by deleting missed data.
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
this allows authenticating with passwords that contain non ascii-characters in contexts that otherwise do not allow it (http basic)
Signed-off-by: Robin Appelman <robin@icewind.nl>
CreateUserEvent was the only one that didn't matched the naming scheme of BeforePASTTENSEEvent and PASTTENSEEvent. The event wasn't used at all so this just removes it again as there is BeforeUserCreatedEvent that is also available since 18.
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
To continue this formatting madness, here's a tiny patch that adds
unified formatting for control structures like if and loops as well as
classes, their methods and anonymous functions. This basically forces
the constructs to start on the same line. This is not exactly what PSR2
wants, but I think we can have a few exceptions with "our" style. The
starting of braces on the same line is pracrically standard for our
code.
This also removes and empty lines from method/function bodies at the
beginning and end.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
* Order the imports
* No leading slash on imports
* Empty line before namespace
* One line per import
* Empty after imports
* Emmpty line at bottom of file
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Some user backends (like the database backend) allow us to obtain a user
case insensitive. However the UID itself is case sensitive.
Example:
* create a user User1
* login as User1
- This results the data/User1 folder to be created etc
* now have some code somewhere that obtains the userFolder (from
IRootFolder) but pas in 'uSER1' as uid
- The code will check if that is a valid user. And in this case it is
since User1 and uSER1 both map to the same user
- However the the UID in the user object is used for the folder a new
folder fill be create data/uSER1
With this PR this is avoided now. Since we obtain the real UID casing in
the backend before creating the user object.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Fixes#7084
Now entering wrongly cased email (roeland@ instead of Roeland@) for
password reset etc. Will also work.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
`\OC\User\Database::createUser` can throw a PHP exception in case the UID is longer than
permitted in the database. This is against it's PHPDocs and we should cast this to `false`,
so that the regular error handling triggers in.
The easiest way to reproduce is on MySQL:
1. Create user `aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa` in admin panel
2. Create user `aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa` in admin panel again
3. See SQL exception as error message
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
Most of the time, when people have multiple backends or add a
custom backend, they want to create the users there and not in
the default backend. But since that is registered first, users
were always created there.
Signed-off-by: Joas Schilling <coding@schilljs.com>
Use firstLogin event to trigger creation of default calendar and default address book
Delay login of admin user after setup so that firstLogin event can properly be processed for the admin
Fixing tests ...
Skeleton files are not copied over -> only 3 cache entries are remaining
Use updateLastLoginTimestamp to properly setup lastLogin value for a test user