Issue with Tyk Identity Broker ProxyProvider configuration to issue api keys

Yay, I’m getting the auth token back:

curl -i -X POST http://192.168.99.100:3010/auth/1/proxy
HTTP/1.1 301 Moved Permanently
Location: http://192.168.99.100:3000#token=570eb4bee11a690001000005f43939e48d4f4d2f60a830a7ea9fa8af
Date: Wed, 13 Apr 2016 21:17:07 GMT
Content-Length: 0
Content-Type: text/plain; charset=utf-8

Thanks so much for all the help Martin. Now that I know how everything fits together and what to watch out for (duplicate listen paths, primary key vs api_id), it should be much easier the next time around

1 Like

Glad to hear it - lots of stuff we need to work on on this end :slight_smile:

Yea, it’s definitely a bit tough to track down some of my silly errors. I recommend hard failing on any config issues (duplicate listen paths, missing keys, etc) and preventing people from adding an api with a listen path that already exists. It can be a bit rough to track those things down in the code if you don’t know what you’re looking for.

1 Like

Ah, well actually we do that in cloud, it’s all very strictly managed (listen paths are forced UUIDS and auto-generated, duplicate slugs aren’t allowed - or even possible between tenants, collisions can’t happen etc. All of this is configured and managed with the same tech as on-prem (Pro).

But for Pro, we take the gloves off because the installs are smaller and users usually have access to logs and error data, so we’d rather give people lots of options in what seems like a more unstable system, but the payout is a high degree of flexibility to suit your needs once it’s up and running as required - it’s all a trade-off in the end…

TIB is a different story - it’s very new, so stabilising it and making it nice and friendly is still a WIP, we’ll get there though.