Commit graph

5 commits

Author SHA1 Message Date
9ea7fbcb30
Bug 25002: JS Includes should be wrapped with template comments
This patch adds HTML comments to Template::Toolkit include files which
contain <script> tags so that it is clear where the embedded scripts can
be found in the code.

To test, apply the patch and view source on the following pages to
verify the presence of the comments:

Acquisitions home page:
  - acquisitions-toolbar.inc
  - validtor-strings.inc
  - js_includes.inc
  - format-price.inc
Acquisitions -> Add order from new record,
Acquisitions -> Receive order:
  - additem.js.inc
Cataloging -> Add/Edit item:
  - columns_settings.inc
  - strings.inc
  - select2.inc
  - calendar.inc
  - str/cataloging_additem.inc
Authorities home page:
  - authorities_js.inc
Bibliographic detail page:
  - catalog-strings.inc
Cataloging -> Advanced editor:
  - cateditor-ui.inc
  - cateditor-widgets-marc21.inc
Administration -> Item types:
  - greybox.inc
ILL requests:
  - ill-list-table-strings.inc
Web installer
  - installer-intranet-bottom.inc
Web installer -> Onboarding
  - installer-strings.inc
Lists -> List contents -> Merge records
  - merge-record-strings.inc
Patrons -> Patron -> Change password
  - password_check.inc
  - str/members-menu.inc
Patrons -> Patron -> Print summary
  - slip-print.inc
Circulation -> Check out
  - timepicker.inc
Administration -> System preferences:
  - str/tinymce_i18n.inc
  - wysiwyg-systempreferences.inc
Cataloging -> Z39.50 Search:
  - z3950_search.inc

Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-04-29 17:15:20 +01:00
9c4f368622 Bug 22973: Remove type attribute from script tags: Staff client includes 2/2
This patch removes the "type" attribute from <script> tags in several
staff client include files. Also removed: Obsolete "//<![CDATA[ //]]>"
markers.

This patch also makes minor indentation changes, so diff using the "-w"
flag.

To test, apply the patch and confirm that examples of affected pages
work properly without any JavaScript errors in the browser console:

 - Installer -> Onboarding (uses installer-strings.inc,
   validator-strings.inc)
 - Patrons -> Patron details -> Change password (uses
   password_check.inc)
 - Patrons -> Patron details -> Print summary (slip-print.inc)
 - Circulation -> Check out (strings.inc, timepicker.inc)
 - Cataloging -> New from Z39.50/SRU (z3950_search.inc)

Validating the HTML source of any of these pages should return no errors
related to the "type" attribute.

Signed-off-by: Hayley Mapley <hayleymapley@catalyst.net.nz>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2019-05-30 10:25:21 +00:00
Jonathan Druart
dcd1f5d48c Bug 13618: Add html filters to all the variables
Here we go, next step then.
As we did not fix the performance issue when autofiltering
the variables (see bug 20975), the only solution we have is to add the
filters explicitely.

This patch has been autogenerated (using add_html_filters.pl, see next
pathces) and add the html filter to all the variables displayed in the
template.
Exceptions are made (using the new 'raw' TT filter) to the variable we
already listed in the previous versions of this patch.

To test:
- Use t/db_dependent/Koha/Patrons.t to populate your DB with autogenerated
data which contain <script> tags

- Remove them from borrower_debarments.comments (there are allowed here)
update  borrower_debarments set comment="html tags possible here";

- From the interface hit page and try to catch alert box.
If you find one it means you find a possible XSS.
To know where it comes from:
* note the exact URL where you found it
* note the alert box content
* Dump your DB and search for the string in the dump to identify its
location (for instance table.field)

Next:
* Ideally we would like to use the raw filter when it is not necessary
to HTML escape the variables (in big loop for instance)
* Provide a QA script to catch missing filters (we want html, uri, url
or raw, certainly others that I am forgetting now)
* Replace the html filters with uri when needed (!)

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

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2018-08-17 15:55:05 +00:00
e24e7ad7f1 Bug 19908: Do not use .optional in password match validation function
Test plan:
0) Aplly only first patch
1) You will be able to submit a from on member-password.pl even if the
passwords don't match
2) Apply this patch -> you can't be able to submit the form if the
paswords don't match, but you'll be able to submit the form when
password fields are blank

Signed-off-by: Roch D'Amour <roch.damour@inlibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2018-03-19 12:23:13 -03:00
7cc65af6ff Bug 18298: Use the validate jQuery plugin
To validate password fields we need to use the validate jQuery plugin.
To make things reusable this patch adds a new include file
'password_check.inc' at the intranet and opac sides, it creates 3 new
validation methods:
- password_strong => make sure the passwords are strong enough according
to the values of the RequireStrongPassword and minPasswordLength prefs
- password_no_spaces => prevent passwords to be entered with leading or
trailing spaces
- password_match => make sure both password fields match

Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2017-10-16 09:44:32 -03:00