Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

Shibboleth Developer's Meeting, 2020-09-04

Call Administrivia

09:00 Central US / 10:00 Eastern US / 15:00 UK / 17:00 FI

Calls are normally the 1st and 3rd Fridays of each month. Next call would be Friday 2020-09-18. Any reason to deviate from this?

60 to 90 minute call window.


Call Details

This week's call will use the Zoom system at GU, see ZoomGU for access info.


AGENDA

  1. Package sealing?

Attendees:


Brent


Daniel


Henri

  • JOIDC-5 - Getting issue details... STATUS
    • Digesting the comments from Ian and Scott
    • XML schema: sequence vs choice

Ian


John


Marvin


Phil

  • Updated the archetype inline with the 'current' plugin guidance (git@git.shibboleth.net:philsmart/java-idp-plugin-archetype).
  • Tried out the plugin installer for my plugin (some logging suggestions IDP-1672 - Getting issue details... STATUS )
  • Various Duo plugin fixes.
    • I will probably add some tickets highlighting a few areas for general review next week.
  • Are we OK with adding detectHandlerMethodsInAncestorContexts="true" to the RequestMappingHandlerMapping in mvc-beans.xml? so my controller is picked up in the postconfig.xml file.


Rod

  • IDP-1595 - Getting issue details... STATUS  
    • Functionally complete
    • Bug fixing now (including the worrying  IDP-1663 - Getting issue details... STATUS )
    • Will swap in the module stuff and work on integrating it into the scripting  plugins and the installer.
  • IDP-1666 - Getting issue details... STATUS


Scott

  • SSPCPP-904 - Getting issue details... STATUS
  • IDP-1671 - Getting issue details... STATUS
    • No longer need to teach it about new property files, we will auto-load anything under conf with that suffix.
  • IDP-1664 - Getting issue details... STATUS
    • An IdPModule is a unit of function that can be individually enabled or disabled via command line.
    • Plugins can expose any number of IdPModules after installation, and could auto-enable them.
    • Generally this just involves managing a set of configuration resources by either copying them in or removing them (usually be saving them off, not deletion, but this will be controllable). Resources can be tagged as replace or noreplace, RPM-style.
    • Most modules should be expressible with property files and a trivial subclass to add to the Java services file.
    • Repeated enable/disable will be idempotent.
    • "Disabled" modules may not be totally "off" but probably will operate with default, often unusable, settings.
    • Many default config files (esp. for various subflows) will be removed or hidden in 4.1 behind disabled modules.
    • Upgrades will act as though many modules are already enabled, and disabling them can be used to remove the files.

Tom

  •  working on using headless Chrome/Firefox rather than HtmlUnit as part of testing consent
    IDP-1660 - Getting issue details... STATUS
    IDP-1632 - Getting issue details... STATUS

Other





  • No labels