OK, so there is a bug at login time. Of course, it needs to be fixed.

Now about extending the case sensitivity to accents, I reply "this is going to be very complicated" because we have to think for all characters supported by UTF-8.

We have already encountered such a difficulty for tag names. A tag has a name and a url_name. the url_name is used in URLs and is a simplified version of the name : without accents. For exemple "béatrice" will become "beatrice". The problem was for russian or chinese tags : url_name was always empty, and it was making the tags feature impossible to use. The solution I took was to say : if the result of the create_url_name($name) was empty then $url_name = $name.

Adding the "accent removal" in Piwigo core doesn't sound like a great idea to me. It's a good idea in a plugin, but not in Piwigo core (not yet at least)

By the way, this configuration parameter should have been name $conf['case_sensitive_username'] (to avoid negative boolean variables... it's much easier to read $conf['show'] = true than $conf['hide'] = false)

Hi dear Piwigo team ;

LucMorizur wrote:

[Bugtracker] ticket 1835

So to fix that bug, do you think that should be used usual "simple" PHP functions like strtolower() , or that we could use a much more complex, but normally also more complete function, like the one developped by Eric, Whiler and me: http://piwigo.org/dev/browser/extension … v=head#L28 ?

LucMorizur wrote:

_ The solution I proposed uses PHP function strtolower() . But it gives me this strange behaviour: it will not convert "Béa" the same way on my local installation (Win XP SP3, WampServer 2) than on my ISP (Free) installation, see images attached. So it might be that accentuated characters might cause a problem, this needs to be cleared.

You have to specify your encoding somewhere...
For example: mb_strtolower($_POST['n_text_entry'], 'UTF-8')

Another way would be to use a source file encoded in ISO.... but not very useful in your context ;o)

Whiler wrote:

or you can change your internal encoding...

If you test this, I'm pretty sure you are in ISO-8859-1 ;o)

          <tr><td><?php
            echo('mb_strtolower ('.mb_internal_encoding().')&nbsp;:&nbsp;');
          ?></td><td><?php
            echo mb_strtolower($_POST['n_text_entry'], 'UTF-8');
          ?></td></tr>

Well, yes in this case mb_internal_encoding() answers ISO-8859-1 cause I didn't precise 'UTF-8' as I should have done, you're right that it should be done this way for mb_strtolower() . But what about strtolower() ? And is it allowed to use mb_strtolower() on all servers ?

EDIT : I precise that in this test page, I added the line <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> , and that FF in the page infos, tells that the page is properly displayed and coded in UTF-8. But that's true, mb_strtolower() should be precised 'UTF-8'.

Last edited by LucMorizur (2011-01-05 11:33:27)

LucMorizur wrote:

Hi;

I've submitted a proposal to fix [Bugtracker] ticket 1835 . You can test on my test gallery http://lucmorizur.free.fr that user Test (password: 1234) can be logged in with any spelling : TEST, test, TEst... I added two lines in ./identification.php , and a 30-lines function in ./include/functions_user.inc.php .


Now remains two points:

(...)

A third point I think : probably this solution does not work for Apache authentication and for external user tables (when Piwigo uses a user table that it doesn't manage by itself). Yet at least, users should be able to authenticate with the proper spelling of their username, just as if $conf['insensitive_case_logon'] was set to false. I didn't test such cases.

rvelices wrote:

as I said in the bug tracker the easiest and automatic solution would be to change the type of db column #users.username from binary to not binary (case insesitive).

I already did this on my site sometime ago. The only issue if we do that automatically in the next version is if you already have users Test and test -> it will be a problem because username is a unique key and we'll have db errors ...

Many thanks rvelices for your contribution.

I have written in the bugtracker that on my local configuration, the table #_users is already of type utf8_general_ci , but as you know well, indeed the table is qualified utf8_general_ci for the whole table, but in fact most of the fields are utf8_general_ci , and the `username` field is utf8_bin . And indeed as you wrote it, once you've changed the `username` field to utf8_general_ci , if you ask for

SELECT * FROM #_users WHERE `username` = 'test'

you will get user Test.

And as you wrote it also, if you have already users "test" and "Test" in this table, the attempt to convert field `username` to utf8_general_ci fails, because an item of the field `username` cannot be duplicate, and "test" and "Test" are equal in a utf8_general_ci field.



Yet if we go on forward, to my opinon the solution you propose would then force to establish at installation time whether usernames shall be case sensitive or not -- which could be better indeed. Because changing `username` field to utf8_general_ci once the gallery is installed , is at least as much complex as my solution (need to arrange the case where conversion fails, propose a button or anything allowing the webmaster to ask for the conversion, and display this command).

Looking forward on your opinion on this :-) .

justin_ruch1180 wrote:

WHEW.. This is complicated for me...:(

For us too ^^ !

The problem is that we want to have one's cake and eat it ("avoir le beurre et l'argent du beurre" in french, or so says my dictionnary :-/ ...): we want to make possible that a gallery is one day "username case sensitive" and the other day "username case insensitive" -- at least is it what parameter $conf[insensitive_case_logon] leads to. So we need to manage the case where some different usernames are in conflict at the instant you turn your gallery "username case insensitive" -- if you have users "Test" and "test" who both registered in your gallery when it was "username case sensitive", and that these two usernames where considered as really different.

Indeed I'm still interested in rvelices' opinion ;-) .