/
2020-09-04

2020-09-04

Jul 29, 2021

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

  • OSJ-323 - Getting issue details... STATUS

    • Provisional fix committed.  Reporter says seems to fix his issue.  Need to do a little more testing before closing out.

 

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.

    • Added the Version class and Manifest stuff, but can not get it to work. Will ask Rod. 

  • 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.

    • 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


Other