Moodle

Missing encoding checks /auth/ldap/lib.php

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.5.4, 1.6.2, 1.6.3, 1.7
  • Fix Version/s: 1.8, 1.9
  • Component/s: Authentication
  • Labels:
    None
  • Environment:
    MS-AD, PHP 5.1.2, MySQL 5.0.24 latin charset
  • Database:
    MySQL
  • Affected Branches:
    MOODLE_15_STABLE, MOODLE_16_STABLE, MOODLE_17_STABLE
  • Fixed Branches:
    MOODLE_18_STABLE, MOODLE_19_STABLE

Description

When using latin charset database some functions in /auth/ldap/lib.php are missing proper
encoding checks and conversions if necessary. This will cause data loss when syncronizing database
with LDAP and it disables user accounts when username contains charachters like å, á, é etc...
Functions missing checks:

  • auth_sync_users
  • auth_get_userinfo_asobj
  • auth_ldap_update_user_record

Issue Links

Activity

Hide
Martin Dougiamas added a comment -

To do after backups

Show
Martin Dougiamas added a comment - To do after backups
Hide
Yu Zhang added a comment -

Hi,

Could you pleaes check these modifications are correct? (In the attached file). Sorry I don't know much about LDAP. I could not find where to place checks for auth_sync_users(), where should the checks be?

Yu

Show
Yu Zhang added a comment - Hi, Could you pleaes check these modifications are correct? (In the attached file). Sorry I don't know much about LDAP. I could not find where to place checks for auth_sync_users(), where should the checks be? Yu
Hide
Petr Škoda (skodak) added a comment -

Please no more utf8_decode() it works only for iso-latin-1 only.

When I was hacking with MS LDAP, I noticed that depending on the version it was sending either utf-8 or default platform encoding (cp1250 in my case). I think that the encoding should be configurable, because we can not guess it in all cases.

Show
Petr Škoda (skodak) added a comment - Please no more utf8_decode() it works only for iso-latin-1 only. When I was hacking with MS LDAP, I noticed that depending on the version it was sending either utf-8 or default platform encoding (cp1250 in my case). I think that the encoding should be configurable, because we can not guess it in all cases.
Hide
Petr Škoda (skodak) added a comment -

To be fixed in 1.8

Show
Petr Škoda (skodak) added a comment - To be fixed in 1.8
Hide
Martín Langhoff added a comment -

Now that 1.8 is only UTF-8, the situation is that

  • The LDAP protocol uses UTF-8. Barring servers doing strange stuff, or PHP-LDAP messing the data up, Moodle should just use the string as returned. It will be valid UTF-8. I did quite a bit of digging around the protocol specs.
  • auth/db has 2 cases:
  • DB backend supports unicode (even if the database/tables are not in utf-8), we can just issue "use names UTF-8 " and stop worrying as this transfers the job of ensuring data we trade with the DB is treated as UTF-8.
  • DB backend does not support unicode. Add option to set what encoding should we assume the db is encoded in, and transcode accordingly.
Show
Martín Langhoff added a comment - Now that 1.8 is only UTF-8, the situation is that
  • The LDAP protocol uses UTF-8. Barring servers doing strange stuff, or PHP-LDAP messing the data up, Moodle should just use the string as returned. It will be valid UTF-8. I did quite a bit of digging around the protocol specs.
  • auth/db has 2 cases:
  • DB backend supports unicode (even if the database/tables are not in utf-8), we can just issue "use names UTF-8 " and stop worrying as this transfers the job of ensuring data we trade with the DB is treated as UTF-8.
  • DB backend does not support unicode. Add option to set what encoding should we assume the db is encoded in, and transcode accordingly.
Hide
Petr Škoda (skodak) added a comment -

encoding is now fully configurable, thanks for the report

Show
Petr Škoda (skodak) added a comment - encoding is now fully configurable, thanks for the report

People

Dates

  • Created:
    Updated:
    Resolved: