View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001964 | MMW v4 | Other | public | 2005-08-05 08:16 | 2008-11-26 06:06 |
| Reporter | jiri | Assigned To | |||
| Priority | high | Severity | minor | Reproducibility | always |
| Status | assigned | Resolution | reopened | ||
| Summary | 0001964: Serial Number Algorithm: should not generate keys with similar looking characters | ||||
| Description | Our serial number algorithm generates some keys that are difficult and/or impossible for a user to enter if they enter the key manually, because the user confuses or has no way of knowing what character to enter. Confusing: O, o, vs 0 Impossible: l, I, l (lowercase L) | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
One easy way of getting around this without changing the algorithm would be to make the client side 'flexible' so that it can accept those characters interchangeably. |
|
|
Jiri, I know you'd indicated that you already included some 'smarts' in the algorithm. Can you indicate in this bug? (I can't find your comments on the subject). |
|
|
Currently the generated keys can contain only uppercase letters A-Z without 'O' and digits 1-9 (i.e. without '0'). Btw, I'm listed as a reported of this bug, but I don't recall entering it into Mantis!? Is it a Mantis bug? |
|
|
Ok, so the only problem is when the user enters a lowercase L instead of a 1 (both of these appear identically in some fonts). It would probably be worthwhile to make the client side software accept a 'lowercase L' or a '1' whenever a '1' is the desired number. Setting as urgent, but feel free to push back--lately I haven't gotten that many serial number related complaints. |
|
|
Since this isn't easily possible, I'd suggest keeping it as is. |
|
|
Wouldn't it be simple in cases where the key fails to just check for an 'l' or a '1' in the key and if it's there, compare a second string in which the 'l's and '1's are switched? The problem isn't a daily occurence, but it's often enough that if this is less than an hours work, it'll save time in the long run. |
|
|
It isn't just about switching, it would be necessary to test all combinations, i.e. 2^n combinations. Not that it's impossible, but quite problematic. |
|
|
Would you really have to check all cases? Wouldn't it be sufficient to just check the case where the user misinterprets all 1's as l's or vice versa? (i.e. if they appear the same way, it's unlikely that the user will sometimes interpret the character one way and other times another). |
|
|
I think it's very likely (in case user makes an error) user interprets both 1's and I's the same way, i.e. both as 1's or both as I's. In such case all possible combintations have to be checked. |
|
|
Reducing priority on this...we'll see over the next little while whether we can do without this... |
|
|
Raising the priority again. There are easily several queries a week on this subject--it's a big time waster. |
