-
-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: NC 25.0.x - authentication - a need to recalculate credentials after secret is updated from empty to non-empty value #35443
Comments
Does it matter if I see exception to be thrown at files_external (retrieve function, see logs as I have pasted)? Maybe stored credentials (stored with "empty" secret) cannot be retrieved with new secret? In such a case - maybe some kind of fixup for data will be the solution (or such a solution shall be a part of job as implemented in #35368). Please take a look at CredentialsManager.php and then at Crypto.php. It seems that definitely secret is used to calculate HMAC. |
Edit: success - I have simply analyzed the code and it seems that credentials are refreshed, as for my settings: So, I have deleted all records from oc_storages_credentials table. And... now login succeeds. Current state (after login for 1st of LDAP user): So, I strongly suggest to add "recalculation" of credentials for job added in #35368 (only in case secret was empty/not defined and upgrade is making non-empty value). This suggestion is really for all data that may have been previously stored with empty secret. |
CredentialsManager, cc @CarlSchwan |
Shall the title of issue be changed? Currently it may not fully describe what the issue is (it was resulting that authentication was failed but the reason/root-cause was different). |
Are you aware of any other places (besides listed here: "oc_storages_credentials") that such a recalculation may be required? Proposal of new title "[Bug]: NC 25.0.x - authentication - a need to recalculate credentials after secret is updated from empty to non-empty value". |
@CarlSchwan any update ? or is there a workaround ? |
Anyone wants to try? #35600 |
and #35605 is also needed. We forgot to backport it to 25 |
What is the strategy? I assumed originally that it will be a part of job from #35368 - simply - in case update was from empty secret to non-empty - then in particular places - read ALL encrypted values with secret = '' and store them immediately with secret = new secret. But it seems that the solution relies on fallback - "try to read the encrypted value and if it has failed - try next read with secret = ''? |
Bug description
According to reported issue #35347 my installation didn't have "secret" defined. Once issue has been reported it was arbitrarily marked as "resolved by #35368". Nobody has noticed that I have commented that if I add secret to my config (add manually) then authentication will not work with LDAP users:
In the log (see below) - there is an exception reported with HMAC does not match.
Remark: the same issue was for 24.0.7 - when I added secret manually - LDAP authentication was not working.
So, this issue is about it. Secret is already defined but I am not able to login by LDAP users. Definitely the problem is with the secret itself as when I remove it and additionally apply code fix (procedure in OC_Util to check existence of secret) - everything is working.
Of course for now I will apply my "code workaround" (see below) again and remove secret from config:
Steps to reproduce
Expected behavior
Login for LDAP users with "secret" defined shall working correctly - the same as without secret.
Installation method
Community Web installer on a VPS or web space
Operating system
Debian/Ubuntu
PHP engine version
PHP 7.4
Web server
Apache (supported)
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
Updated to a major version (ex. 22.2.3 to 23.0.1)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info
No response
The text was updated successfully, but these errors were encountered: