special case for basic auth added

[dencoded]

Fix https://github.com/TykTechnologies/tyk-analytics/issues/976 #2038

Added new attributes org_id and username (boolean) attributes, which should be passed together when you query for username.

[buger]

I get the idea, but I'm afraid this will not work. When dashboard sends the request to gateway API, it does not set the right API id.

[dencoded]

it worked for me in dashboard - tried to find two different BA-keys (created for different BA apis).

the problem here that our gateway logic uses API-id just to get session storage, then it can find any key as they are prefixed with "apikey-" (no API id in prefix). I think dashboard picks latest added API ID to do call and relays on that weird legacy behaviour.

So nothing really changed except it works with hashing algo. There is one problem though - if passed API ID is not BA - it is not gonna work. This condition https://github.com/TykTechnologies/tyk/pull/2018/files#diff-651a84f8ad6a38c1f7ccdf63f2692410R328 makes sense only dashboard is sending right API ID, maybe we should remove spec.UseBasicAuth part from there.

The question is how would dashboard know the right API ID? Looks like asking for right API ID in this case is something extra as gateway's API already support key retrieval without API ID - in endpoint GET /tyk/keys/{keyName}?api_id={apiID} query string param api_id can be omitted and then our logic falls back to FallbackKeySesionManager https://github.com/TykTechnologies/tyk/pull/2018/files#diff-651a84f8ad6a38c1f7ccdf63f2692410R323

[buger]

That's why I was thinking about extending Tyk Keys API, and for example, pass query attribute "?username=true" to the endpoint, and if it set, it will run logic similar to what you do in PR.

Dashboard can't know right APIID in advance.

[dencoded]

makes sense to me. just to mention - we also need OrgID to generate right token and get key from storage. I guess the assumption with this approach would be that dashboard would be still passing key as OrgID + username and ?username=true, then we can extract OrgID from that value (it has fixed length) and generate right storage key

[buger]

@dencoded makes sense to me

[dencoded]

@buger I've added boolean parameter username to endpoints:

• GET /tyk/keys/{keyName}
• PUT /tyk/keys/{keyName}
• DELETE /tyk/keys/{keyName}

username=true triggers to form correct key token with respect to current hash algo

POST /tyk/keys stays the same as we have everything to generate right key in request payload

[buger]

Exactly, instead orgid extraction logic you implemented. Also note that gateway api is an admin one, and we trust user input, so check if orgid valid also redundant.