Red Hat Bugzilla – Bug 155379
error message in validate_user_password seems incorrect
Last modified: 2007-04-18 13:24:03 EDT
Description of problem:
as per #151328:
either the error message is wrong, or the regex/logic is wrong. I'm
not entirely sure what the intended behaviour is.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Should be fixed in rhns-4.0.0-53 and newer.
Test case: see bug 151328
Essentially, try to put a * in your password. Should work.
Try to put a * at the beginning of the password. Should work.
Try to use only * chars. Should fail.
*** Bug 157375 has been marked as a duplicate of this bug. ***
*** Bug 151328 has been marked as a duplicate of this bug. ***
This bug is considered CanFix for RHEL 3 U6 by RHN Engineering.
Mass move to ON_QA
Dev & PM ACKs for U6
6/28/2005 -- bnackash
1- Using the web UI to create a new user, I was able to successfully choose a
password of "*******" and log in as the new user. Bug 151328 states that the
web UI does allow all asterisks for the password, but I'm not sure if that's a
feature or a bug. If feature, then disregard this comment.
2- Using the web UI, I was able to successfully change my RHN password to
*********** or something of that ilk. (At least the web UI indicated my
information had been updated.) And now I can't remember how many ********s I
used and locked myself out of RHN :( Again, not sure if this is a feature or a bug.
3- There's a small typo in the error message: "password can not be all
asterisks" should say "password cannot be all asterisks".
Other comments from Beth: Using up2date --register (up2date-18.104.22.168-2), I was
unable to enter a password with all asterisks. I was able to enter a password
with one or more asterisks. This is correct behavior.
#3 from comment #8 fixed in svn
rest is pending discussion on whats the correct behaviour
Seems we decided client is doing the right thing, so moving this to ON_QA
up2date-4.4.30-3 still says "password can not be all asterisks"
Which up2date fixes this?
re comment #12
It's a server side change, not a client side change, so fix should
appear for next QA push.
Do you mean the fix should have made it into Thursday's (7/14) QA push? Because
doh, never actually committed it. Next QA push.