Google Cloud Endpoints - apiKeyRequired not working when endpoint has trailing slash

Question

I have an endpoint in Google Cloud Endpoints Frameworks for App Engine (Java). The endpoint is restricted to require an API key like this:

    @ApiMethod(name = "echo", path = "echo",  apiKeyRequired = AnnotationBoolean.TRUE, httpMethod = ApiMethod.HttpMethod.GET)

Which is working. However if I add a trailing slash when making the call, the endpoint returns data without an api key requirement.

I have tried to restrict api access globally in the api definition, like this:

@Api(
name = "myapi",
version = "v1",
apiKeyRequired = AnnotationBoolean.TRUE,

This however does not seem to work. I have regenerated the openapi.json and redeployed both the openapi.js and the app engine app, and the endpoint is still accessible if it has a trailing slash, but not without.

Does anyone know how I can prevent this? Any insight is much appreciated.

Answer 1

I was unable to solve this within Google Endpoints, so I utilized tuckey's urlrewrite to remove the trailing slashes in a filter

web.xml

         <filter>
        <filter-name>UrlRewriteFilter</filter-name>
        <filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
           <init-param>
                <param-name>confPath</param-name>
                <param-value>/WEB-INF/urlrewrite.xml</param-value>
            </init-param>
    </filter>
    <filter-mapping>
        <filter-name>UrlRewriteFilter</filter-name>
        <url-pattern>/_ah/api/*</url-pattern>
        <dispatcher>REQUEST</dispatcher>
    </filter-mapping>

urlrewrite.xml

    <?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 3.1//EN" "http://www.tuckey.org/res/dtds/urlrewrite3.1.dtd">
<urlrewrite>
    <rule match-type="regex">  
      <note>Remove trailing slash</note>
      <from>^(.*)/$</from>
      <to type="redirect">$1</to>
    </rule>  
</urlrewrite>

more info:

http://www.tuckey.org/urlrewrite/manual/4.0/index.html

Note: as of yet, it is not redirecting properly. I'm continuing to work on that, and will post updates, but now at least I'm getting a 404 for the version with the trailing slash, rather than the response data without api key, which satisfies my security needs at the moment