Summary: | Encoding problem with utf8 chars in userid | ||
---|---|---|---|
Product: | Koha | Reporter: | Marcel de Rooy <m.de.rooy> |
Component: | Authentication | Assignee: | Marcel de Rooy <m.de.rooy> |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | major | ||
Priority: | P5 - low | CC: | bgkriegel, dpavlin, karamqubsi |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6554 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9951 |
||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: | ||
Bug Depends on: | 6554 | ||
Bug Blocks: | |||
Attachments: |
Bug 10019: Fix for userid containing UTF8 chars
Bug 10019: Fix for userid containing UTF8 chars |
Description
Marcel de Rooy
2013-04-10 07:47:13 UTC
A observation to start with: The line in admin/preferences.pl: $YAML::Syck::ImplicitUnicode = 1; somehow makes the userid appear correctly. Looking at it from a distance, this seems a unwanted side-effect. This statement influences more than it looks like. We could also enable this YAML var only when needed (during the load of the pref file). But this is another report. My solution for the current problem does not interfere with this side-effect.. To solve this problem, I followed Bernardo's idea about CGI::Session. But I checked the session info and it was good. But deeper in Auth.pm, the userid parameter was not decoded. When coming from CGI Session in one instance (it is decoded in setuserenv but later used again from CGI::Session) and when coming from CGI in another instance. So a two-liner patch should resolve the problem.. To test this, you really need to login/logout on opac/staff, delete sessions, etc. :) Created attachment 17331 [details] [review] Bug 10019: Fix for userid containing UTF8 chars Decodes userid on two places in checkauth of C4/Auth.pm Test plan: Include some non-Latin characters in your userid (loginname). Arab, Chinese? Login into opac and check user page. Go to staff (no new login), check your login name at various places. Logout, login via staff. Do the same. Go to opac again (no new login), check user page. Optionally: Remove all your sessions from table. Do a login. Check sessions. Karam, Bernardo: Have a look too at bug 9951 where I describe in comment1 the problem with utf8 chars in your password.. That is a really nice one to solve :) Created attachment 17332 [details] [review] Bug 10019: Fix for userid containing UTF8 chars Decodes userid on two places in checkauth of C4/Auth.pm Test plan: Include some non-Latin characters in your userid (loginname). Arab, Chinese? Login into opac and check user page. Go to staff (no new login), check your login name at various places. Logout, login via staff. Do the same. Go to opac again (no new login), check user page. Optionally: Remove all your sessions from table. Do a login. Check sessions. Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> Comment: Works as described. No errors. This patch fixes this problem, but I wonder if there is a general solution that handle all as utf8. Tested in opac and staff. (In reply to comment #5) > This patch fixes this problem, but I wonder if > there is a general solution that handle all as utf8. > Tested in opac and staff. Thanks for your SO. A simpler solution for UTF-8 would be really welcome, but IMO we are now in a transition period. Currently, some scripts use CGI now with -utf8 flag for decoding all parameters. But we already have more modules like Auth.pm that have decodes here and there. The problem is fixed using this patch :) Thanks alot for your fast respond :) Taking the liberty to let this pass qa now too in connection with 6554 and the other encoding reports. Note that these small patches are actually qa followups for 6554. So not a real patch coming from me :) Passed QA This patch has been pushed to master and 3.12.x. Reverted. Closing this report. |