Hi Michael,
On 07/05/2025 15:52, Adolf Belka wrote:
Hi Michael,
On 07/05/2025 14:44, Michael Tremer wrote:
Hello Adolf,
Thanks for the patch. Is there no return code that we get from htpasswd instead
of parsing the output?
It gives a return code for everything, with numbers of 0 to 7, except for the
use of the -v option to verify the password.
There might be a status code returned. The man page says
3 if the password was entered interactively and the verification entry didn't
match
but elsewhere it does suggest that interactively is not via the -bv option but
where you just use -v and manually type the password when requested on the
command line.
If the status 3 is a valid status code, how can I access that from the output of
the &General::system_output subroutine?
I could give it a try out and if it does work then I could do a v3 patch.
Regards,
Adolf.
This gives
password verification failed
if the existing password for the specified user is not correct and
Password for user fred correct.
if the user specified was fred and the specified password was correct.
It does the above for both the interactive -v and the batch mode using the
command line of -bv
I had to use the check for if the string was found in the return variable
because if I checked if the string matched the contents of the variable it
always failed so I think there is a hidden Carriage Return or something in the
output from htpasswd for the verification test.
Regards,
Adolf.
-Michael
On 7 May 2025, at 13:42, Adolf Belka <[email protected]> wrote:
- Realised that I had not tested the old password beinhg correct or not.
Previous check
gave the same answer irrespective of the output coming from the htpasswd
verification.
- This changes the variable used for the system_output result to an array and
then
checks if the first element contains the failure message that htpasswd gives
if
password verification fails.
- Tested out with correct and incorrect old passwords and gave the correct
answer in
both cases. Confirmed also that the check for the user being present works
correctly
for both an existing and new user name, which it did.
Fixes: bug12755
Tested-by: Adolf Belka <[email protected]>
Signed-off-by: Adolf Belka <[email protected]>
---
html/cgi-bin/chpasswd.cgi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/html/cgi-bin/chpasswd.cgi b/html/cgi-bin/chpasswd.cgi
index c00caca20..46c3e02f6 100644
--- a/html/cgi-bin/chpasswd.cgi
+++ b/html/cgi-bin/chpasswd.cgi
@@ -77,11 +77,11 @@ if ($cgiparams{'SUBMIT'} eq $tr{'advproxy chgwebpwd change
password'})
# Check if a user with this name and password exists in the userdb file
# and if it does then change the password to the new one
my $user = &General::system_output("grep", "$cgiparams{'USERNAME'}",
"$userdb");
- my $old_password = &General::system_output("/usr/bin/htpasswd", "-bv", "$userdb",
"$cgiparams{'USERNAME'}", "$cgiparams{'OLD_PASSWORD'}");
+ my @old_password = &General::system_output("/usr/bin/htpasswd", "-bv", "$userdb",
"$cgiparams{'USERNAME'}", "$cgiparams{'OLD_PASSWORD'}");
if (!$user) {
$errormessage = $tr{'advproxy errmsg invalid user'};
goto ERROR;
- } elsif (!$old_password) {
+ } elsif (@old_password[0] =~ /password verification failed/) {
$errormessage = $tr{'advproxy errmsg password incorrect'};
goto ERROR;
} else {
--
2.49.0
