password error message is incorrect when extended characters are used

RESOLVED WORKSFORME

Status

()

Bugzilla
Bugzilla-General
--
trivial
RESOLVED WORKSFORME
15 years ago
10 years ago

People

(Reporter: Brant Gurganus, Unassigned)

Tracking

Details

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624

I used eight characters from Unicode that were beyond the ASCII range.  I
received an error that 16 characters is too long even though I used eight
characters.

Reproducible: Always

Steps to Reproduce:
1. Use characters in a password that are beyond the ASCII range.
Actual Results:  
An incorrect error.

Expected Results:  
A correct error or characters beyond the ASCII range are not accepted.

This can probably be prevented by the accept-charset attribute of the form
element being US-ASCII.

Comment 1

14 years ago
related to bug 218025?
(Reporter)

Comment 2

14 years ago
Frank, the principal behind the errors is probably the same (product is designed
for eight-bit characters), but the products are different so fixes would be
unrelated.
Reassigning bugs that I'm not actively working on to the default component owner
in order to try to make some sanity out of my personal buglist.  This doesn't
mean the bug isn't being dealt with, just that I'm not the one doing it.  If you
are dealing with this bug, please assign it to yourself.
Assignee: justdave → general
QA Contact: mattyt-bugzilla → default-qa

Comment 4

10 years ago
dkl, himorin: is this bug still valid? If not, do you know which bug fixed it, or at least the version since which this issue is fixed? If you know the bug which fixed it, please mark this bug as depending on the other bug, set its milestone accordingly and mark this bug as FIXED.
Keywords: qawanted

Comment 5

10 years ago
(In reply to comment #4)
> dkl, himorin: is this bug still valid? If not, do you know which bug fixed it,
> or at least the version since which this issue is fixed? If you know the bug
> which fixed it, please mark this bug as depending on the other bug, set its
> milestone accordingly and mark this bug as FIXED.

I think this is fixed with introducing utf8 flag for string. So, this might be reproduced with setting utf8 parameter to off.
If not utf8-flagged, length will return its bytes, but length will return its char count (as utf-8) when utf8-flagged.
Of cource, password is 'crypt'-ed in DB of the Bugzilla, so only first xx (i forgot :-p) bytes of the password will be used.

Comment 6

10 years ago
Based on testing done by himorin, this is WFM. You must have the utf8 parameter set to 1.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Keywords: qawanted
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.