I understand this position and can emphasize while it may lead to a wrong sense of security. Even service users require severe attention wrt their permissions and can be similarly dangerous if they can write code into executable locations (and expand the attack by being able to potentially use loginadmin).
I personally still think we should get an option to retrieve a session and/or resourceResolver where we further constrain what the user can do in this particular session - processing malicious data in such a session couldn’t do harm outside of the case for which the session is built. Maybe someone with a deeper security aspect background of the oak team can share about their thoughts of how to deal with those cases best. Cheers Dominik Bertrand Delacretaz <[email protected]> schrieb am Sa. 28. Juli 2018 um 12:06: > On Sat, Jul 28, 2018 at 10:23 AM Carsten Ziegeler <[email protected]> > wrote: > > ...Today you can just look at the > > code and you know whether admin is used or not... > > I share this concern, any mechanism that magically makes something > admin is dangerous as it can easily be overlooked. > > If changes are really needed I think they should keep the current > "it's obvious what admin is" visibility. > > -Bertrand >
