Mark,
On 5/27/21 12:22, Mark Thomas wrote:
On 27/05/2021 15:04, Christopher Schultz wrote:
Mark,
On 5/27/21 04:59, Mark Thomas wrote:
On 27/05/2021 07:32, Carsten Klein wrote:
On 26/05/2021 19:56, Mark Thomas wrote:
Given that the attributes may well be security related, you would
need to make sure neither the Map nor any of the keys/values could
be modified. Protecting the Map is easy. Protecting the keys/values
is a little trickier. For that reason I'd lean towards the solution
below.
Oh yes, these attributes should likely be immutable. Since I still
believe that Enumerations are kind of uncomfortable (and outdated?),
what about strictly relying on Collections.unmodifiableMap?
The issue while objects can't be added to the Map or removed from the
Map, the objects can still be mutated. For that reason I prefer the
getAttribute() approach where an appropriate defensive copy can be
made before returning any attribute value.
Does that mean this needs to be Map<String,<? extends Clonable>>? Or
Map<String,<? extends Serializable>>?
How do you expect to perform defensive-copies of arbitrary objects?
Good point. I think that means attribute values can't be any old object.
Limiting things to <? extends Clonable> seems reasonable to me as that
makes the defensive copy easy. Although that does lead to a deep clone
vs shallow cone discussion. I think the simplest way to deal with that
is to document how the defensive copy is made and note that users of the
API need to be sure any attributes they provide are safe given how the
defensive copy is made.
Unfortunately, Clonable and Serializable have both fallen out of favor
in the Java world because both ideas seem to have some serious issues.
If we pick one versus the other, we may have a lot of push-back.
What's the primary use-case for these kinds of attributes?
If we restrict attribute values to Strings, is that too limiting?
If we return Collections.unmodifiableMap() to return Map<String,String>
that makes things simpler. But how much do we trust
Collections.unmodifiableMap if the underlying data are
security-sensitive? With reflection, is it possible to monkey your way
through the references and swap-out the underlying references? That
might be Bad.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
