Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [es-dev] app-securitycontext TCK test

I think this TCK test originally comes from the Soteria test suite (https://github.com/eclipse-ee4j/soteria/tree/master/test). So it's new for Security 3.0. But even then, Security 3.0 has already been released and to remove this test it would have to be challenged. And I think that insufficient documentation is not enough to challenge the test. So we have no way to remove/disable it, it's better to accept it and improve the documentation in the next release.



All the best,
Ondro Mihalyi

Director, Jakarta EE expert
OmniFish - Jakarta EE Consulting & Support | www.omnifish.ee
Omnifish OÜ, Narva mnt 5, 10117 Tallinn, Estonia | VAT: EE102487932

On Tue, Aug 16, 2022 at 1:09 PM Darran Lofthouse <darran.lofthouse@xxxxxxxxx> wrote:
Hi Ondro,

Yes I think that does sound like a reasonable definition for future releases to keep both in alignment.  For now however as the API is documented as requiring at least one method specified I don't think the TCK should enforce specific behaviour when no method is specified for Jakarta EE Security 3 testing.

Regards,
Darran Lofthouse.


On Tue, Aug 16, 2022 at 11:56 AM Ondro Mihályi <mihalyi@xxxxxxxxxxx> wrote:
Hi Darran,

I agree there's not much information to clarify this and this should be clarified in future versions of the security spec. For now, I think what best documents it is the TCk test and some hints in the Javadoc:
  • The Javadoc for SecurityContext.hasAccessToWebResource() contains the following in the documentation of the resource argument: "For a full specification of this pattern see WebResourcePermission(String, String)". I know this isn't in the docs for the methods argument, but WebResourcePermission includes not only resource pattern but also actions (http methods). So I'd assume that the documentation of WebResourcePermission is relevant also for the methods argument
  • The Javadoc for WebResourcePermission claims that "A null or empty string HTTPMethodSpec indicates that the permission applies to all HTTP methods at the resources identified by the URL pattern." Which means that the list of actions can be null or empty string. And that in that case the permission applies to all HTTP methods. That is a hint that when the methods argument to SecurityContext.hasAccessToWebResource() is empty, it should return true if the user has permission to all HTTP methods for a given resource.
I believe that this is also in line with what the TCK test expects.

Do you agree with what I wrote? Is it enough to clarify this behavior and explicitly document it in the future version of the Security spec? Or do you think that the behavior should be different?

All the best,
Ondro Mihalyi

Director, Jakarta EE expert
OmniFish - Jakarta EE Consulting & Support | www.omnifish.ee
Omnifish OÜ, Narva mnt 5, 10117 Tallinn, Estonia | VAT: EE102487932

On Tue, Aug 16, 2022 at 12:31 PM Darran Lofthouse <darran.lofthouse@xxxxxxxxx> wrote:
Hello I am just working on the WildFly profile for the Jakarta Security TCK, I am running into an issue with the app-securitycontext test I wanted to discuss.

Presently the test is making a call to SecurityContext.hasAccessToWebResource()   without specifying the HTTP method to test.


With no method passed in WildFly is presently returning false, however if I pass in a single method such as "GET" it returns true.

From the API itself this parameter is described as taking "one or more methods to check", from the specification itself there is also no mention of calling without specifying the HTTP method and the documented example does specify a method:


This feels like something which could be clarified in a later release but for now it doesn't feel like there is a clear definition of expected behaviour when no method is specified.

--

Darran Lofthouse

Red Hat

darran.lofthouse@xxxxxxxxx   

_______________________________________________
es-dev mailing list
es-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/es-dev


_______________________________________________
es-dev mailing list
es-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/es-dev
_______________________________________________
es-dev mailing list
es-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/es-dev

Back to the top