Support api key passed as query parameter about tyk HOT 5 CLOSED

Added in master branch. Will be part of 1.6

Setting auth.use_param in an API Definition to true will have tyk look for API tokens in the requests parameters instead of the header. This is case sensitive.

from tyk.

Super. Thank you very much, Martin.

from tyk.

Would it be possible to permit both?

I've never written go before, but would something like this work?

diff --git a/middleware_auth_key.go b/middleware_auth_key.go
index 566d911..a15d820 100644
--- a/middleware_auth_key.go
+++ b/middleware_auth_key.go
@@ -52,14 +52,14 @@ func (k *AuthKey) ProcessRequest(w http.ResponseWriter, r *http.Request, configu
        thisConfig := k.TykMiddleware.Spec.APIDefinition.Auth

        authHeaderValue := r.Header.Get(thisConfig.AuthHeaderName)
-       if thisConfig.UseParam {
+       if thisConfig.UseParam && authHeaderValue = "" {
                tempRes := CopyRequest(r)

                // Set hte header name
                authHeaderValue = tempRes.FormValue(thisConfig.AuthHeaderName)
        }

-       if thisConfig.UseCookie {
+       if thisConfig.UseCookie && authHeaderValue = "" {
                tempRes := CopyRequest(r)
                authCookie, notFoundErr := tempRes.Cookie(thisConfig.AuthHeaderName)
                if notFoundErr != nil {

Ideally, I'd prefer the ability to set both a header param AND a query param that'll be accepted, so that a request could authenticate with (header) Authorization: foobar or (query) ?access_token=foobar; headers are conventionally camel cased and dash-delimited, while query params are conventionally snake cased. It's not a huge deal, but it would be a nice little extra. :)

from tyk.

@cheald It's totally possible, though I would prefer to make it an explicit configuration, either one, the other or both.

Currently, they share a configuration setting (the name of the field). This proposal would require:

• The addition of a new field in the tykcommon API Definition to hold the new data
• The modification of all the middleware and methods that extract version data (there's two I believe) to handle a new field

This would break backwards compatibility, to make it compatible, we would need to introduce behaviour that infers the correct name, i.e. some kind of "sluggifier" that converts headers (I believe these are case insensitive but make use of hyphens) into the respective querystring representation.

It's not ideal, but that's how I'd approach it to make sure it was backwards compatible without adding more data.

In V2 we can add new fields.

If this is something you want to see, open a new issue requesting the capability and it we'll get to it.

from tyk.

• 1
  We are going to need the same support for both auth-tokens in querystring and in header.

from tyk.