The driver is clever enough to figure out that it’s a replica set. We use replica sets too and don’t include the name specifically, the driver handles it.
Thanks. I have already change that and it’s appears functional. Another question regarding key creation.
With the upgrade to v2.0 from what I understand the key generation was removed from the dashboard for free licences is that correct?
Ok, so you’re tyk.conf doesn’t declare a secret to use for API calls, only one for the node heartbeat. You need to add a "secret": "352d20ee67be67f6340b4c0605b044b7" to your tyk.conf, since you’ve declared it in your dashboard configuration.
So basically, the dashboard was making a request to the gateway, with it’s API secret, but the gateway wasn’t configured with one and so defaulted to an empty string.
I have already defined the node secret in my local gateway . But still have problems when trying to generate keys for the organization. I can in dashboard to create them but I cannot create when using my api. I have the same problem a while back and I talked to you and at the time You told me to create a little timer to wait for API reload. In the previous version it was working but know it gives a null pointer exception on tyk gateway.
No, a gateway can only listen on one path per API - Tyk Gateway itself has almost no comprehension of what an ORG is, that’s purely a Dashboard concept.
If you are going multi-tenant, then I suggest you manage the listen paths more aggressively and have them auto-assigned, there’s a setting for this, but then they become IDs and you will need to manage rewrites yourself.
Hum… ok. Different approach then…Let’s suppose that I define in the listen path or name and set the API definition accordingly.
I have noticed that on github a issue is open relating this question:
Do you foresee problems on my end if instead I put another param instead of {id} (let’s say {org}) and not strip the listen path from inbound request? Will it work? Or is more complex?
if Tyk detects two listen paths that are a string match, it will skip the latter, so a wildcard might not help here.
What are you trying to achieve? No matter what yu do you will need to differentiate an inbound request by org somehow, that’s either busy path or by domain…
I’m trying to have the same API in a multi tenant setup. I have a nginx that will balance the incoming requests for this API and redirect to tyk gateway upstream…I need to redirect to the correspondent “tenant API”
Example:
ORG 1 Path 1
/api/tenant1
API Definition 1
/api/{tenant1}
ORG 2 Path 2
/api/tenant2
API D1finition 2
/api/{tenant2}
What I would like in the future it’s to rewrite the proxy_pass to pass parms to the gateway upstream
Second Point → Creating API Definitions and Keys
The upstream will be the tyk gateway and I need the listen path to be dynamic so that is different and not give the error of the duplicate API Definition. If this is not possible I only see the domain approach and didn’t understand you when you said[quote=“Martin, post:34, topic:763”]
somehow, that’s either busy path or by domain…
[/quote]
Ok, so the rule is simple - same string in listen path means a skip.
So define the same API with different listen paths and have two NGinX rewrites, one for org 1 and one for org 2.
We do this with lots of multi tenant installs, because you can tightly control listen paths that way and ensure no dupes but still have dupes on the domain side.
Hum…OK . We will not be doing multiple installs on different clients. When I refer multi tenant is that our platform will have multi tenant application logic. The tenants will be incorporated in the platform. We will be leveraging the organization concept for our benefit.
The rule stil holds: one listen path per API, Tyk Gateway has no tenancy concept, you need to manage that via domains or listen paths or a combo of the two.
Multi tenancy comes from the dashboard, and it baseline assumes that you will be running tenants in different domains or listen paths.
So, you either need to give each shared listen path a different domain or you need to use unique listen paths.