I might have found a bug with the dashboard.
I setup my tyk definition json with custom_middleware (Oauth enabled)
I imported the json into tyk using the IMPORT API flow in the dashboard.
Just as a test , I exported the definition for the API and it was as expected.
I updated the name of the slug of the API and saved it
I exported the API definition again and this time I lost the “custom_middleware” part of the definition.
It’s now empty
Looks like the dashboard is overwriting the middleware setting in the definition.
Is this a know/valid bug ?
The dashboard doesn’t respect the custom middleware portion of the API definition.
To use middleware with the dash, use the folder-method
Thanks for the response. Will take a look.
I see that the PUT request from the dashboard while updating an API contains empty ‘custom_middleware’ definition.
One suggestion would be to probably not do that ?
Or use the ‘custom_middleware’ setting from the actual API definition when reading it on the edit page and use that in the PUT as well ?
Yeah we thought that too, we might add it as a reserved field so it doesn’t get overwritten. Will be considered.
Folder based method is easier though, you need to place files on the host anyway.
True. We’d have to have the files on the host anyways.
But, following the folder-method, we’d have to update that folder structure every time a new API is registered on tyk.
We are using docker containers and going with the flow of folder-structure is complicating the process a lot.
Is there a way to write a golang plugin instead of the JS plugin ?
If yes, does the golang plugin use the same folder structure requirements as the JS plugin ?
You can write go middleware and compile it into the source, you can’t selectively add it because it isn’t dynamic.
You could mount those folders into the docker containers for easier transport instead of packaging them.