Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Critical
-
Resolution: Fixed
-
Affects Version/s: 1.7.1, 1.8
-
Fix Version/s: 1.8
-
Component/s: Authentication
-
Labels:None
-
Database:MySQL, PostgreSQL
-
Affected Branches:MOODLE_17_STABLE, MOODLE_18_STABLE
-
Fixed Branches:MOODLE_18_STABLE
Description
When using db authentication, by default Moodle connects under iso-8859-1 charset. This causes that retrieved data from external DB is iso-8859-1. And such data (fistname, lastname...) is discarded on insert if Moodle is running under UTF-8.
So the actual situation is that DB authentication with non-ASCII characters is only working if Moodle is running in NON-UNICODE mode (then such retrieved data is perfectly inserted).
With more and more Moodle sites running under Unicode, this is really an ugly problem. Luckly it has a SIMPLE solution:
1) Always stabilise the authdb channel to be UTF-8. This will cause retrieved data to arrive always in UTF-8 (no matter of the authdb real encoding, both drivers will perform the needed conversions automatically). (That's the attached patch).
2) Some lines below, data will be converted back to ISO-8859-1 for Moodle running in NON-UNICODE mode (this part of code currently exists).
Note that this will fix the problem under MySQL and PostgreSQL (where we can stabilise the communication channel). MSSQL and Oracle auth-dbs are required to run under UTF-8.
Please, take a look to the simple patch. I've tested it both against iso-8859-1 and utf-8 autdbs and under iso-8859-1 and utf-8 moodle dbs. Seems to support all the combinations.
Ciao 
Attachments
Issue Links
Activity
- All
- Comments
- History
- Activity
- Source
- Test Sessions
Just some random comments:
1.- I can't see anything wrong with the patch, but I'm no db guru by any means
2.- Shouldn't we do something similar to auth_user_login()/user_login() (1.7.x/HEAD) for the password check when $CFG->auth_dbpasstype/$this->config->passtype === 'internal' ?
3.- It seems auth/db is still using the old db prefix hack. I thought you fixed it (unless you just fixed it in enrol/database). Aha! Now I see it. You fixed it in HEAD, but not in 1.7.x
Saludos. Iñaki.
2.- Shouldn't we do something similar to auth_user_login()/user_login() (1.7.x/HEAD) for the password check when $CFG->auth_dbpasstype/$this->config->passtype === 'internal' ?
3.- It seems auth/db is still using the old db prefix hack. I thought you fixed it (unless you just fixed it in enrol/database). Aha! Now I see it. You fixed it in HEAD, but not in 1.7.x
Saludos. Iñaki. Hi,
1-) Great. I'll consider you voted +1. Form DB perspective I think it's correct. Two more positives needed.
2-) Yep, in fact my patch running HEAD at home does exactly that for each $authdb->Connect() in the file (4 occurrences more or less). But finally I only applied it to the auth_get_userinfo(), because it was safe to use it there and no in other places, because such method is the only one that, some lines below, perform the correct conversion if the DB is not unicode. So I would propose:
2a) For 17_STABLE, apply it ONLY as showed in the attachment - applied to auth_get_userinfo() exclusively.
2b) For HEAD, apply it to every connection in auth/db/auth.php, because Moodle 1.8 is UTF-8 always and it's safe to set the communication channel always to UTF-8.
3-) Yes, that issue (MDL-8152) was applied exclusively to HEAD (17_STABLE continues using the old prefix hack).
Ciao
fixed in cvs, ext db encoding in now configurable and there is a setup commend when ppl can type set names 'utf8' or set names 'latin1'
closing now, thanks for the report 
Raising it to critical.
Adding some auth gurus here. In case I get 3 positives, I'll apply it both to 1.7 and HEAD. If somebody can imagine any combination where it won't work, please....tell about.
Ciao