Commit graph

5 commits

Author SHA1 Message Date
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
3e91d99a15 Bug 20053: Drop type attribute "text/javascript" in OPAC templates
This patch is a reimplementation of the original from Indranil Das Gupta
and the QA follow-up from Julian Maurice. Original test plan:

Conformance rules for HTML5 is generating warnings for <script> element
with type="text/javascript" attribute when the OPAC page is checked
with W3C Validator. This patch removes the cause of these warnings.

Test plan
=========

1/ Paste the URL to your OPAC page (if it is hosted) to W3C Validator
   and watch about 10+ warnings being generated by the validator.

2/ Apply patch and re-submit the page to the Validator. The warnings
   would be gone.

Signed-off-by: Jon Knight <J.P.Knight@lboro.ac.uk>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2018-06-08 09:48:12 -04:00
Julian Maurice
ed7543287b Bug 20538: Remove the need of writing [% KOHA_VERSION %] everywhere
Having to write [% KOHA_VERSION %] for each url is bad because:
- It's easily forgettable when adding new <script> or <link>
- It prevents grep'ing for the full filename
- It violates the DRY principle
- If at some point we want to change the "force js and css reload"
  mechanism, it will be tedious

This patch:
- adds a Template::Toolkit plugin that generates <script> and
  <link> tags for JS and CSS files, and inserts automatically the Koha
  version in the filename
- use the new plugin to remove all occurences of [% KOHA_VERSION %]
- remove the code that was adding KOHA_VERSION as a template variable

Test plan:
1. Apply patch
2. Go to several different pages in Koha (opac and intranet) while
   checking your browser's dev tools (there should be no 404 for JS and
   CSS files, and the Koha version should appear in filenames) and the
   server logs (there should be no "File not found")
3. `git grep KOHA_VERSION` should return nothing
4. prove t/db_dependent/Koha/Template/Plugin/Asset.t

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

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

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2018-04-13 11:49:44 -03:00
0ad922011c Bug 12904: Force browser to load new javascript files after upgrade
This patch has been automatically generated using:
  perl kv.pl **/*.tt **/*.inc

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
2018-02-08 14:53:24 -03:00
eb92d94be1 Bug 10309 - New OPAC theme based on Bootstrap
The goal of this theme is to provide a fully-responsive OPAC which
offers a high level of functionality across multiple devices with varied
viewport sizes. Its style is based on the CCSR theme, with elements of
the Bootstrap framework providing default styling of buttons, menus,
modals, etc.

The Bootstrap grid is used everywhere, but Bootstrap's default
responsive breakpoints have been expanded to allow for better
flexibility for our needs.

All non-translation-depended files are in the root directory of this new
theme:

css, images, itemtypeimg, js, less, and lib. Languages.pm has been
modified to ignore the new directories when parsing the theme language
directories.

This theme introduces the use of LESS (http://lesscss.org/) to build
CSS. Three LESS files can be found in the "less" directory: mixins.less,
opac.less, and responsive.less. These three files are compiled into one
CSS file for production: opac.css. "Base" theme styles are found in
opac.less. A few "mixins" (http://lesscss.org/#-mixins) are found in
mixins.less. Any CSS which is conditional on specific media queries is
found in responsive.less.

At the template level some general sturctural changes have been made.
For the most part JavaScript is now at the end of each template as is
recommended for performance reasons. JavaScript formerly in
doc-head-close.inc is now in opac-bottom.inc.

In order to be able to maintain this structure and accommodate
page-specific scripts at the same time the use of BLOCK and PROCESS are
added. By default opac-bottom.inc will PROCESS a "jsinclude" block:

[% PROCESS jsinclude %]

Each page template in the theme must contain this block, even if it is
empty:

[% BLOCK jsinclude %][% END %]

Pages which require that page-specific JavaScript be inserted can add it
to the jsinclude block and it will appear correctly at the bottom of the
rendered page.

The same is true for page-specific CSS. Each page contains a cssinclude
block:

[% BLOCK cssinclude %][% END %]

...which is processed in doc-head-close.inc:

[% PROCESS cssinclude %]

Using these methods helps us maintain a strict separation of CSS links
and blocks (at the top of each page) and JavaScript (at the bottom). A
few exceptions are made for some JavaScript which must be processed
sooner: respond.js (https://github.com/scottjehl/Respond, conditionally
applied to Internet Explorer versions < 9 to allow for layout
responsiveness), the _() function required for JS translatability, and
Modernizr (http://modernizr.com/, a script which detects browser
features and allows us to conditionally load JavaScript based on
available features--or lack thereof).

Another new JavaScript dependency in this theme is enquire.js
(http://wicky.nillia.ms/enquire.js/), which lets us trigger JavaScript
events based on viewport size.

I have made an effort to re-indent the templates in a sane way,
eliminating trailing spaces and tabs. However, I have not wrapped lines
at a specific line length. In order to improve template legibility I
have also tried to insert comments indicating the origin of closing tags
like <div> or template directives like [% END %]:

</div> <!-- / .container-fluid -->

[% END # / IF ( OpacBrowseResults && busc ) %]

TESTING

Proper testing of this theme is no easy task: Every template has been
touched. Each page should work reasonable well at a variety of screen
dimensions. Pages should be tested under many conditions which are
controlled by toggling OPAC system preferences on and off. A variety of
devices, platforms, and browsers should be tested.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2013-10-14 23:13:05 +00:00