data protection improvements

[unixslayer]

Why is this change proposed?

• XML support in data protection
• configure message protection when only property is annotated
• handle changing property names with custom converters

Pull Request Contribution Terms

• I have read and agree to the contribution terms outlined in CONTRIBUTING.

[unixslayer]

I've tried to use ConversionService here but it does not support serialization between array and xml string loosing parameter names when converting array into xml.

[dgafka]

Isn't the #[Sensitive('someCustomName')] solving this?

[dgafka]

class Person
{
       #[Sensitive("someName")]
       private string name
}

Or if this is about nesting e.g. <result><person><someName></someName></person></result>, so we do not know how to go into deeper nesting?

Because we could then provide nested structure attribute:

#[Nested(expression: "createArray('result', data)")]
class Person
{
       #[Sensitive("someName")]
       private string name
}

or eventually when we add support for functions (new php feature), that could be modified as needed:

#[Nested(expression: function($data) => ["result" => $data]]
class Person
{
       #[Sensitive("someName")]
       private string name
}

[unixslayer]

DataProtectionConverter works around serialization on root level. Depending on configuration, not all of properties may need protection. Custom name passed with #[Sensitive] does not solve it as it's not for serialization. It only tells DataProtectionConverter that property name in serialization is different than property in actual object.

Also nested data is not a problem here because it does not matter. Data Protection works only for root and nested properties (non scalar) are always serialized to string. Consider following example:

class SomeMessage
{
    public function __construct(
        #[Sensitive] public SomeClass $sensitive,
        public string $property
    ) {
    }
}

class SomeClass
{
    public function __construct(
        public string $argumentA,
        public string $argumentB,
    ) {
    }
}

After serialization it will have nested structure:

[
    "sensitive" => [
        "argumentA" => "foo",
        "argumentB" => "bar",
    ],
    "property" => "baz",
]

Encryption will return following structure:

[
    "sensitive": "TG9yZW0gaXBzdW0gZG9sb3Igc2l0IGFtZXQ=",
    "property": "baz"
]

Once encrypted, data has to be returned as XML. ConversionService returns following XML (handled by JMSConverter)

<?xml version="1.0"?>
<root>
    <entry>TG9yZW0gaXBzdW0gZG9sb3Igc2l0IGFtZXQ=</entry>
    <entry>baz</entry>
</root>

This is the reason why I introduced XMLHelper as JMS was not cooperative.

[dgafka]

Isn't the #[Sensitive('someCustomName')] solving this?

[dgafka]

class Person
{
       #[Sensitive("someName")]
       private string name
}

Or if this is about nesting e.g. <result><person><someName></someName></person></result>, so we do not know how to go into deeper nesting?

Because we could then provide nested structure attribute:

#[Nested(expression: "createArray('result', data)")]
class Person
{
       #[Sensitive("someName")]
       private string name
}

or eventually when we add support for functions (new php feature), that could be modified as needed:

#[Nested(expression: function($data) => ["result" => $data]]
class Person
{
       #[Sensitive("someName")]
       private string name
}