[Koha-bugs] [Bug 17855] Updated Koha web installer and new onboarding tool feature to guide users through setting up Koha

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Wed Jan 18 05:27:33 CET 2017


https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17855

--- Comment #95 from Alex Buckley <alexbuckley at catalyst.net.nz> ---
(In reply to Owen Leonard in comment 92 and M.Tompsett in comment 94)

Apologies if it sounded dictatorial that is certainly never my intent. I was
thinking that special characters should not be permitted due to the security
implications of the user being able to input code into these input fields.

Regarding the server-side validation of entered cardnumbers in memberentry.pl
if the user entered the form with a blank cardnumber field then the cardnumber
is treated as null, as the below code shows:

298     # If the cardnumber is blank, treat it as null.
299     $newdata{'cardnumber'} = undef if $newdata{'cardnumber'} =~ /^\s*$/;

Then if there is an error from the checkcardnumber function the error is handed
to the @errors array, which I have already implemented in my bug. 


In the template memberentrygen.tt the html inputs value attribute has a '|
html' in it (e.g. <input name="cardnumber" value="cardnumber | html">, as I
understand it this stops any special characters entered into the input field
from being executed as code. Therefore I will implement this in the cardnumber
field and remove the html regex so that the same level of data validation in
the staff interface and onboarding tool exists. 

I personally do not believe we have been lax in our data validation, for the
following reason:
All text input fields have had html regexs on them in the onboarding tool from
the start, to prevent users from inputting special characters to fields.

-- 
You are receiving this mail because:
You are watching all bug changes.


More information about the Koha-bugs mailing list