Ex: Re: idp 4 / jetty

[Paul B. Henson]

> From: Cantor, Scott
> Sent: Monday, April 20, 2020 5:35 AM
> 
> Permitting GET/POST didn't block the others, but that could have been a bug
> in whatever version I was testing on.

Oh, that's not what I meant; I wasn't suggesting to replace the existing restriction, but rather augment it with an additional one that explicitly allows what is not explicitly denied rather than leaving it implicitly allowed.

My understanding of the warning is that if you have any security constraints at all, if there are any URLs that are not covered by a security constraint, whether allow or deny, it will warn you in case that was unintentional. The only way to get rid of the warning is to explicitly allow/deny all possible URL patterns/methods served by the app?

Hmm, based on a quick reading of the specifications, I think if you replace the first constraint with this:

<security-constraint>
    <display-name>Non-API Content</display-name>
    <web-resource-collection>
        <url-pattern>/*</url-pattern>
        <http-method-omission>GET</http-method-omission>
        <http-method-omission>POST</http-method-omission>
    </web-resource-collection>
    <auth-constraint/>
</security-constraint>

It might work? This will restrict all methods except GET/POST (if there are any others needed for the base URLs, they would have to be listed too). This constraint covers all methods so I think would not generate the warning. Then the other constraint currently in place doesn't specify methods, so I think it would be okay too.

It's not like the warning is an issue, I'm pretty sure the end result of your current constraints is exactly what you want, but sometimes I'm a bit anal about cleaning up logs 8-/.

Thanks...