[
https://issues.apache.org/jira/browse/QPID-7380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15451949#comment-15451949
]
Keith Wall commented on QPID-7380:
----------------------------------
The agreed approach is:
* The operation mechanism will be enhanced so that operations can be considered
secure if arbitrary parameters are set true. This will be specified using an
an annotation on Operation {{secureIfParamTrue}}.
* The existing operation {{Queue#getMessageInfo}} will accept a new optional
parameter includeHeaders which will default to true. If set false, the
operation will not return the headers the map. The new parameter will be
configured so that if set true, the operation requires a secure channel.
* UI will be changed:
** The message table in the queue tab will be populated with a call to
getMessageInfo(includeHeaders=false) so that the table is populated even on an
insecure channel.
** The message dialogue will request headers and show message content
preview/buttons only if the channel is secure. If on a insecure channel, it
should show the available message info and include a message with word to
effect of "message headers and content unavailable as channel is insecure".
> [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]
