Hi Just my 2 cents to it: Why not defining a "featureflag-interface" which is internally implemented with ResourceAccessGates. Personally I think ResourceAccessGates could do the job but I can follow the fear, that such a mechanism mixing up with a security mechanism could lead to bad design. So the solution could really be to wrap the ResourceAccessGates for the functionality of featureflags.
Best regards mike > -----Original Message----- > From: Dominik Süß [mailto:dominik.su...@gmail.com] > Sent: Tuesday, June 10, 2014 2:53 PM > To: dev > Subject: [featureflags] Readding sling:features to resourceResolver > > Hi everyone, > > although I know this touches an area with a lot of emotions involved I > wanted to reopen the discussion around Featureflags support for the > resourceresolver. > The last thing that happend was removing it for a release due to potential > confusion and subtle issues. See http://markmail.org/thread/jgpso52iqiivpa5t > > Here are my arguments why I think it would be good to readd it to the > resourceResolver (or any other mechanism being able to filter the resource > tree: > - Currently writing frontend that needs to adapt to featureflags requires > adding custom code to check and filter the ui to be rendered. This leads to > a lot of boilerplate code written over and over again with minor differences > - Mechanisms relying on the Default Get Servlet JSON output would need to > implement the filterlogic in clientside code. > - ACL based solutions complicate the security setup for administrators > because each feature would require a group (if toggling should be achived > by membership instead of complex permissionrewriting) and could potentially > impact performance of acl checks (not my domain so some specialists might > be able to tell if those additional groups and memberships have impact on > performance) > > The argument that developers might mistake feature flags with security is > indicating that they don't read documentation (where potential security > warnings should be written down in a prominent location) or do not care. > But who does not care will not take care of proper ACLs anyways and > assuming developers are using features without reading or respecting > warnings in the documentation sounds a bit paranoid. > > I still think Resource Access Gate might be viable but some people > convinced me that solving such a mechanism with a security mechanism would > probably make distinction between security and business based access > constraints (such as featureflags that constraint the access to a feature). > > Let's discuss this a bit so that everyone gets a clearer picture what > issues where faced and why it was a better idea to remove this featureflag > support and what would be the conditions under which no one would have an > issue with readding a revamped featueflag support for the resource tree. > > Best regards > Dominik
