This project is mirrored from git://git.koha-community.org/koha.git. Updated .
  1. 20 Apr, 2018 3 commits
  2. 27 Mar, 2018 5 commits
  3. 26 Mar, 2018 2 commits
  4. 23 Mar, 2018 5 commits
  5. 13 Feb, 2018 1 commit
  6. 12 Feb, 2018 5 commits
  7. 08 Feb, 2018 1 commit
  8. 11 Dec, 2017 1 commit
  9. 01 Nov, 2017 2 commits
    • Marcel de Rooy's avatar
      Bug 17989: Include full path logic in _get_template_file · 8c510e1a
      Marcel de Rooy authored
      Similar to the full path test in sub themelanguage, this patch makes a
      change in _get_template_file. This allows you to pass a template
      outside the modules directory to get_template_and_user. (Note: the sub
      badtemplatecheck already blocks bad paths.)
      
      Especially, this would be helpful for plugins using templates. As can be
      seen in Templates.pm, a change was made earlier to overwrite the filename
      for a plugin in sub gettemplate. This exception can now be removed.
      
      Also note the small change in Koha/Plugin/Base.pm; mbf_path is already
      absolute and if we pass a full path, we do not need it. This allows use of
      a regular Koha template or a shared template between plugins (as long as
      badtemplatecheck allows the path).
      
      What are the side-effects of this change?
      [1] We should not pass absolute paths if we mean relative ones.
          A follow-up patch deals with one occurrence in the codebase.
          No regressions for regular use.
      [2] Plugins can call get_template_and_user directly or go via get_template
          in Koha/Plugin/Base (absolute paths don't go via mbf_path).
      
      Note: replaced two single quotes in Auth.pm to show template name in test
      description.
      
      Test plan:
      [1] Open some page on OPAC or staff client to trigger a template.
      [2] Run t/db_dependent/Auth.t to verify not allowing some bad templates.
      [3] Run t/db_dependent/Templates.t to verify an absolute path.
      [4] Run t/db_dependent/Plugins.t to verify using templates in a plugin.
      Signed-off-by: 's avatarMarcel de Rooy <m.de.rooy@rijksmuseum.nl>
      Signed-off-by: Wm. Nick Clemens's avatarNick Clemens <nick@bywatersolutions.com>
      Signed-off-by: joubu's avatarJonathan Druart <jonathan.druart@bugs.koha-community.org>
      8c510e1a
    • Marcel de Rooy's avatar
      Bug 17989: Centralize bad template check · 411d0cf8
      Marcel de Rooy authored
      The bad template check in get_template_and_user can be removed, since
      this check has been added in gettemplate on bug 18010.
      
      The check moves here to a new sub in C4::Templates. And will be extended
      in a follow-up.
      
      Removed unused variable $path in gettemplatefile.
      
      Test plan:
      [1] Run t/db_dependent/Auth.t (get_template_and_user bad calls).
      [2] Run t/db_dependent/Templates.t (bad call to gettemplate).
      Signed-off-by: 's avatarMarcel de Rooy <m.de.rooy@rijksmuseum.nl>
      Signed-off-by: Wm. Nick Clemens's avatarNick Clemens <nick@bywatersolutions.com>
      Signed-off-by: joubu's avatarJonathan Druart <jonathan.druart@bugs.koha-community.org>
      411d0cf8
  10. 16 Oct, 2017 1 commit
  11. 14 Jul, 2017 2 commits
  12. 10 Jul, 2017 1 commit
  13. 05 Jul, 2017 2 commits
  14. 12 May, 2017 2 commits
    • joubu's avatar
    • joubu's avatar
      Bug 18314: Account lockout · cfc484b1
      joubu authored
      To prevent brute force attacks on Koha accounts, staff and opac, we need to
      implement an account lockout process to Koha.
      
      After a number of failed login attempts a users account would become locked.
      The user would then need to use the reset password functionality to send a reset
      token to their email account. After a successful password reset the lockout flag
      would be removed.
      
      The number of failed login attempts before lockout is configurable using a new
      system preference 'FailedLoginAttempts'.
      
      How does it work?
      When a patron enter an invalid password, the borrowers.login_attempts value
      for this patron is incremented. When this value reach the value of the
      pref FailedLoginAttempts, the password comparison is not done and the
      authentication is rejected.
      This login_attempts field is reset when a patron correctly logs in. When
      the account is locked the patron has to reset his/her password using
      the OpacResetPassword feature or ask a staff member to generate a new
      password.
      If the pref is not set (0, or '') the feature is considered as disabled,
      but the failed login attempts are stored anyway.
      
      Test plan:
      0/ Apply patch and execute the update DB entry
      1/ Switch on the feature by setting FailedLoginAttempts to 3
      2/ Use an invalid password to login at the staff or OPAC interface
      3/ After the third consecutive failures, you will be asked to reset your
      password if OpacResetPassword is set, or contact a staff member
      4/ Switch on OpacResetPassword and reset your password
      5/ Confirm that you are able to login
      6/ Play with the different combinations
      
      QA details: The trick happens in C4::Auth::checkpw, to make things clear
      I had to create a return value (note the awesome name: @return) and
      replace the 3 successives if statements with elsif. Indeed if one of
      the condition is reached, it will return inside the given block.
      Signed-off-by: Jonathan Field's avatarJonathan Field <jonathan.field@ptfs-europe.com>
      Signed-off-by: Wm. Nick Clemens's avatarNick Clemens <nick@bywatersolutions.com>
      Signed-off-by: 's avatarKyle M Hall <kyle@bywatersolutions.com>
      cfc484b1
  15. 08 May, 2017 2 commits
    • joubu's avatar
    • Alex Buckley's avatar
      Bug 18442: Fix DB user loggin · 416029ff
      Alex Buckley authored
      Test plan:
      1. Drop and recreate your db
      
      2. Clear memcached
      
      3. Go through the installer (to speed up this test plan install all
      sample data so you dont have to create libraries, patron categories etc. later)
      
      4. On the installer page login as the database user and notice that it
      does not work on the first attempt ( you get 'Error: You do not have
      permission to access this page')
      
      5. Try logging in as database user for a second time and notice you are
      logged in successfully this time
      
      4. In staff interface create a patron account with superlibrarian permissions
      
      5. Logout of the staff interface
      
      6. Login as database user
      
      7. Notice you cant log in. You get the 'Error:: You do not have permission to access this
      page' error
      
      8. Try a second attempt and notice you get the same error
      
      9. Open the URL in a new tab and notice the staff interface appears
      showing that you are logged in
      
      10. log out and log back in as the superlibrarian user you created and
      notice it works on first login attempt
      
      11. Apply patch
      
      12. Log out and try logging back in as database user and notice that you
      can login successfully on first attempt
      
      13. Repeat steps 1,2,3 and login as database user and notice the login
      works on first attempt
      Signed-off-by: joubu's avatarJonathan Druart <jonathan.druart@bugs.koha-community.org>
      Signed-off-by: Martin Renvoize's avatarMartin Renvoize <martin.renvoize@ptfs-europe.com>
      Signed-off-by: 's avatarKyle M Hall <kyle@bywatersolutions.com>
      416029ff
  16. 28 Apr, 2017 1 commit
    • Kyle M Hall's avatar
      Bug 12461 - Add patron clubs feature · 95429af6
      Kyle M Hall authored
      This features would add the ability to create clubs which patrons may be
      enrolled in. It would be particularly useful for tracking summer reading
      programs, book clubs and other such clubs.
      
      Test Plan:
      1) Apply this patch
      2) Run updatedatabase.pl
      3) Ensure your staff user has the new 'Patron clubs' permissions
      4) Under the tools menu, click the "Patron clubs" link
      5) Create a new club template
         * Here you can add fields that can be filled out at the time
           a new club is created based on the template, or a new enrollment
           is created for a given club based on the template.
      6) Create a new club based on that template
      7) Attempt to enroll a patron in that club
      8) Create a club with email required set
      9) Attempt to enroll a patron without an email address in that club
      10) Create a club that is enrollable from the OPAC
      11) Attempt to enroll a patron in that club
      12) Attempt to cancel a club enrollment from the OPAC
      13) Attempt to cancel a club enrollment from the staff interface
      
      Followed test plan, works as expected.
      Signed-off-by: 's avatarMarc Véron <veron@veron.ch>
      Signed-off-by: Wm. Nick Clemens's avatarNick Clemens <nick@bywatersolutions.com>
      Signed-off-by: 's avatarKyle M Hall <kyle@bywatersolutions.com>
      95429af6
  17. 21 Apr, 2017 3 commits
  18. 29 Mar, 2017 1 commit