Bug 14599 - Saved auth login and password are used in patron creation from
Summary: Saved auth login and password are used in patron creation from
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Fridolin Somers
QA Contact: Testopia
URL:
Keywords:
: 14236 14430 (view as bug list)
Depends on:
Blocks: 29025
  Show dependency treegraph
 
Reported: 2015-07-24 11:55 UTC by Fridolin Somers
Modified: 2021-09-15 05:14 UTC (History)
9 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Trivial patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 14599 - Saved auth login and password are used in patron creation from (1.79 KB, patch)
2015-11-23 08:26 UTC, Fridolin Somers
Details | Diff | Splinter Review
Bug 14599 - Saved auth login and password are used in patron creation from (1.84 KB, patch)
2015-11-24 20:20 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 14599 - Saved auth login and password are used in patron creation from (2.00 KB, patch)
2015-11-25 15:46 UTC, Jonathan Druart
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Fridolin Somers 2015-07-24 11:55:14 UTC
If one save the login and password used to authenticate in staff interface, when creating a new patron, those login and password are filled in the corresponding inputs in the form.
This behaviour is awkward from web browser.

How can it be disabled ?
Comment 1 Gaetan Boisson 2015-07-24 14:18:50 UTC
This seems like a revival of http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8080
Comment 2 Fridolin Somers 2015-08-21 09:46:31 UTC
When using private navigation in Firefox :
In loggin form the loggin is not filled-in automatically and the password is filled-in automatically after choosing a loggin.
Then in add patron form, the problem does not occurs.

Also, in normal navigation, it is the same behavior if I have more than one loggin registred.

The problem seems to be a Firefox behaviour, independently from "autocomplete=off".
Comment 3 Katrin Fischer 2015-11-21 21:52:16 UTC
I think this could be quite problematic and we should fix it:

To test:

- Log into Koha, allow the browser to save the password.
- Create a new patron.
- Verify that your saved password and username have been added to the form.
Comment 5 Katrin Fischer 2015-11-21 23:01:48 UTC
It seems like this is a known problem, but I haven't found a really good fix yet.

One way I found to 'fix' it is adding additional hidden input fields of the password type to the form. As the stackoverflow entry mentions, 3+ password fields on a page keep Firefox from filling them in.
Comment 6 Fridolin Somers 2015-11-23 08:17:59 UTC
I've found using a disabled input between loggin and password disables autocompletion
Comment 7 Fridolin Somers 2015-11-23 08:26:20 UTC Comment hidden (obsolete)
Comment 8 Nick Clemens 2015-11-24 20:20:55 UTC Comment hidden (obsolete)
Comment 9 Jonathan Druart 2015-11-25 15:46:23 UTC
Created attachment 45146 [details] [review]
Bug 14599 - Saved auth login and password are used in patron creation from

If one save the login and password used to authenticate in staff interface, when creating a new patron, those login and password are filled in the corresponding inputs in the form.
This behaviour is awkward from web browser.

A trick is provided by http://stackoverflow.com/questions/10738090/why-firefox-autocomplete-even-with-different-input-name

I found that the best way is to use an hidden disabled input between userid and password.

Test plan :

- Log into Koha
- Allow the browser to save the userid/password
- Be sure that you have only one userid/password for this Koha
- Loggout
- Re log to check the browser autocomplets the authentication form
- Create a new patron
=> Without patch your saved userid/password have been added to the form
=> With patch your saved userid/password have not been added to the form

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This is not elegant but it works.
Note that the problem does not exist with Chromium
Comment 10 Kyle M Hall 2015-12-11 15:31:56 UTC
Pushed to master! Thanks Frido!
Comment 11 Julian Maurice 2015-12-11 16:15:47 UTC
Patch pushed to 3.22.x, will be in 3.22.1
Comment 12 Frédéric Demians 2015-12-11 17:13:21 UTC
This patch has been pushed to 3.20.x, will be in 3.20.7.
Comment 13 Jonathan Druart 2016-01-07 14:00:29 UTC
*** Bug 14236 has been marked as a duplicate of this bug. ***
Comment 14 Marcel de Rooy 2016-04-07 09:40:15 UTC
*** Bug 14430 has been marked as a duplicate of this bug. ***