Topics

hasAccessToWebResource method


Guillermo González de Agüero
 

Great to hear, Will, thanks!


Regards,

Guillermo González de Agüero


El vie., 19 de mayo de 2017 17:25, Will Hopkins <will.hopkins@...> escribió:
Actually, I've reconsidered. I'll leave it in for now, and we can consider what, if anything, to do with it after the PRD is published. I may tweak or remove some of the JACC-related language (although JACC isn't my issue with the API design).

Will


On 05/19/2017 11:08 AM, Guillermo González de Agüero wrote:
Hi,

While I understand your position, I think removing that method will be a big miss for users. It is clearly a needed feature.

In the unfortunate case that it finally has to be removed, I'd strongly vote for keeping it on the RI as an incubating API.

Given that some other useful things have been moved to the RI due to lack of consensus/time, I think Oracle should do some promotion and marketing about those features on the Glassfish blog, so that people will undertand the limitations of the API and how important is for them to test and provide feedback on those non portable features.

Lots of people (including me) try to use just the standard APIs and tend to ignore the propietary ones in order to maintain portability. Specially in this case, feedback will be needed to evolve these incubating features, and people need to be conscious about it.

This is of course not to blame spec lead work. We all know these are difficult decissions. It's just a thought I wanted to expose.


Regards,

Guillermo González de Agüero

El vie., 19 de mayo de 2017 16:49, Will Hopkins <will.hopkins@...> escribió:
Hi Arjan,

As I said on the other thread:
I feel badly about this, but I'm going to say we need to leave it out. It was added after I made clear statements that we couldn't add any more scope to the API, I'm not convinced the approach is the right one (although, equally, I'm not convinced it's wrong), and we're out of time to have the EG weigh in.

Will



On 05/19/2017 10:30 AM, Arjan Tijms wrote:

p.s.

To address some of the concerns that were raised by Will, I could make the following changes:


* Rename the method to hasCallerAccessToWebResource

* Rename the method's argument from "resource" to "urlPattern"

* Remove the overloaded method that defaults to GET, specify that if no parameters are provided for "methods" that GET is assumed. (addressing the "many methods concern somewhat)

* Clarify that all containers in Java EE are allowed to call the method

* Clarify that is the caller is not authenticated at all, and the resource is non-public a false is returned

* Clarify that Section 11.2 of the Servlet spec is meant, instead of just "the servlet spec"


Kind regards,

Arjan Tijms




-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Arjan Tijms
 

Hi Will,

Thanks a lot for reconsidering this very important feature! I'm okay with tweaking the JACC language.

Your previous mail and my last response crossed each other because I was working on the PR to address the things you mentioned. If you want to accept the PR feel free to do so for the PRD, but leaving things as-is for now (i.e. not accepting the PR at this point) would also work for me.

Thanks again!

Kind regards,
Arjan Tijms




On Fri, May 19, 2017 at 5:25 PM, Will Hopkins <will.hopkins@...> wrote:
Actually, I've reconsidered. I'll leave it in for now, and we can consider what, if anything, to do with it after the PRD is published. I may tweak or remove some of the JACC-related language (although JACC isn't my issue with the API design).

Will


On 05/19/2017 11:08 AM, Guillermo González de Agüero wrote:
Hi,

While I understand your position, I think removing that method will be a big miss for users. It is clearly a needed feature.

In the unfortunate case that it finally has to be removed, I'd strongly vote for keeping it on the RI as an incubating API.

Given that some other useful things have been moved to the RI due to lack of consensus/time, I think Oracle should do some promotion and marketing about those features on the Glassfish blog, so that people will undertand the limitations of the API and how important is for them to test and provide feedback on those non portable features.

Lots of people (including me) try to use just the standard APIs and tend to ignore the propietary ones in order to maintain portability. Specially in this case, feedback will be needed to evolve these incubating features, and people need to be conscious about it.

This is of course not to blame spec lead work. We all know these are difficult decissions. It's just a thought I wanted to expose.


Regards,

Guillermo González de Agüero

El vie., 19 de mayo de 2017 16:49, Will Hopkins <will.hopkins@...> escribió:
Hi Arjan,

As I said on the other thread:
I feel badly about this, but I'm going to say we need to leave it out. It was added after I made clear statements that we couldn't add any more scope to the API, I'm not convinced the approach is the right one (although, equally, I'm not convinced it's wrong), and we're out of time to have the EG weigh in.

Will



On 05/19/2017 10:30 AM, Arjan Tijms wrote:

p.s.

To address some of the concerns that were raised by Will, I could make the following changes:


* Rename the method to hasCallerAccessToWebResource

* Rename the method's argument from "resource" to "urlPattern"

* Remove the overloaded method that defaults to GET, specify that if no parameters are provided for "methods" that GET is assumed. (addressing the "many methods concern somewhat)

* Clarify that all containers in Java EE are allowed to call the method

* Clarify that is the caller is not authenticated at all, and the resource is non-public a false is returned

* Clarify that Section 11.2 of the Servlet spec is meant, instead of just "the servlet spec"


Kind regards,

Arjan Tijms




-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803



Will Hopkins
 

Actually, I've reconsidered. I'll leave it in for now, and we can consider what, if anything, to do with it after the PRD is published. I may tweak or remove some of the JACC-related language (although JACC isn't my issue with the API design).

Will

On 05/19/2017 11:08 AM, Guillermo González de Agüero wrote:
Hi,

While I understand your position, I think removing that method will be a big miss for users. It is clearly a needed feature.

In the unfortunate case that it finally has to be removed, I'd strongly vote for keeping it on the RI as an incubating API.

Given that some other useful things have been moved to the RI due to lack of consensus/time, I think Oracle should do some promotion and marketing about those features on the Glassfish blog, so that people will undertand the limitations of the API and how important is for them to test and provide feedback on those non portable features.

Lots of people (including me) try to use just the standard APIs and tend to ignore the propietary ones in order to maintain portability. Specially in this case, feedback will be needed to evolve these incubating features, and people need to be conscious about it.

This is of course not to blame spec lead work. We all know these are difficult decissions. It's just a thought I wanted to expose.


Regards,

Guillermo González de Agüero

El vie., 19 de mayo de 2017 16:49, Will Hopkins <will.hopkins@...> escribió:
Hi Arjan,

As I said on the other thread:
I feel badly about this, but I'm going to say we need to leave it out. It was added after I made clear statements that we couldn't add any more scope to the API, I'm not convinced the approach is the right one (although, equally, I'm not convinced it's wrong), and we're out of time to have the EG weigh in.

Will



On 05/19/2017 10:30 AM, Arjan Tijms wrote:

p.s.

To address some of the concerns that were raised by Will, I could make the following changes:


* Rename the method to hasCallerAccessToWebResource

* Rename the method's argument from "resource" to "urlPattern"

* Remove the overloaded method that defaults to GET, specify that if no parameters are provided for "methods" that GET is assumed. (addressing the "many methods concern somewhat)

* Clarify that all containers in Java EE are allowed to call the method

* Clarify that is the caller is not authenticated at all, and the resource is non-public a false is returned

* Clarify that Section 11.2 of the Servlet spec is meant, instead of just "the servlet spec"


Kind regards,

Arjan Tijms




-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Guillermo González de Agüero
 

Hi,

While I understand your position, I think removing that method will be a big miss for users. It is clearly a needed feature.

In the unfortunate case that it finally has to be removed, I'd strongly vote for keeping it on the RI as an incubating API.

Given that some other useful things have been moved to the RI due to lack of consensus/time, I think Oracle should do some promotion and marketing about those features on the Glassfish blog, so that people will undertand the limitations of the API and how important is for them to test and provide feedback on those non portable features.

Lots of people (including me) try to use just the standard APIs and tend to ignore the propietary ones in order to maintain portability. Specially in this case, feedback will be needed to evolve these incubating features, and people need to be conscious about it.

This is of course not to blame spec lead work. We all know these are difficult decissions. It's just a thought I wanted to expose.


Regards,

Guillermo González de Agüero

El vie., 19 de mayo de 2017 16:49, Will Hopkins <will.hopkins@...> escribió:
Hi Arjan,

As I said on the other thread:
I feel badly about this, but I'm going to say we need to leave it out. It was added after I made clear statements that we couldn't add any more scope to the API, I'm not convinced the approach is the right one (although, equally, I'm not convinced it's wrong), and we're out of time to have the EG weigh in.

Will



On 05/19/2017 10:30 AM, Arjan Tijms wrote:

p.s.

To address some of the concerns that were raised by Will, I could make the following changes:


* Rename the method to hasCallerAccessToWebResource

* Rename the method's argument from "resource" to "urlPattern"

* Remove the overloaded method that defaults to GET, specify that if no parameters are provided for "methods" that GET is assumed. (addressing the "many methods concern somewhat)

* Clarify that all containers in Java EE are allowed to call the method

* Clarify that is the caller is not authenticated at all, and the resource is non-public a false is returned

* Clarify that Section 11.2 of the Servlet spec is meant, instead of just "the servlet spec"


Kind regards,

Arjan Tijms




-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Will Hopkins
 

Hi Arjan,

As I said on the other thread:
I feel badly about this, but I'm going to say we need to leave it out. It was added after I made clear statements that we couldn't add any more scope to the API, I'm not convinced the approach is the right one (although, equally, I'm not convinced it's wrong), and we're out of time to have the EG weigh in.

Will


On 05/19/2017 10:30 AM, Arjan Tijms wrote:

p.s.

To address some of the concerns that were raised by Will, I could make the following changes:


* Rename the method to hasCallerAccessToWebResource

* Rename the method's argument from "resource" to "urlPattern"

* Remove the overloaded method that defaults to GET, specify that if no parameters are provided for "methods" that GET is assumed. (addressing the "many methods concern somewhat)

* Clarify that all containers in Java EE are allowed to call the method

* Clarify that is the caller is not authenticated at all, and the resource is non-public a false is returned

* Clarify that Section 11.2 of the Servlet spec is meant, instead of just "the servlet spec"


Kind regards,

Arjan Tijms




-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Arjan Tijms
 

p.s.

To address some of the concerns that were raised by Will, I could make the following changes:


* Rename the method to hasCallerAccessToWebResource

* Rename the method's argument from "resource" to "urlPattern"

* Remove the overloaded method that defaults to GET, specify that if no parameters are provided for "methods" that GET is assumed. (addressing the "many methods concern somewhat)

* Clarify that all containers in Java EE are allowed to call the method

* Clarify that is the caller is not authenticated at all, and the resource is non-public a false is returned

* Clarify that Section 11.2 of the Servlet spec is meant, instead of just "the servlet spec"


Kind regards,

Arjan Tijms




Arjan Tijms
 

Hi,

As requested by Werner, splitting this topic off from the welcome thread.

The previous discussion was about the format of the URL pattern and whether Servlet did, or did not define it.

As  mentioned, it's at least pretty clearly defined by JACC. There's no need to fear JACC, as it's just another Java EE spec that has defined or has helped defined a couple of things in Servlet and EJB pretty well.

That said, Servlet does indeed specify it too. The deployment descriptor referenced javaee:url-pattern, which is of url-patterntype. url-patterntype is defined in javaee_7.xsd as follows:


 <xsd:complexType name="url-patternType">

    <xsd:annotation>

      <xsd:documentation>

        The url-patternType contains the url pattern of the mapping.

        It must follow the rules specified in Section 11.2 of the

        Servlet API Specification. This pattern is assumed to be in

        URL-decoded form and must not contain CR(#xD) or LF(#xA).

        If it contains those characters, the container must inform

        the developer with a descriptive error message.

        The container must preserve all characters including whitespaces.

      </xsd:documentation>


So this points back to Section 11.2 of the Servet spec, which was already mentioned.

In practice the URL pattern is a very well known concept in Java EE, as it's used in Servlet mappings, Filter mappings and the @WebServlet annotation.

Kind regards,

Arjan Tijms