There were some cases where a negative limit could be passed in. Which
would happily make the query explode.
This is just a quick hack to make sure it never is negative.
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#11097
If your password hash changed (becuse your are on 7.2 and we moved to
ARGON2). Then we shold not 'set a new password' but just update the
hash. As else we invoke the password policy again which might lock out
users.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Fixes#9279
If a pure numerical user is in the DB the value might be casted to a int
when returned. Cast it all to a string so we don't break the strict
typing.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Due to a misplaced closing parenthesis the condition of the left join
clause was just "userid = uid"; the other conditions were passed as
additional parameters to "leftJoin", and thus they were ignored.
Therefore, the result set contained every preference of each user
instead of only the email, so the "WHERE configvalue LIKE XXX" matched
any configuration value of the user.
Besides the closing parenthesis this commit also fixes the literal
values. Although "Literal" objects represent literal values they must be
created through "IExpressionBuilder::literal()" to be properly quoted;
otherwise it is just a plain string, which is treated as a column name.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Fixes#7175.
- Updated the query to fetch the users in users > everyone tab.
- Updated the query to fetch the users in users > admin tab.
- Tested to ensure that the disabled users are also being fetched.
- Added test cases.
Signed-off-by: Abijeet <abijeetpatro@gmail.com>
`\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>
The constructor is iniitiated already very early in base.php, thus requiring this here will break the setup and some more. For now we probably have to live with a static function call here thus.
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
For guest users on every request executes query:
SELECT `uid`, `displayname` FROM `users` WHERE LOWER(`uid`) = LOWER(null)
as I see, uid can't be equal to null by design.
We always query the database backend. Even if we use a different one
(ldap for example). Now we do this everytime we try to get a user object
so caching that a user is not in the DB safes some queries on each
request then (at least 2 what I found).
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
