Bug 20402 implements an Oauth2 server for the client credentials grant. It should be awesome if the patron management interface in Koha provided a way for staff members (and maybe for patron users later) to create and revoke API keys. The work is actually done already, by Julian in the first commit for bug 13920. So we need to recover that patch, adapt it to our coding guidelines and make it work on top of bug 20402!
Looking forward to this. I've wanted this for a while.
Created attachment 74179 [details] [review] Bug 20568: API keys management in interface 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
Created attachment 74180 [details] [review] Bug 20568: Add mandatory description field for api keys This patch changes the table structure adding fields usually found on this kind of api management pages.
I've attached my WIP stuff just in case anyone wants to comment on that. I basically resurrected one patch from Julian from bug 13920 (API keys management in interface) and worked on adapting it to current practices. The staff interface api management page is fully functional. OPAC is next. Unit tests almost ready, not submitted.
Created attachment 74229 [details] [review] Bug 20568: API keys management in interface 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
Created attachment 74230 [details] [review] Bug 20568: Add mandatory description field for api keys This patch changes the table structure adding fields usually found on this kind of api management pages.
Created attachment 74231 [details] [review] Bug 20568: Unit tests This patch adds unit tests for the introduced classes: Koha::ApiKey(s). To test: - Apply this patch - Run $ kshell k$ prove t/db_dependent/Koha/ApiKeys.t => FAIL: Tests fail because the feature is not implemented.
Created attachment 74232 [details] [review] Bug 20568: API key management for OPAC users 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
Created attachment 74233 [details] [review] Bug 20568: API keys management in interface 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
Created attachment 74234 [details] [review] Bug 20568: Add mandatory description field for api keys This patch changes the table structure adding fields usually found on this kind of api management pages.
Created attachment 74235 [details] [review] Bug 20568: Unit tests This patch adds unit tests for the introduced classes: Koha::ApiKey(s). To test: - Apply this patch - Run $ kshell k$ prove t/db_dependent/Koha/ApiKeys.t => FAIL: Tests fail because the feature is not implemented.
Created attachment 74236 [details] [review] Bug 20568: API key management for OPAC users 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
Created attachment 74248 [details] [review] Bug 20568 (follow-up) Interface and markup changes 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.
Created attachment 74254 [details] [review] Bug 20568: API keys management in interface 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
Created attachment 74255 [details] [review] Bug 20568: Add mandatory description field for api keys This patch changes the table structure adding fields usually found on this kind of api management pages.
Created attachment 74256 [details] [review] Bug 20568: Unit tests This patch adds unit tests for the introduced classes: Koha::ApiKey(s). To test: - Apply this patch - Run $ kshell k$ prove t/db_dependent/Koha/ApiKeys.t => FAIL: Tests fail because the feature is not implemented.
Created attachment 74257 [details] [review] Bug 20568: API key management for OPAC users 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
Created attachment 74258 [details] [review] Bug 20568 (follow-up) Interface and markup changes 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>
Created attachment 74259 [details] [review] Bug 20568: Move value => client_id + secret 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.
Created attachment 74343 [details] [review] Bug 20568: API keys management in interface 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>
Created attachment 74344 [details] [review] Bug 20568: Add mandatory description field for api keys 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>
Created attachment 74345 [details] [review] Bug 20568: Unit tests This patch adds unit tests for the introduced classes: Koha::ApiKey(s). To test: - Apply this patch - Run $ kshell k$ prove t/db_dependent/Koha/ApiKeys.t => FAIL: Tests fail because the feature is not implemented. Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 74346 [details] [review] Bug 20568: API key management for OPAC users 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>
Created attachment 74347 [details] [review] Bug 20568 (follow-up) Interface and markup changes 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>
Created attachment 74348 [details] [review] Bug 20568: Move value => client_id + secret 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>
Created attachment 74388 [details] [review] Bug 20568: (follow-up) Interface and markup changes 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>
Created attachment 74389 [details] [review] Bug 20568: Move value => client_id + secret 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>
Created attachment 74434 [details] [review] Bug 20568: (follow-up) Atomic update fix Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 74454 [details] [review] Bug 20568: (follow-up) Atomic update fix Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
QA comments: 1) The UUID generation happens in the store method. This means that every time I revoke/activate a key, client_id and secret are changed. I think that is not the desired behaviour. 2) A CSRF attack can remove and revoke keys. This can be prevented by using Koha::Token. 3) UUID::generate($uuid); UUID::unparse( $uuid, $uuidstring ); can be replaced by $uuidstring = uuid(); 4) In intranet, if I have no key and click twice on "Generate a new client id/secret pair" link, the form appear then disappear. Not really a problem, but it's an odd behaviour. I suggest to just show the button even if I have no keys, like in OPAC. 5) I feel that api_keys.id is not useful as client_id can be used as a primary key 6) Since we're using UUID, why not store the binary representation instead of the string representation ? I don't know how that would affect performance but that will save storage space. If we stick with the string representation I suggest that we change the data type of client_id and secret to a fixed-width string type (CHAR(36) ?) Failing QA for 1 and 2. 3 and 4 are not required but they should be easy to do. 5 and 6 are just thoughts. Please comment.
Created attachment 74476 [details] [review] Bug 20568: (QA follow-up) Test client_id and secret are not overwritten Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 74477 [details] [review] Bug 20568: (QA follow-up) Make sure client_id and secret are not overwritten on store Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 74478 [details] [review] Bug 29568: (QA follow-up) Get rid of the id column Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 74479 [details] [review] Bug 20568: (QA follow-up) Get rid of the id column Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 74480 [details] [review] Bug 20568: (QA follow-up) Get rid of the id column Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 74481 [details] [review] Bug 20568: CSRF protection Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(In reply to Julian Maurice from comment #30) > QA comments: > > 1) The UUID generation happens in the store method. This means that every > time I revoke/activate a key, client_id and secret are changed. I think that > is not the desired behaviour. Done. I provided both regression tests for this situation and the fix. > 2) A CSRF attack can remove and revoke keys. This can be prevented by using > Koha::Token. Done. Good catch :-D > 3) UUID::generate($uuid); UUID::unparse( $uuid, $uuidstring ); can be > replaced by $uuidstring = uuid(); I've had issues with Jessie's version of UUID (0.05). I get: Error: "uuid" is not exported buy the UUID module > 4) In intranet, if I have no key and click twice on "Generate a new client > id/secret pair" link, the form appear then disappear. Not really a problem, > but it's an odd behaviour. I suggest to just show the button even if I have > no keys, like in OPAC. Right, I will think about it. Maybe Owen can answer about this. > 5) I feel that api_keys.id is not useful as client_id can be used as a > primary key You are right! Removed! > 6) Since we're using UUID, why not store the binary representation instead > of the string representation ? I don't know how that would affect > performance but that will save storage space. If we stick with the string > representation I suggest that we change the data type of client_id and > secret to a fixed-width string type (CHAR(36) ?) I don't think this is necessary. For this client_id/secret pairs as are not expected be be many. Also, VARCHAR only takes as much space as the size of the content.
Created attachment 74482 [details] [review] Bug 20568: CSRF protection Edit: fix warning introduced by this patch Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 74486 [details] [review] Bug 20568: API keys management in interface 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>
Created attachment 74487 [details] [review] Bug 20568: Add mandatory description field for api keys 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>
Created attachment 74488 [details] [review] Bug 20568: Unit tests This patch adds unit tests for the introduced classes: Koha::ApiKey(s). To test: - Apply this patch - Run $ kshell k$ prove t/db_dependent/Koha/ApiKeys.t => FAIL: Tests fail because the feature is not implemented. Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Created attachment 74489 [details] [review] Bug 20568: API key management for OPAC users 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>
Created attachment 74490 [details] [review] Bug 20568: (follow-up) Interface and markup changes 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>
Created attachment 74491 [details] [review] Bug 20568: Move value => client_id + secret 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>
Created attachment 74492 [details] [review] Bug 20568: (follow-up) Atomic update fix Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Created attachment 74493 [details] [review] Bug 20568: (QA follow-up) Test client_id and secret are not overwritten Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Created attachment 74494 [details] [review] Bug 20568: (QA follow-up) Make sure client_id and secret are not overwritten on store Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Created attachment 74495 [details] [review] Bug 20568: (QA follow-up) Get rid of the id column Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Created attachment 74496 [details] [review] Bug 20568: CSRF protection 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>
Created attachment 74980 [details] [review] Bug 20568: (QA follow-up) Remove api-key management from OPAC Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 74981 [details] [review] Bug 20568: (QA follow-up) Remove api-key management from OPAC Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 75023 [details] [review] Bug 20568: (QA follow-up) Remove unused vars Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 75186 [details] [review] Bug 20568: (follow-up) API keys management in interface Fix bad resolution conflict.
Created attachment 75187 [details] [review] Bug 20568: fix shebang
Created attachment 75188 [details] [review] Bug 20568: Fix bad resolution conflict with bug 18403 borrowers module permission has now several subpermissions
Pushed to master for 18.05, thanks to everybody involved!