fix(UserConfig): cast getTypedValue() result to string in getValueBool()

[thereisnotime]

• Resolves: [Bug]: NC 33 / PHP 8.4: TypeError in UserConfig::getValueBool() — strtolower() receives non-string from getTypedValue() #59629

Summary

PHP 8.4 made passing non-strings to strtolower() a fatal TypeError. UserConfig::getValueBool() calls strtolower() directly on the return value of getTypedValue(), which can return a non-string under certain conditions. The (string) cast prevents the TypeError regardless of what getTypedValue() returns.

Verified in production on NC 33.0.2 / PHP 8.4 — LDAP users were getting 500 errors on every authenticated request.

TODO

• Investigate the root cause of why getTypedValue() returns a non-string (see discussion in [Bug]: NC 33 / PHP 8.4: TypeError in UserConfig::getValueBool() — strtolower() receives non-string from getTypedValue() #59629)

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation has been updated or is not required
• Backports requested where applicable — backport to stable33 needed
• Labels added where applicable
• Milestone added for target branch/version

AI (if applicable)

• The content of this PR was partly or fully generated using AI

[artonge]

Isn't it the same as #59630 ?

[CarlSchwan]

Isn't it the same as #59630 ?

yes but the diff is clean

[CarlSchwan]

I don't get how getTypedValue can return something which is not a string

[nickvergessen]

Empty string on oracle is null?

[susnux]

See stack trace in linked issue. It is a string. Php would throw if it is not a string due to strict types.

I suspect a faulty PHP build being used on that machine.

[thereisnotime]

Not Oracle, it's pgsql (as in the issue). The ): string hint is correct in the happy path, but the values returned come directly from $fastCache/$lazyCache, which are populated from PDO row data. The ?? '' in loadConfig guards against null, but doesn't cover all non-string cases that can end up in the cache from other write paths. The specific case here is user_ldap calling getValueBool($uid, 'user_ldap', 'isDeleted') on users who never had that key written, where a type mismatch in the stored metadata is enough to trigger it. PHP 8.4 made strtolower() fatal for non-strings (before that it was a silent deprecation), which is why this is only surfacing now. The stack trace in #59629 is from a stock PHP 8.4 build, reproduced by multiple people.

[susnux]

  {"file": "lib/private/Config/UserConfig.php", "line": 688, "function": "strtolower", "args": ["false"]},

It gets passed a string, so the error makes no sense.
Also if like you describe a non-string would be returned by getTypedValue, then the error message would be:

TypeError: getTypedValue(): Return value must be of type string, false returned

[susnux]

The stack trace in #59629 is from a stock PHP 8.4 build, reproduced by multiple people.

Not sure what a "stock php 8.4" is, as every distribution could compile PHP in a different way.
I tried to reproduce this but it simply cannot be reproduced the way it is reported.

Setup: I use PHP 8.4.20

Try 1: Call the getValueBool where no value was ever written to user_ldap. ➡️ works as expected no error.

Try 2: Manipulate the caches to return invalid value ➡️ throws different exception because caches are already used before.

Try 3: Manipulate method to return false ➡️ different error:

OC\Config\UserConfig::getTypedValue(): Return value must be of type string, false returned in file '/var/www/html/lib/private/Config/UserConfig.php' line 745

---

So maybe just try to update PHP to 8.4.20

[thereisnotime]

Running PHP 8.4.20 (same version you tested with), image nextcloud:33.0.2-apache.

Production logs from this instance (redacted user IDs):

TypeError: strtolower(): Argument #1 ($string) must be of type string, string given
  at /var/www/html/lib/private/Config/UserConfig.php#688

Stack trace args show strtolower('false'), which is indeed confusing since 'false' looks like a string in the serialized output. The error message itself ("must be of type string, string given") is contradictory, which may point to something deeper in how this specific code path interacts with the PHP runtime.

The call path is:

UserConfig->getValueBool($uid, 'user_ldap', 'isDeleted')
  → DeletedUsersIndex->isUserMarked($uid)
  → User_LDAP->isUserEnabled($uid)

This happens on every authenticated request for LDAP users. Multiple users hit it simultaneously (both UUID-based and username-based LDAP identifiers). The (string) cast resolves it regardless of the root cause.

I agree the error message doesn't match what you'd expect from a strict return type violation on getTypedValue(). Happy to run any additional debugging you'd find useful on this instance.