WSO2 API Manager - "Make this the default version" causes authentication errors?

Question

I have an API that works no problem providing the "Make this the default version" checkbox isnt checked, once checked I get this error back

<ams:fault 
    xmlns:ams="http://wso2.org/apimanager/security">
    <ams:code>900906</ams:code>
    <ams:message>No matching resource found in the API for the given request</ams:message>
    <ams:description>Access failure for API: xxxx/xxxx, version: v0.1 with key: xxxxxx</ams:description>
</ams:fault>

Is there something I have missed at all?

Thanks,

Ash.

EDIT - Extra Detail and Logs

TID[-1234] [AM] [2014-07-10 13:05:56,238] ERROR {org.wso2.carbon.apimgt.gateway.handlers.security.APIAuthenticationHandler} - API authentication failure org.wso2.carbon.apimgt.gateway.handlers.security.oauth.OAuthAuthenticator.authenticate(OAuthAuthenticator.java:157) org.wso2.carbon.apimgt.gateway.handlers.security.APIAuthenticationHandler.handleRequest(APIAuthenticationHandler.java:92) org.apache.synapse.rest.API.process(API.java:285) org.apache.synapse.rest.RESTRequestHandler.dispatchToAPI(RESTRequestHandler.java:83) org.apache.synapse.rest.RESTRequestHandler.process(RESTRequestHandler.java:64) org.apache.synapse.core.axis2.Axis2SynapseEnvironment.injectMessage(Axis2SynapseEnvironment.java:220) org.apache.synapse.core.axis2.SynapseMessageReceiver.receive(SynapseMessageReceiver.java:83) org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:180) org.apache.synapse.transport.passthru.ServerWorker.processNonEntityEnclosingRESTHandler(ServerWorker.java:344) org.apache.synapse.transport.passthru.ServerWorker.run(ServerWorker.java:168) org.apache.axis2.transport.base.threads.NativeWorkerPool$1.run(NativeWorkerPool.java:172) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) java.lang.Thread.run(Thread.java:744)

Answer 1

You'll first want to turn on wire logs in that environment by editing your ../repository/conf/log4j.properties file and restarting the service. This will allow you to see the request headers for both the initial request to the gateway and the request from the gateway to itself (or other gateways in your cluster) since that's how requests to a default API version are resolved. This can help you identify whether your Authorization header values are actually making it to the authentication handler.

After you take a look at this, note that when you publish an API with a default version, you're actually creating (or updating) two separate synapse configurations for the API: a versioned configuration and an unversioned configuration. The portion of the latter's definition that you need to check is:

            <else>
           <header name="WSO2_AM_API_DEFAULT_VERSION" scope="transport" value="true"/>
           <property name="uri.var.portnum" expression="get-property('https.nio.port')"/>
           <send>
              <endpoint>
                 <http uri-template="https://localhost:{uri.var.portnum}/myApi/v1">
                    <timeout>
                       <duration>60000</duration>
                       <responseAction>fault</responseAction>
                    </timeout>
                 </http>
              </endpoint>
           </send>
        </else>

By default, the newly generated definition for the default version attempts to send the request to localhost, which may not be what you want. Check at ../repository/deployment/synapse-configs/default/api and make sure that this definition is correct.

Since it looks like this is actually an authentication error, you should also test a new subscription. Create a new application with some subscriber, subscribe to the API, and generate new access tokens. I wouldn't understand why (since setting a default version doesn't create a new API entry in the AM_API table) but this could possibly be due to the access token credentials being invalid for the default version, and generating new tokens should (in theory) test against this.

Answer 2

Please save and publish the API once you made the change to the API. This may be causing the issue.

Once you have published you should see 2 sets of production url (one with the version and one without the version). Please check if the same is available in the API store for your API.