This patch makes two corrections to the patron API key template: Convert
to Bootstrap grid and correct class on "new key" button.
To test, apply the patch and enable the RESTOAuth2ClientCredentials
preference.
- Open a patron record in the staff client and choose More -> Manage
API keys.
- On the API keys page, confirm that the page adjusts well at various
page widths.
- Confirm that the size of the "Generate new client id/key pair" button
matches the buttons in the toolbar.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
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>
Code and variables to deal with the update child feature are not
centralized but copied/pasted in several scripts. Which leads to issues
obsviously (bug 20805 for instance).
Moreover the strings used by the templates are also in several template
files (or .inc)
To deal with that this patch introduces the idea to create 1 .inc file
per .js file
Here we have members-menu.inc for members-menu.js
Test plan:
- Remove all your adult categories (categories.category_type='A')
- Create a patron with a child category
- Try to update to adult category
=> The entry does no longer appears! (This is a change in the behaviour)
- Create one adult category
- Update to adult category
=> There is a JS confirmation message, if you accept the patron will
be updated to the adult category
- Create (at least) another adult category
- Create another child
- Update to adult category
=> No more confirmation message but a popup to select the adult category
- Pick one
=> The patron has been updated to the adult category
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch adds a required JS asset to the patron API key interface.
Without it, JS-based functions in the toolbar do not work.
To test you must have RESTOAuth2ClientCredentials enabled.
- From a patron detail page, choose More -> Manage API keys.
- Test the toolbar buttons on this page, especially "Search to hold"
and the various print options.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Edit: fix warning introduced by this patch
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch addresses the request from Julian that api keys are expected
to be client id/secret pairs.
It does so by
- Adding 'client_id' and 'secret' columns
- Removing 'value'
Tests got adjusted and so controller scripts and templates.
Both libs and tests changes have been squashed. This ones remain in
order to keep Owen's attribution on the template changes and avoid
rebase conflicts.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch makes some interface changes to bring things better in line
with existing interface patterns. This patch also re-indents the
modified templates with 4 spaces instead of 2 and makes <input>s
self-closing.
Also changed: Corrected system preference check in opac-apikeys.pl.
To test, apply the patch and:
In the staff client:
- Open a patron record and choose More -> Manage API keys.
- There should be a standard message dialog containing a link to
"Generate a new key."
- Clicking the link should show the form for adding a new key.
- Test that clicking the "Cancel" link hides the form.
- Test that creating the new key works correctly.
- You should now see a table showing existing keys and a "Generate a
new key" button above it.
- Test that the "Delete" button asks for confirmation, and that
confirming and denying both work correctly.
- Test that "Revoke" and "Activate" actions still work correctly.
In the OPAC:
- Set the AllowPatronsManageAPIKeysInOPAC system preference to "Allow."
- Log in to the OPAC and click the "your API keys" link in the sidebar.
- Clicking the "Generate new key" button should display the form for
adding a new key.
- Clicking the "cancel" link should hide the form.
- Submitting the form should add a new key.
- You should now see a table showing existing keys.
- Test that the "Delete" link asks for confirmation, and that
confirming and denying both work correctly.
- Test that "Revoke" and "Activate" actions still work correctly.
- Set the AllowPatronsManageAPIKeysInOPAC system preference to "Don't
allow."
- Log in to the OPAC and confirm that the "your API keys" link in the
sidebar is no longer visible.
- Confirm that navigating directly to /cgi-bin/koha/opac-apikeys.pl
results in a 404 error.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch makes the OPAC interface for API keys management work
with the new lib. Verify all actions work for a logged user.
Users without login should be redirected to an error page.
The AllowPatronsManageAPIKeysInOPAC syspref is added to control if the
OPAC feature is enabled or not.
To test:
- Verify the syspref works
- Verify users can manage their API keys
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch changes the table structure adding fields usually found on
this kind of api management pages.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This introduces the concept of API keys for use in the new REST API.
A key is a string of 32 alphanumerical characters (32 is purely
arbitrary, it can be changed easily).
A user can have multiple keys (unlimited at the moment)
Keys can be generated automatically, and then we have the possibility to
delete or revoke each one individually.
Test plan:
1/ Go to staff interface
2/ Go to a borrower page
3/ In toolbar, click on More -> Manage API keys
4/ Click on "Generate new key" multiple times, check that they are
correctly displayed under the button, and they are active by default
5/ Revoke some keys, check that they are not active anymore
6/ Delete some keys, check that they disappear from table
7/ Go to opac interface, log in
8/ In your user account pages, you now have a new tab to the left "your
API keys". Click on it.
9/ Repeat steps 4-6
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
