Skip to content
Snippets Groups Projects
  1. Feb 03, 2019
  2. Dec 10, 2018
  3. Dec 03, 2018
  4. Nov 20, 2018
  5. Oct 17, 2018
  6. Oct 08, 2018
    • Jaime Pérez Crespo's avatar
      Initial version of routing, requests and responses. · 2ae9f3b1
      Jaime Pérez Crespo authored
      This introduces the following:
      
      - The use of Request objects to handle request data to controllers.
      - The use of Response objects to model responses that should be sent to the browser.
      - The use of "controllers" that are responsible for translating a request into a response.
      - The possibility to define your own URLs on each module by specifying them, together with their controllers, in a "routes.yaml" file in the root of a module.
      - The new UI is completely separated from the old, so "usenewui" must be set to "true" in the configuration.
      - Twigified templates are not used unless we're using the new UI, or the twig template is part of a theme.
  7. Aug 22, 2018
  8. Aug 13, 2018
  9. Jun 01, 2018
  10. May 31, 2018
  11. Nov 22, 2017
  12. Oct 25, 2017
  13. Oct 19, 2017
  14. Jul 04, 2017
    • Jaime Pérez Crespo's avatar
      Further optimize the SimpleSAML\Module class. · 7b3a5c0d
      Jaime Pérez Crespo authored
      Instead of one cache, we need to use two: one for the list of modules available, and the other for the details for them. Those caches should be filled independently, so that someone calling getModules() does not trigger the code checking of the modules are enabled or finding their hooks.
  15. Jun 30, 2017
    • Jaime Pérez Crespo's avatar
      Enhance the performance of SimpleSAML\Module. · 4e68df80
      Jaime Pérez Crespo authored
      The issue here is that every time we need to list the modules or check if they are enabled, we just iterate over the modules directory and subdirectories, which is terribly expensive. Instead of doing so, we build a cache of modules specifying if they are enabled or not. In the end, this is also fixing another issue, given that enabling/disabling a module in the middle of a request being processed could lead to inconsistencies and unexpected behaviour (likely exceptions and horrible crashes). Modules should be checked in the beginning of a request and their state (enabled/disabled) frozen until the request is processed to avoid that, and this is the way to achieve so.
      
      Additionally, we take the chance to check if modules are enabled when we search for them. This reduces the processing time to around a third of the original without this fix.
  16. Mar 09, 2016
  17. Feb 22, 2016
  18. Feb 19, 2016
  19. Aug 05, 2015
  20. May 26, 2015
    • Olav Morken's avatar
      Ensure that config.php is optional for module loading. · 0fc3f8a7
      Olav Morken authored
      Currently, if we try to load a class from a module, and the config.php
      is absent, we will get an error about the missing configuration file.
      
      There is no reason for the configuration file to be mandatory here,
      since we have reasonable fallbacks, so fix the code to make it
      optional.
      
      This should make it easier to write tests for code in modules.
      0fc3f8a7
  21. Apr 21, 2015
  22. Jan 15, 2015
  23. Jul 09, 2014
  24. Jan 09, 2013
  25. Apr 12, 2012
  26. Nov 26, 2010
  27. Jul 09, 2010
  28. Dec 16, 2009
  29. Sep 01, 2008
  30. Aug 20, 2008
  31. Aug 18, 2008
Loading