[
https://issues.apache.org/jira/browse/QPID-7380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15465372#comment-15465372
]
Keith Wall commented on QPID-7380:
----------------------------------
Commit 1759209 restores the ability to view non-confidential information about
messages from Management.
Currently the approach taken is that UI, when trying to populate the message
dialogue first tries to get the confidential information, then if it fails with
a 403 tries again with a {{includeHeaders=false}}. This is quite unpleasant
and may mean logs are cluttered with 403 errors. It would have been nicer if
the client could somehow determine if it is allowed to see confidential
information without causing the failure. Unfortunately the client has no
reasonable we to do this. It cannot tell through which HttpPort the user is
connecting on, so it cannot observe the state of the
{{HttpPort#isAllowConfidentailOperationOnInsecureChannel}} to know if the
override has been applied applied. If there were an operation say
{{HttpManagemen#canViewConfidentialInformation}} the UI could avoid the
nastiness. but the operation's implementation would need information about the
port and protocol- details that our current 'transport agnostics' operation
mechanism is not currently exposed.
As a compromise, it did occur to me that the UI could cache whether
confidential information is accessible on this use the apply the same technique
at all points within the same session. This would at least reduce the noise in
the logs.
> [Java Broker] Managed Operations returning potentially confidential
> information should not be permitted by default on insecure connections
> ------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: QPID-7380
> URL: https://issues.apache.org/jira/browse/QPID-7380
> Project: Qpid
> Issue Type: Improvement
> Reporter: Rob Godfrey
> Fix For: qpid-java-6.1
>
>
> Operations such as getting message content or extracting config or message
> data may contain confidential information. As such one would not normally
> wish these operations to be permitted on insecure (non-TLS) connections. We
> should enhance the meta data for managed operations to allow for declaring
> them "secure", we should then change the REST servlet to prevent the
> operation of "secure" operations on insecure connections. To allow those who
> are aware of the risks, but accept them, we should add an attribute to the
> (Http)Port to allow secure operations to be performed on that port even where
> the connection is insecure.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
