Authentication with a golang plugin

I try to follow this docs step by step: Golang plugins (tyk.io). But it seems not work for me. The output of this api is alway: { “error”: “Access to this API has been disallowed” }

Here is my api definition file:

{
    "name": "BFF API",
    "slug": "bff-api",
    "api_id": "1",
    "org_id": "1",
    "use_keyless": false,
    "use_go_plugin_auth": true,
    "definition": {
        "location": "header",
        "key": "x-api-version"
    },
    "version_data": {
        "not_versioned": true,
        "versions": {
            "Default": {
                "name": "Default",
                "use_extended_paths": true
            }
        }
    },
    "custom_middleware": {
        "pre": [],
        "post": [],
        "post_key_auth": [],
        "auth_check": {
            "name": "AbcAuth",
            "path": "./middleware/plugin.so"
        },
        "driver": "goplugin"
    },
    "driver": "otto",
    "proxy": {
        "listen_path": "/bff/",
        "target_url": "http://my-upstream/",
        "strip_listen_path": true
    },
    "active": true
}

Please help to figure me out where am I wrong. Thanks.

It looks like compatibility issue.
If removes all dependencies of TykTechnologies/tyk away. My demo plugin will be ok.
My tyk-ce version: v3.2.1
My plugin dependency: github.com/TykTechnologies/tyk@b9315433e9477e2621c54c530327eb75f7e81ef5 (matches v3.2.1 as doc says)

Hi @redochenzhen ,

Welcome to Tyk Community and thank you for your patience on this.

Upon checking it seems that the issue { “error”: “Access to this API has been disallowed” } happens because there’s an issue with the plugin that’s why it is not being loaded properly. I can see that there’s indeed dependency issue happening on 3.2.1. Also as mentioned in this thread , it seems that there’s a bug in v3.2.x where the session is not being retrieved and since the code that you are following uses sessions, it will also have some issues. You can use v3.1.2 and the code works properly. Please let us know if there’s also a reason if you really need to use v3.2.x.

Additionally, I notice in your API Definition that there’s this line "driver": "otto", which should not be included. The correct “driver” field should be only the one inside the custom_middleware.

@redochenzhen Can you check if the same issue happens with v3.2.3?

I updated the thread with the initial spot also.