Versions Compared

Old Version 9

changes.mady.by.user Scott Cantor

Saved on

compared with

New Version 10

changes.mady.by.user Tom Zeller

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Shibboleth Developer's Meeting, May 24, 2013

Attendees:  Brent, Daniel, Ian, Marvin, Rod, Scott, Tom

Call Administrivia

Next call is next Friday.

60 to 90 minute call window.


 

Brent

Finishing up remaining TODOs in message processing code as well as java-shib-testbed.

As documented in Web Flow, when a flow reaches an end-state, if a view-state is not rendered the default behavior is to redirect to beginning of flow. Need to mark response as completed at end of flow, RequestContext.getExternalContext().recordResponseComplete().

 

Daniel

 

Ian

 

Marvin

 

Rod

  • Attribute Filtering.  After discussion with Tom, completed refactoring (unfortunately some may need unrefactoring)
  • Started on the the rest of the "Policy" type predicates.
  • Design note for AttributeInMetadata and AttributeInRequest under  construction.

...

Refactoring idp-attribute-filter-api, looks like a return to v2, with some differences. Not sure why v3 diverged originally, let us avoid design regressions.

Be deliberate when changing API artifacts. Special svn notifications ?

Continue to refactor "MatchFunctor" to "Matcher" and its evaluatePolicyRule(AttributeFilterContext) to matches(AttributeFilterContext).

Q : "What does a Matcher do?"
A : "A Matcher matches (an attribute filter context) and it gets matching values (for an attribute in the context)".

As mentioned in Javadoc, a base AbstractMatcher class could require concrete implementations to provide just getMatchingValues(), since a default matches() implementation could iterate over the Attributes in the AttributeFilterContext and return true the first time getMatchingValues() returns a non-empty set. Not optimal, of course.

So, MatchFunctor might exist in the schema only.

As mentioned on a previous dev call, for consistency, I thing "filtering" should be refactored to "filter" in Java class and package names, and the AttributeFilteringEngine should become AttributeFilter. To match the AttributeResolver maybe AttributeFilterer is more appropriate, but no.

Readlock on AttributeFilterService.filterAttributes() ?


Topics

 

Decisions

Coding convention : getLdapUrl or getLDAPURL ?

...