On 7/16/14, 1:21 PM, Brian Stansberry wrote:
On 7/15/14, 10:40 PM, Edward Wertz wrote:
> I've got a better broad solution to this now, but I'm having some trouble
figuring out how to create limitations on the functionality.
> I added a 'resolve-expressions' parameter to ':read-attribute', which
can enable the handler to simply call ModelNode.resolve() on the return value and replace
all the expressions with their runtime values from that server.
I assume you're referring to server-side handler,
You can't resolve expressions by calling ModelNode.resolve(), as that
doesn't account for all the resolution sources available in a WildFly
process, e.g. the security vault. An OperationStepHandler would do it
FYI, folks, Joe has done great work on this and has also been very
patient! See  which I hope to merge in the next day or so.
I was a bit off base in my last comment above. I don't actually want to
bring the security vault into the resolution process. The really nice
article on the vault by mentallurg at  outlines the theory of the
vault nicely. The whole point is the expression can be publicly
available, e.g. in the config file which might get passed around. But to
learn a secret you must have access to the vault itself, and that is a
carefully protected file.
Allowing a remote management client to read the vault via this feature
defeats the whole point. We don't let the existing :resolve-expression
op do this. I don't think our security schemes are such that we can say
that just because a user is an authorized WildFly admin (even an RBAC
SuperUser) that they are privileged in the user organization to read
This isn't a difficult issue to deal with though; a simple added commit
on Joe's work takes care of it.
Senior Principal Software Engineer
JBoss by Red Hat