Post processing is there to filter the data returned by a get or a query. But it requires that they write code, so it is probably only pertinent for the old security model not for the new fully configurable End-to-end model that we have begun discussing.
So MAYBE we're actually doing too much work in keeping it for the new model. Thoughts? -- Mike Stolz Principal Engineer, GemFire Product Manager Mobile: 631-835-4771 On Fri, Jun 17, 2016 at 11:44 AM, Jinmei Liao <jil...@pivotal.io> wrote: > While working on the integrated security for gemfire9/geode1, we are > frequently baffled by this post-processing functionality that's been lumped > into security. Here are a few observations we've come up with and want to > run with the dev community for comments: > > 1. Post processing is not authorization. At this point, all necessary > authorization should already be done and satisfied. > > 2. Post processing is related to security in the sense that it needs a > Principal in the context, but it's not part of the authorization. > > 3. Previous implementation (client-server) adds post process after every > authorization checks. We want to make a clean separation of these two > concepts. New interfaces of post processing will be introduced (so that we > can preserve the old behavior if user is implementing the old interface), > and will ONLY be added to the "get" and "query" data operations. > > 4. The new interface will look like below: > public Object processValue(Principal principal, String regionPath, Object > key, Object value) > > Is this a sufficient interface to begin with? Do you have any client that > would need post processor to do something completely different? > > Thank you for all your feedback. > > -- > Cheers > > Jinmei >
