Consider strict mode to reject unexpected content

Description

The traditional behavior of the unmarshallers is to ignore unxpected content, with the default base class supplying empty non-throwing versions of attribute and element processing.

I think this is dangerous as a default, and think it's worth considering whether to have a toggleable property to enable more strict behavior that raises exceptions when content that's explicitly disallowed appears where it shouldn't. I think that's mostly in the base class, frankly, and not a huge change.

Environment

None

Activity

Show:

Scott Cantor August 23, 2023 at 4:10 PM

Heh, will fix.

Rod Widdowson August 23, 2023 at 4:06 PM

Saw invalid element content " of elemment

Sic?

Scott Cantor August 23, 2023 at 3:59 PM

I found the metadata error. My best guess as to the reason it doesn’t log this is that it was a “trailing” character mistake, and it probably stopped processing the element content before it reached the character.

Scott Cantor August 23, 2023 at 3:52 PM

I’ve scoured my logging config and logs, I can’t find any sign of the debug output that seemingless has to be there if it’s not throwing. It’s like it behaves differently unmarshalling based on the strict mode setting. I don’t know how that would be possible.

Scott Cantor August 23, 2023 at 3:28 PM
Edited

Setting -Dopensaml.config.xml.unmarshall.strictMode=false does fix this (pending a simpler way to turn it off) but I find it curious that it doesn’t appear to be logging anything on DEBUG from that alternate code branch. That seems…impossible?

The EntityAttributes unmarshaller subclass doesn’t override that method, so it should either throw or log and if it was throwing and now isn’t…it should log now.

Done
Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Reporter

Components

Fix versions

Created November 25, 2019 at 3:05 PM
Updated August 23, 2023 at 4:10 PM
Resolved August 23, 2023 at 4:00 PM