@michaelandrepearce I may have worked due to a bug that allowed the broker to violate the AMQP specification but was fixed later (https://issues.apache.org/jira/browse/ARTEMIS-1092) and should continue to not allow the broker to violate the AMQP 1.0 specification.
@tabish121 ok, so the use case here, is per https://issues.apache.org/jira/browse/ARTEMIS-584 essentially you cannot/do not trust the user sent on the message, you only trust the user used during auth to the broker, this is quite important for an audit requirement.
In this case as i noted as a user you are explicitly saying you wish to violate spec and modify the message. whilst i agree by default the broker should NOT break any specs, there does need ability to violate/or override for a feature, this would be on par with some of the FQQN stuff that allows users to violate some bits in JMS, (e.g. get a JMS Queue actually bound to a JMS Topic subscription), but you do this explicitly knowing this.
@tabish121 im open to suggestion on how to implement this in a way thats more amenable to yourself.
Other ideas i have:
1) Introduce a broker flag that specially and clearly named something like "allow-amqp-modfication-spec-break" then allows AMQP spec break, so its so clear that we're enabling a spec break.
2) If the populate-validated-user is set, then a or copy of the message is made.
3) Another idea, is there a tamper flag on AMQP spec? If so could we can set that? basically allowing you to say the message was mutated via the broker (and even possible say what was mutated (in this case user)).