Bug 21096

Summary: Garbled username on intranet login page
Product: Koha Reporter: Lauski Mori <lauskixmori666>
Component: PatronsAssignee: Jonathan Druart <jonathan.druart>
Status: CLOSED FIXED QA Contact: Testopia <testopia>
Severity: normal    
Priority: P5 - low CC: fridolin.somers, gmcharlt, jonathan.druart, katrin.fischer, kyle.m.hall, martin.renvoize, nick
Version: Main   
Hardware: All   
OS: All   
Change sponsored?: --- Patch complexity: Small patch
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Bug Depends on: 18403    
Bug Blocks:    
Attachments: The attached picture of garbled username on koha intranet page.
Bug 21096: Do not display loggedinusername in template
Bug 21096: Do not display loggedinusername in template
Bug 21096: Do not display loggedinusername in template
Bug 21096: Do not display loggedinusername in template

Description Lauski Mori 2018-07-20 04:18:59 UTC
Created attachment 77149 [details]
The attached picture of garbled username on koha intranet page.

Hello,
I recently found that one could create a new account(one that could access intranet page as well as opac page) with using Mandarin for username. Although username shown on opac page was fine, username shown somehow came into garbled as long as moving forward to other features or setting on intranet page.
Comment 1 Owen Leonard 2018-07-23 12:16:39 UTC
For what it's worth, I didn't find this to be a problem in master, testing with Firefox and Chrome on Windows 10. I copied and pasted characters from this page for testing: http://carlgene.com/blog/2012/02/45-mandarin-sentences-with-chinese-characteristics/
Comment 2 Jonathan Druart 2018-07-23 15:09:21 UTC
You should paste here the values of surname and firstname you have set for this user.
Comment 3 Jonathan Druart 2018-07-23 15:17:41 UTC
(In reply to Jonathan Druart from comment #2)
> You should paste here the values of surname and firstname you have set for
> this user.

And the userid (it is the one displayed on the intranet side actually)
Comment 4 Lauski Mori 2018-07-24 03:50:57 UTC
(In reply to Jonathan Druart from comment #3)
> (In reply to Jonathan Druart from comment #2)
> > You should paste here the values of surname and firstname you have set for
> > this user.
> 
> And the userid (it is the one displayed on the intranet side actually)

Hello, Jonathan Druart!
I set the same value for surname and firstname: they were 月 and 月, which were Traditional Chinese Characters.
Comment 5 Lauski Mori 2018-07-25 08:41:09 UTC
(In reply to Lauski Mori from comment #4)
> (In reply to Jonathan Druart from comment #3)
> > (In reply to Jonathan Druart from comment #2)
> > > You should paste here the values of surname and firstname you have set for
> > > this user.
> > 
> > And the userid (it is the one displayed on the intranet side actually)
> 
> Hello, Jonathan Druart!
> I set the same value for surname and firstname: they were 月 and 月, which
> were Traditional Chinese Characters.

Also the userid was 月月 as a full name for surname and firstname.
Comment 6 Jonathan Druart 2018-07-25 14:42:22 UTC
Confirmed on master. It appends on second click (no when just logged in).
Comment 7 Jonathan Druart 2018-07-25 16:05:57 UTC
Created attachment 77270 [details] [review]
Bug 21096: Do not display loggedinusername in template

This patch is a little fix for a much bigger hidden issues.

The original issue:
1. Set the firstname and surname values of a paontr to utf-8 characters
("wide characters"), for instance 月月
2. Use this patron to login at the staff interface
=> In the header the logged in patron's info (concat of firstname and
surname) are displayed correctly
3. Hit whatever link
=> In the header the info are now displayed incorrectly
("ææ")

What happens?
After that the user loggin, loggedinusername is set with the value from
the DB (borrowers.userid)
On next hits it is picked from the session (which contains the decoded
utf8 value, see first lines of C4::Context->set_userenv)
From C4::Auth::checkauth:
834             $s_userid = $session->param('id') // ''

The quick fix is to use the logged_in_user variable in the template, but
it seems that issues may occurred if external authentication is used
(ldap, shib, cas). Could someone test this?

Test plan:
Make sure the original issue is fixed
Comment 8 Owen Leonard 2018-07-25 16:19:12 UTC
Created attachment 77271 [details] [review]
Bug 21096: Do not display loggedinusername in template

This patch is a little fix for a much bigger hidden issues.

The original issue:
1. Set the firstname and surname values of a paontr to utf-8 characters
("wide characters"), for instance 月月
2. Use this patron to login at the staff interface
=> In the header the logged in patron's info (concat of firstname and
surname) are displayed correctly
3. Hit whatever link
=> In the header the info are now displayed incorrectly
("ææ")

What happens?
After that the user loggin, loggedinusername is set with the value from
the DB (borrowers.userid)
On next hits it is picked from the session (which contains the decoded
utf8 value, see first lines of C4::Context->set_userenv)
From C4::Auth::checkauth:
834             $s_userid = $session->param('id') // ''

The quick fix is to use the logged_in_user variable in the template, but
it seems that issues may occurred if external authentication is used
(ldap, shib, cas). Could someone test this?

Test plan:
Make sure the original issue is fixed

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Comment 9 Jonathan Druart 2018-07-26 17:30:17 UTC
Note for QA: 

 254                 # A bit of a hack, but I don't know there's a nicer way
 255                 # to do it.
 256                 $user = $patron->firstname . ' ' . $patron->surname;

Is this still valid? If yes, the patch is not enough.
Comment 10 Katrin Fischer 2018-08-01 22:26:44 UTC
Created attachment 77415 [details] [review]
Bug 21096: Do not display loggedinusername in template

This patch is a little fix for a much bigger hidden issues.

The original issue:
1. Set the firstname and surname values of a paontr to utf-8 characters
("wide characters"), for instance 月月
2. Use this patron to login at the staff interface
=> In the header the logged in patron's info (concat of firstname and
surname) are displayed correctly
3. Hit whatever link
=> In the header the info are now displayed incorrectly
("ææ")

What happens?
After that the user loggin, loggedinusername is set with the value from
the DB (borrowers.userid)
On next hits it is picked from the session (which contains the decoded
utf8 value, see first lines of C4::Context->set_userenv)
From C4::Auth::checkauth:
834             $s_userid = $session->param('id') // ''

The quick fix is to use the logged_in_user variable in the template, but
it seems that issues may occurred if external authentication is used
(ldap, shib, cas). Could someone test this?

Test plan:
Make sure the original issue is fixed

Signed-off-by: Owen Leonard <oleonard@myacpl.org>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 11 Nick Clemens 2018-08-22 11:46:10 UTC
(In reply to Jonathan Druart from comment #9)
> Note for QA: 
> 
>  254                 # A bit of a hack, but I don't know there's a nicer way
>  255                 # to do it.
>  256                 $user = $patron->firstname . ' ' . $patron->surname;
> 
> Is this still valid? If yes, the patch is not enough.

I cannot trigger this code, I think this patch should be good for now.

Can you rebase?
Comment 12 Jonathan Druart 2018-08-29 19:09:12 UTC
Created attachment 78286 [details] [review]
Bug 21096: Do not display loggedinusername in template

This patch is a little fix for a much bigger hidden issues.

The original issue:
1. Set the firstname and surname values of a paontr to utf-8 characters
("wide characters"), for instance 月月
2. Use this patron to login at the staff interface
=> In the header the logged in patron's info (concat of firstname and
surname) are displayed correctly
3. Hit whatever link
=> In the header the info are now displayed incorrectly
("ææ")

What happens?
After that the user loggin, loggedinusername is set with the value from
the DB (borrowers.userid)
On next hits it is picked from the session (which contains the decoded
utf8 value, see first lines of C4::Context->set_userenv)
From C4::Auth::checkauth:
834             $s_userid = $session->param('id') // ''

The quick fix is to use the logged_in_user variable in the template, but
it seems that issues may occurred if external authentication is used
(ldap, shib, cas). Could someone test this?

Test plan:
Make sure the original issue is fixed

Signed-off-by: Owen Leonard <oleonard@myacpl.org>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 13 Nick Clemens 2018-08-30 14:10:42 UTC
Awesome work all!

Pushed to master for 18.11
Comment 14 Martin Renvoize 2018-09-05 09:57:48 UTC
Pushed to 18.05.x for 18.05.04
Comment 15 Fridolin Somers 2018-09-24 09:16:23 UTC
Depends on Bug 18403 not in 17.11.x