smoyer64 edited a comment on issue #21: PennSt Bug #67 - PatchOperationPathAdapter marshaller does not pass … URL: https://github.com/apache/directory-scimple/pull/21#issuecomment-413560972 We definitely want PATCH to be compatible with the specification and @alexhaskell has put a lot of effort into the parts of PATCH that are done. We have issues with both PUT and PATCH when attribute-by-attribute security is enabled (we use Fortress RBAC to control access to methods and "objects"). Imagine a user who retrieves the attributes they're allowed to "see" and then PUTs an update. Under the strict definition of the PUT verb, they would effectively delete any fields that weren't "visible" to them. The existing PATCH code will probably work for the SCIM Groups resource. We completely understand why you don't want to completely replace an LDAP group just to add or delete a member. If you don't have attribute-based security as noted above, there shouldn't be an issue with PATCHing groups. We've backed off on using PATCH for the SCIM Users resource at the moment and so it might be a while before we can get around to fully testing PATCH on one of our production systems. I'll let @alexhaskell comment further if he's got any more insight. As an aside, I'm curious what IdP you're using, and what type of persistence they're backing their SCIM interface with. We found an interesting duality with PATCH (that somewhat extends to POST and PUT when an RDBMS-like persistence layer is used. First consider an LDAP backing store. The protocol specifically allows ldapmodify requests which can be directly created from the operations described in a PATCH operation. If those same multi-valued attributes are to be stored in an RDBMS, you're going to end up (presumably) sending multiple UPDATE requests to the server (preferably wrapped in a transaction to maintain consistency). PUTs and POSTs are somewhat the opposite ... you can store them in a NoSQL system with a single call, but you have to GET the entry, modify it in place and PUT it back into the NoSQL with another (single) call. So to some degree, we allow the provider to decide how these operations are turned into interactions with the persistence layer. We've never published nightly builds - but SNAPSHOT builds were built by the Penn State Jenkins server and pushed to Sonatype's OSS SNAPSHOT repository whenever a new commit was detected. Now that we're an Apache project, we're building using the Apache Jenkins infrastructure which is still triggered on commits to the develop branch of the project. Apache projects don't publish SNAPSHOTs to the Sonatype OSS SNAPSHOT repository but instead provide their own SNAPSHOT artifact repository. You can find the latest SNAPSHOT builds of the Apache Directory SCIMple project at https://repository.apache.org/content/repositories/snapshots/org/apache/directory/scim/. Either add the Apache SNAPSHOT repository to your local artifact repository as a proxy __OR__ at it to the repository section of your project's POM. We'll definitely work with you to get PATCH tested and I think that SCIM Groups (being quite a bit simpler) is a good place to start! EDIT: As noted in the README, we have in fact moved the project's issue tracking to Apache's Jira server - it's true that we haven't yet migrated existing issues to Jira (I'm looking at automated tools to do that) but feel free to submit new issues there (http://issues.apache.org/jira/browse/SCIMPLE)
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
