SMF login problem with accentuated username

[SarekCDL]

Hello,

I recently installed raidplaner for my guild's usage and we have noticed one bug with the SMF bridge.

The accounts containing accents in the username cannot access the raidplaner. It seems that raidplaner can link the account correctly (i saw the account in the admin tab) but users always get a password error message.

After an update on the username directly in SMF to replace it with one without accent the login to raidplaner was successfull but it's annoying.

[arnecls]

I just tried to reproduce the problem on version 1.1.3d but I had no problems connecting to SMF accounts with special characters in it (e.g. "tätü" or "téster" worked just fine).

What's even more interesting is that MySQL (at least in my case and yes, it is mysql not php) even allowed to log in via "tatu". I.e. on my server MySQL seems to simply ignore special characters (I validated this via a simple select).

Long story short I need some more information about your setup to properly reproduce the problem:

• PHP version (just in case)
• MySQL version
• Raidplaner version
• SMF version

[SarekCDL]

PHP version : 5.5 MySQL version : MySQL 5.1.73 Raidplaner version : 1.1.3 (release, not master) SMF version (2.0.8, upgraded 2.0.9 today but I didn't retry with accentuated login)

[arnecls]

Ok, after I finally managed to reproduce your setup (hint: your mysql version is really ancient) I found the problem to be that SMF uses the username as part of the password hash - d'oh. If you install SMF without UTF8 enabled this will lead to encoding error on the password.

I'll have to do a little research on how to use the correct encoding on the user name to fix this. The easier way (at least for me) would be to configure SMF to use UTF8.

[arnecls]

Half-way fixed.

• Download the latest version from the master branch
• Run the binding setup for SMF again (you don't need to change anything)
• Set the login method to cleartext

=> Everything should work now unless your database uses one of the encodings that does not have a conversion, yet.

Please check if this works on your system, too. The javascript (aka. safe) login will probably need some more time to get fixed.

[SarekCDL]

Ok thanks, i will test it as soon as possible. ;-)

[SarekCDL]

Miss click -_-

[arnecls]

Encoded login via javascript should now work, too (1.1.3f). The only thing that won't work are passwords which contain special characters - I currently have no idea how to encode such a string correctly in javascript.

[arnecls]

Two additional fixes:

• Passwords with special characters now work with clear text login
• Group detection now properly works with post based member groups, too

[arnecls]

Did you have a chance to test the latest version, yet?

[SarekCDL]

No sorry, I will try to test it this evening.

Can I overwrite my actual version with master branch without any risk ?

[arnecls]

As you can rollback to 1.1.3 at any time, yes. Just make sure you have a backup of your config files.

I already did most release tests on the master branch on the weekend which worked fine so this version should already be quite stable. The only thing that I did not test yet was a full binding test which takes some time to complete. I.e. there might be some binding/config related problems left, but those be fixable by running the binding setup again (no changes, just keep clicking next until the config files are re-written).

[SarekCDL]

Sorry, I am a bit busy with WoW, raids just started and I didn't have much time.

I'll think I can test it this week-end.

[arnecls]

Moved to 1.1.5. The bug should be fixed now. If it is not it will be fixed for 1.1.5.

[SarekCDL]

Hi,

I finally had time to test it with new version 1.1.4 and it didn't work.

I have rerun binding setup

I test both login cleartext or not, with a password containing special chars or not, nothing work and my test account "tétëtestè" always get "wrong password" error...

Any idea ?

[SarekCDL]

Finally it's worse than before with 1.1.4.

Some users without special chars in login and password cannot log in. They are "locked" on the "Busy. Please wait" message.

[arnecls]

Did you re-run the configuration with "detect settings"? If yes, could you please post me the smf config (without passwords of course). The "spinner" is probably a php error during the login ajax request. I'll have a look if I can find something in that area.

[SarekCDL]

<?php define('SMF_BINDING', true); define('SMF_DATABASE', ''); define('SMF_USER', ''); define('SMF_PASS', ''); define('SMF_TABLE_PREFIX', 'smfcdl'); define('SMF_COOKIE', 'SMFCookieCDL'); define('SMF_AUTOLOGIN', true); define('SMF_POSTTO', 65); define('SMF_POSTAS', 42); define('SMF_MEMBER_GROUPS', '9'); define('SMF_RAIDLEAD_GROUPS', '1,11'); define('SMF_ENCODING', 'UTF-8'); ?>

in addition SMF version never save my change, when I set it to 2.0.9 and re-open the config it returns to 2.0.0.

[arnecls]

Looks like either your DB encoding is not in the list or the problem is now at some other place. Could you please give me the string collation from two fields from the SMF (!) member table (smf_cdl_members)? The fields "member_name" and "password are important" (see image below).

And thanks for pointing out the version bug. Not much of an issue here as the version is not used (yet) but the value should be written.

[SarekCDL]

I, it seems to be same as yours.

[arnecls]

That's strange for several reasons because with UTF8 encoding in the SMF database the login should already have worked before (as JS encoding is UTF8, too and thus the member name gives the same hash). So with that constellation the fix I did does not do anything (besides that "spinner" problem I still have to investigate). So I'll check the whole pipeline again for potential encoding problems.

BTW - Did you convert the database to UTF8 at some point?

[SarekCDL]

No, I did'nt convert the database at this time. (not used to SMF, it's a friend who made install + configuration part so I need to see with him before)

In addition (again :/) one of my members experience the same connection bug (impossible to login, spinner loop) while I rollback code to version 1.1.3 and he didn't have that problem before I try to upgrade.