Oh, yes. In the new model we are working on, users can just configure the security with no custom implementation. But if they want to do something crazy, they can still grab these interfaces and implement their own way.
On Fri, Jun 17, 2016 at 1:57 PM, Michael Stolz <mst...@pivotal.io> wrote: > But the new model is supposed to be configuration only no user code, so I > don't think it applies > > -- > Mike Stolz > Principal Engineer - Gemfire Product Manager > Mobile: 631-835-4771 > On Jun 17, 2016 4:48 PM, "Jinmei Liao" <jil...@pivotal.io> wrote: > > > If we are only doing post-processing for get and query, then it's not too > > much work adding it into the new model. > > > > On Fri, Jun 17, 2016 at 12:00 PM, Michael Stolz <mst...@pivotal.io> > wrote: > > > > > 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 > > > > > > > > > > > > > > > -- > > Cheers > > > > Jinmei > > > -- Cheers Jinmei
