28 Mar, 2014

3 commits


27 Mar, 2014

1 commit


26 Mar, 2014

3 commits

  • * provide the ability to easily set attributes in entries.
    
    
    git-svn-id: https://svn.forgerock.org/openig/trunk@153 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    matthew
     
  • Provided global variable "ldap" which provides simple access to OpenDJ LDAP SDK including:
    
    * ldap.connect(host, port) - obtains cached connection to host/port (no SSL)
    * ldap.connect(host, port, options) - obtains cached connection to host/port (with optional SSL)
    * ldap.dn(template, args...) - injection safe printf style formatting of DNs
    * ldap.filter(template, args...) - injection safe printf style formatting of filters
    * ldap.scope.* - easy access to LDAP search scopes, e.g. ldap.scope.sub.
    
    The connect methods return an adapted SDK LDAP connection which only exposes the synchronous methods. This is to protect against future evolution of the SDK APIs (e.g. we plan to migrate to using Promises). In addition, the Groovy scripting engine has been enhanced using Groovy MetaClasses to facilitate access to LDAP Entry attributes, which are now exposed as properties. For example, the following code parses the "description" attribute as a single valued string:
    
        entry.description.parse().asString()
    
    The testLdapClient unit test in GroovyScriptFilterTest illustrates LDAP usage.
    
    
    git-svn-id: https://svn.forgerock.org/openig/trunk@152 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    matthew
     
  • * added out of the box support for using the OpenDJ LDAP SDK
    * added unit test illustrating usage from within Groovy.
    
    A subsequent commit will improve the integration in order to reduce boilerplate and to cache connections between script invocations.
    
    
    git-svn-id: https://svn.forgerock.org/openig/trunk@151 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    matthew
     

07 Mar, 2014

2 commits

  • Filters and handlers support a single standalone Groovy script. At the moment the script is not automatically reloaded. The following variables are injected into each script invocation:
    
    * globals - a Map of global variables which persist across successive invocations of the script
    * exchange - the HTTP exchange
    * http - an OpenIG HTTP client which may be used for performing outbound HTTP requests
    * logger - the OpenIG logger
    * next - the next handler in the filter chain (filters only).
    
    Many examples showing how Groovy scripts can interact with OpenIG can be found in GroovyScriptFilterTest.
    
    
    git-svn-id: https://svn.forgerock.org/openig/trunk@150 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    matthew
     
  • git-svn-id: https://svn.forgerock.org/openig/trunk@149 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    matthew
     

05 Mar, 2014

1 commit


28 Feb, 2014

2 commits

  • Add basic preliminary support for Groovy scriptable filters and handlers. Uses JSR-223 for now, but plan to move to our commons scripting module when it's ready. Scripts can read and write exchange fields, except for the entity.
    
    
    git-svn-id: https://svn.forgerock.org/openig/trunk@147 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    matthew
     
  • "If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck."
    
    But Ducks are fat and we don't want lots of excess fat in our code base so, since we are not duck collectors, let's go shoot some duck. :-)
    
    Seriously: OpenIG uses duck-typing to provide map-like views of various objects. JSR 223 implementations, such as for Groovy, provide automatic support for bean-like objects and maps. In particular, bean getters/setters and map key/value pairs are automatically mapped to properties in Groovy scripts. This makes scripting really easy and developer friendly. Unfortunately, the support does not extend to our duck-typed objects, which are neither beans or maps. I was unable to see why duck-typing is needed in OpenIG, other than to avoid implementing a couple of awkward map view methods (e.g. entrySet), but they bring their own complexity. For example, many engineers find the duck-type support hard to understand and maintain.
    
    
    git-svn-id: https://svn.forgerock.org/openig/trunk@146 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    matthew
     

21 Feb, 2014

1 commit


20 Feb, 2014

1 commit

  • * remove unused imports
    * fixed various compilation warnings.
    
    
    git-svn-id: https://svn.forgerock.org/openig/trunk@144 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    matthew
     

07 Feb, 2014

1 commit


06 Feb, 2014

2 commits


03 Feb, 2014

1 commit


14 Jan, 2014

2 commits


03 Jan, 2014

2 commits


11 Nov, 2013

1 commit


13 Oct, 2013

1 commit


10 Sep, 2013

1 commit

  • Merge changes made to 2.1.1 branch but not brought into trunk at the time.
    
    openig/2.1.1 $ svn log -r90
    ------------------------------------------------------------------------
    r90 | jbranch | 2012-08-09 10:05:35 -0700 (Thu, 09 Aug 2012) | 1 line
    
    svn merge https://svn.forgerock.org/openig/branches/2.1.1@90 .
    --- Merging r89 through r90 into '.':
    U    openig-core/src/test/java/org/forgerock/openig/el/ExpressionTest.java
    A    openig-core/src/test/java/org/forgerock/openig/filter/HttpBasicAuthFilterTest.java
    A    openig-core/src/test/java/org/forgerock/openig/filter/HeaderFilterTest.java
    U    openig-core/src/main/java/org/forgerock/openig/filter/HeaderFilter.java
    U    openig-core/src/main/java/org/forgerock/openig/el/Expression.java
    G    openig-core/pom.xml
    U   .
    
    
    
    git-svn-id: https://svn.forgerock.org/openig/trunk@133 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
    jbranch
     

16 Aug, 2013

2 commits


13 Aug, 2013

1 commit


23 Jul, 2013

1 commit


22 Jul, 2013

1 commit


08 Jul, 2013

2 commits


05 Jun, 2013

1 commit


27 May, 2013

1 commit


12 Mar, 2013

1 commit


08 Mar, 2013

1 commit


20 Feb, 2013

1 commit


09 Jan, 2013

2 commits


02 Jan, 2013

1 commit