Uploaded image for project: 'Identity Provider'
  1. Identity Provider
  2. IDP-1472

Single Quotes in Attribute Names.



    • Type: Task
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 4.0.0
    • Fix Version/s: 4.0.0
    • Component/s: Attribute Resolver
    • Labels:


      This started as a side comment in IDP-1351 but it (of course) gets grubbier than that.

      The intial idea is to deprecate the use of single quotes in Attribute names.  My first question whether that is enough and whether we need to consider double quotes , the percent sign and curly brackets.

      I had initially thought that it would probably be safe to make this a constraint but I can certainly see that there may be attributes flowing from data connectors from badly created data stores (example: "User's name") so I think we need to warn in V4.

      Regardless I was shocked when I went into the V3 source and discovered that the check wasn't in IdPAttribute (which is where there is a constraint in V4).  This is because V3 is a different world and Attribute names only have any importance once they issue from AttributeResolvers.  So the warning is on the attribute definition - which is the correct place.  Attribute which occur with spaces outside this world are OK because they can never impact on the flows.

      In V4 attributes can go through the complete flow and never see the attribute definition and so the (new) deprecation warning needs to be in the IdPAttribute (as well as attribute definition and potentially transcoders - see below).  Further in IdPAttribute we need a debug level message with the attribute name to help diagnose these (since we are much further from the configuration at this point),

      So I'll add the test for a single quotes.  What does the team think about other special characters?  Obviously we cannot disallow '.' and ':' but there are others.


      Finally I should note that in V4 the constaint in IdpAttribute is

      Constraint.isTrue(id.indexOf(' ') < 0, "Attribute ID must not have spaces"); 

      But in AbstractAttributeDefinition is is

              if (!Pattern.matches("\\S*", getId())) 

      (in other words tabs and other non printing characters).

      It feels like, in this new world of definitional-less attributes we need to expand the check in IdPAttribute to match the definition, and also for helping in debugging add a similar test somewhere into the Transcoding stack.


          Issue Links



              cantor.2@osu.edu Scott Cantor
              rdw@iay.org.uk Rod Widdowson
              1 Start watching this issue



                  Time Tracking

                  Original Estimate - 3 hours
                  Remaining Estimate - 0 minutes
                  Time Spent - 30 minutes Time Not Required