Description

The plugin path was modified multiple times, ending up in a nonsensepath and not loading the plugin.

Related Issue

https://tyktech.atlassian.net/browse/TT-6668

Motivation and Context

Fix https://tyktech.atlassian.net/browse/TT-6668?focusedCommentId=30359

How This Has Been Tested

• Load plugin with prefix
• Load plugin without prefix
• Load plugin with plain name

Screenshots (if appropriate)

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [ ] Refactoring or add test (improvements in base code or adds test coverage to functionality)

Checklist

• [ ] I ensured that the documentation is up to date
• [ ] I explained why this PR updates go.mod in detail with reasoning why it's required
• [ ] I would like a code coverage CI quality gate exception and have explained why

Description

Caching for JSVM virtual endpoints doesn't work. There are two code paths to VirtualEndpoint code (JSVM).

• if caching is enabled, mw_redis_cache should be used, and
• if caching is disabled, the mw_virtual_endpoint should be used;

Ultimately it was a bug in how the RedisCacheMiddleware was implemented. It was wrapping virtual requests middleware to enable caching on them and breaking the middleware chain flow to capture the response.

• RedisCacheMiddleware was split into the "reader" and "writer" middleware;
• RedisCacheMiddleware becomes the Reader middleware, continuing the middleware chain on cache miss
• ResponseCacheMiddleware was added that saves the *http.Request into the cache at the correct end of all the middlewares (after the response processors middleware).

Minor changes and improvements have been made for type-efficient use, unit tests have been added on uncovered code, style of some functions has been improved for readability, removal of buggy-parallelism (removal of singleflight - cache reading was essentially single threaded).

Related Issue

Jira TT-6527 and GH issue https://github.com/TykTechnologies/tyk/issues/3853

Motivation and Context

How This Has Been Tested

Screenshots (if appropriate)

Types of changes

• [x] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [x] Refactoring or add test (improvements in base code or adds test coverage to functionality)

Checklist

• [x] I ensured that the documentation is up to date
• [x] I explained why this PR updates go.mod in detail with reasoning why it's required
• [ ] I would like a code coverage CI quality gate exception and have explained why

Hey,

Just want a quick thought on this. I want tyk-dashboard to run inside a Apache Web Server as I cannot open a 3000 or other ports. mod_proxy is also not working as your page might load other Urls as well. Can you tell me how can i put Dashboard under Apache web server and get access to dashboard.

This is an alternative implementation of https://github.com/TykTechnologies/tyk/pull/4215/files

Description

Reloading APIs, which use JSVM, cause gateway memory growth, and eventual crash.

Initialise JSVM only when needed

First of all I found that JSVM get initialized when ANY plugin is used. So first fix is: Initialise JSVM only when VirtualEndpoint used, or plugin with JSVM engine is used. It was done by removing initialization code from here https://github.com/TykTechnologies/tyk/compare/fix/jsvm-memory-usage?expand=1#diff-0cf80174bbafb36f6d4f4308ebbd971b2833b76a936bad568220aa1a4ba0ee8bL337-L354 And putting it after we already know plugin type https://github.com/TykTechnologies/tyk/compare/fix/jsvm-memory-usage?expand=1#diff-cdf0b7f176c9d18e1a314b78ddefc2cb3a94b3de66f1f360174692c915734c68R233-R237

Releasing pointers to easy GC

JSVM code by itself, is "a bit of" circular pointer hell. Trying to fix it leads to huge rewrite (and some parts really non obvious on how to do without having links to spec/gateway), which I do not want do as part of this PR. So now it cleanups pointers inside JSVM object, before API gets reloaded, to make GC job easier https://github.com/TykTechnologies/tyk/compare/fix/jsvm-memory-usage?expand=1#diff-78cd278aba997558b7daa7897051a794ef860076d45c93be792791db39381ca0R374-R380

Reloading only APIs which actually changed

For each API we now calculate SHA256 checksum, and if during API reload event, API has not changed, re-use already loaded API and its resources instead. https://github.com/TykTechnologies/tyk/compare/fix/jsvm-memory-usage?expand=1#diff-cdf0b7f176c9d18e1a314b78ddefc2cb3a94b3de66f1f360174692c915734c68R886-R898

How This Has Been Tested

Screenshots (if appropriate)

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [ ] Refactoring or add test (improvements in base code or adds test coverage to functionality)

Checklist

• [ ] Make sure you are requesting to pull a topic/feature/bugfix branch (right side). If pulling from your own fork, don't request your master!
• [ ] Make sure you are making a pull request against the master branch (left side). Also, you should start your branch off our latest master.
• [ ] My change requires a change to the documentation.
  • [ ] If you've changed APIs, describe what needs to be updated in the documentation.
  • [ ] If new config option added, ensure that it can be set via ENV variable
• [ ] I have updated the documentation accordingly.
• [ ] Modules and vendor dependencies have been updated; run go mod tidy && go mod vendor
• [ ] When updating library version must provide reason/explanation for this update.
• [ ] I have added tests to cover my changes.
• [ ] All new and existing tests passed.
• [ ] Check your code additions will not fail linting checks:
  • [ ] go fmt -s
  • [ ] go vet

Description

Added support to use protobuf as serialization method for the analytics. Gateway imports the implementation from tyk-pump, now you can select from msgpack and protobuf (defaults to msgpack). It will use the choosen serializer to encode the records and put them into redis, then tyk-pump will decode them and process as required. The new option added lives under analytics_config its name is serializer_type and valid values are: msgpack and protobuf

This PR also reverts the analytics pkg created in https://github.com/TykTechnologies/tyk/pull/3981 and starts using Tyk pump analytics struct. We made that change in order to start using only 1 source of truth for our analytics records.

Related Issue

TT-4698

Motivation and Context

• Be consistent on how we serialize the data
• Improve the processing time and resources
• Gain some speed

How This Has Been Tested

It should be tested in tandem with https://github.com/TykTechnologies/tyk-pump/pull/436 For instructions on how to test it refer to https://github.com/TykTechnologies/tyk-pump/pull/436 and follow the instructions

Screenshots (if appropriate)

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [x] Refactoring or add test (improvements in base code or adds test coverage to functionality)

Checklist

• [x] Make sure you are requesting to pull a topic/feature/bugfix branch (right side). If pulling from your own fork, don't request your master!
• [x] Make sure you are making a pull request against the master branch (left side). Also, you should start your branch off our latest master.
• [ ] My change requires a change to the documentation.
  • [ ] If you've changed APIs, describe what needs to be updated in the documentation.
  • [ ] If new config option added, ensure that it can be set via ENV variable
• [ ] I have updated the documentation accordingly.
• [ ] Modules and vendor dependencies have been updated; run go mod tidy && go mod vendor
• [ ] When updating library version must provide reason/explanation for this update.
• [x] I have added tests to cover my changes.
• [x] All new and existing tests passed.
• [x] Check your code additions will not fail linting checks:
  • [x] go fmt -s
  • [x] go vet

Howdy

Im trying to get tyk-gateway to validate against an OIDC access key. But im getting a panic in openid2go when its called to try to get the JWK signature verification key. But its odd because I get the panic only every 2nd call. The other call is still giving me "Key not authorised"

This is with gateway 2.2.0.3 being run form the docker image

The Panic

2016/08/17 19:50:51 http: panic serving 192.168.99.1:52583: interface conversion: interface is nil, not string
goroutine 85 [running]:
net/http.(*conn).serve.func1(0xc82046a300)
    /usr/local/go/src/net/http/server.go:1389 +0xc1
panic(0xd2c9e0, 0xc8204b92c0)
    /usr/local/go/src/runtime/panic.go:426 +0x4e9
github.com/TykTechnologies/openid2go/openid.(*idTokenValidator).renewAndGetSigningKey(0xc8203737a0, , 0x0, 0x0, 0x0)
    /home/tyk/go/src/github.com/TykTechnologies/openid2go/openid/idtokenvalidator.go:60 +0x23a
github.com/TykTechnologies/openid2go/openid.(*idTokenValidator).(github.com/TykTechnologies/openid2go/tSigningKey)-fm(0xc8200e2500, 0x0, 0x0, 0x0, 0x0)
    /home/tyk/go/src/github.com/TykTechnologies/openid2go/openid/idtokenvalidator.go:38 +0x46
github.com/dgrijalva/jwt-go.(*Parser).ParseWithClaims(0xc820140a70, 0xc820387087, 0x567, 0x7ffb6311bda8, 8200dc1a0, 0x0, 0x0, 0x0)
    /home/tyk/go/src/github.com/dgrijalva/jwt-go/parser.go:96 +0x12c3
github.com/dgrijalva/jwt-go.(*Parser).Parse(0xc820140a70, 0xc820387087, 0x567, 0xc8200dc1a0, 0xc8200e24b0, 
    /home/tyk/go/src/github.com/dgrijalva/jwt-go/parser.go:19 +0xb4
github.com/dgrijalva/jwt-go.Parse(0xc820387087, 0x567, 0xc8200dc1a0, 0xc8200e24b0, 0x0, 0x0)
    /home/tyk/go/src/github.com/dgrijalva/jwt-go/token.go:89 +0x6a
github.com/TykTechnologies/openid2go/openid.(*idTokenValidator).validate(0xc8203737a0, 0xc820387087, 0x567, 
    /home/tyk/go/src/github.com/TykTechnologies/openid2go/openid/idtokenvalidator.go:38 +0x141
github.com/TykTechnologies/openid2go/openid.authenticate(0xc820373760, 0x7ffb6311bd48, 0xc8203b4b60, 82038a030, 0x7)
    /home/tyk/go/src/github.com/TykTechnologies/openid2go/openid/middleware.go:115 +0x117
github.com/TykTechnologies/openid2go/openid.authenticateUserWithToken(0xc820373760, 0x7ffb6311bd48, 8204ee460, 0x0, 0x0, 0x13f0ea8)
    /home/tyk/go/src/github.com/TykTechnologies/openid2go/openid/middleware.go:157 +0x5e
github.com/TykTechnologies/openid2go/openid.AuthenticateOIDWithUser(0xc820373760, 0x7ffb6311bd48, 8204ee460, 0xbca660, 0xc8200e7818, 0x0)
    /home/tyk/go/src/github.com/TykTechnologies/openid2go/openid/middleware.go:91 +0x3f
main.(*OpenIDMW).ProcessRequest(0xc820373740, 0x7ffb6311bd48, 0xc8203b4b60, 0xc8204ee460, 0x0, 0x0, 0x0, 0x0, 
    /home/tyk/go/src/github.com/lonelycode/tyk/middleware_openid.go:91 +0xb3
main.CreateMiddleware.func1.1(0x7ffb6311bd48, 0xc8203b4b60, 0xc8204ee460)
    /home/tyk/go/src/github.com/lonelycode/tyk/middleware.go:44 +0x178
net/http.HandlerFunc.ServeHTTP(0xc8203926c0, 0x7ffb6311bd48, 0xc8203b4b60, 0xc8204ee460)
    /usr/local/go/src/net/http/server.go:1618 +0x3a
main.CreateMiddleware.func1.1(0x7ffb6311bd48, 0xc8203b4b60, 0xc8204ee460)
    /home/tyk/go/src/github.com/lonelycode/tyk/middleware.go:61 +0x38b
net/http.HandlerFunc.ServeHTTP(0xc820392700, 0x7ffb6311bd48, 0xc8203b4b60, 0xc8204ee460)
    /usr/local/go/src/net/http/server.go:1618 +0x3a
main.CreateMiddleware.func1.1(0x7ffb6311bd48, 0xc8203b4b60, 0xc8204ee460)
    /home/tyk/go/src/github.com/lonelycode/tyk/middleware.go:61 +0x38b
net/http.HandlerFunc.ServeHTTP(0xc820392740, 0x7ffb6311bd48, 0xc8203b4b60, 0xc8204ee460)
    /usr/local/go/src/net/http/server.go:1618 +0x3a
main.CreateMiddleware.func1.1(0x7ffb6311bd48, 0xc8203b4b60, 0xc8204ee460)
    /home/tyk/go/src/github.com/lonelycode/tyk/middleware.go:61 +0x38b
net/http.HandlerFunc.ServeHTTP(0xc820392780, 0x7ffb6311bd48, 0xc8203b4b60, 0xc8204ee460)
    /usr/local/go/src/net/http/server.go:1618 +0x3a
main.CreateMiddleware.func1.1(0x7ffb6311bd48, 0xc8203b4b60, 0xc8204ee460)
    /home/tyk/go/src/github.com/lonelycode/tyk/middleware.go:61 +0x38b
net/http.HandlerFunc.ServeHTTP(0xc8203927c0, 0x7ffb6311bd48, 0xc8203b4b60, 0xc8204ee460)
    /usr/local/go/src/net/http/server.go:1618 +0x3a
github.com/gorilla/mux.(*Router).ServeHTTP(0xc820274c80, 0x7ffb6311bd48, 0xc8203b4b60, 0xc8204ee460)
    /home/tyk/go/src/github.com/gorilla/mux/mux.go:98 +0x29e
net/http.(*ServeMux).ServeHTTP(0xc820010e70, 0x7ffb6311bd48, 0xc8203b4b60, 0xc8204ee460)
    /usr/local/go/src/net/http/server.go:1910 +0x17d
net/http.serverHandler.ServeHTTP(0xc820363380, 0x7ffb6311bd48, 0xc8203b4b60, 0xc8204ee460)
    /usr/local/go/src/net/http/server.go:2081 +0x19e
net/http.(*conn).serve(0xc82046a300)
    /usr/local/go/src/net/http/server.go:1472 +0xf2e
created by net/http.(*Server).Serve
    /usr/local/go/src/net/http/server.go:2137 +0x44e

The non-panic response:

time="Aug 17 19:32:36" level=warning msg="JWT Invalid: Validation error. Jwt token validation failed."
time="Aug 17 19:32:36" level=warning msg="Attempted access with invalid key." key="[JWT]"
time="Aug 17 19:32:36" level=error msg="request error: Key not authorised" api_id=1 org_id=1 path="/ip" server_name="http://httpbin.org/" user_id= user_ip=192.168.99.1

The API is has the following config

{
  "name": "Test API",
  "slug": "test-api",
  "api_id": "1",
  "org_id": "1",
  "auth": {
    "auth_header_name": "Authorization"
  },
  "definition": {
    "location": "header",
    "key": "x-api-version"
  },
  "version_data": {
    "not_versioned": true,
    "versions": {
      "Default": {
        "name": "Default",
        "use_extended_paths": true
      }
    }
  },
  "proxy": {
    "listen_path": "/test-api/",
    "target_url": "http://httpbin.org/",
    "strip_listen_path": true
  },
  "active": true,
  "use_openid": true,
  "openid_options": {
    "providers": [
      {
        "issuer": "https://out-keycloak-url/auth/realms/adfs",
        "client_ids": {
          "c2FtcGxlX2xvZ2lu": "default"
        }
      }
    ],
    "segregate_by_client": false
  }
}

Im using Keycloak as the OIDC provider and I have it working elsewhere.

Description

When create custom key in slave node, we must ensure that the hash is the same as in the master node, otherwise we could face issues updating and deleting tokens. Also in this PR was solved an issue where we would end up having 2 keys in redis when we used the key (when we used the key then a new key and quota key were registered)

Related Issue

• https://tyktech.atlassian.net/browse/TT-2820
• https://tyktech.atlassian.net/browse/TT-2639

Motivation and Context

Fix CRUD of custom keys in slave nodes. Prevent the creation of 2 keys

How This Has Been Tested

Replicating the steps to reproduce the bug

Screenshots (if appropriate)

Types of changes

• [x] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [ ] Refactoring or add test (improvements in base code or adds test coverage to functionality)

Checklist

• [x] Make sure you are requesting to pull a topic/feature/bugfix branch (right side). If pulling from your own fork, don't request your master!
• [x] Make sure you are making a pull request against the master branch (left side). Also, you should start your branch off our latest master.
• [ ] My change requires a change to the documentation.
  • [ ] If you've changed APIs, describe what needs to be updated in the documentation.
  • [ ] If new config option added, ensure that it can be set via ENV variable
• [ ] I have updated the documentation accordingly.
• [ ] Modules and vendor dependencies have been updated; run go mod tidy && go mod vendor
• [ ] When updating library version must provide reason/explanation for this update.
• [ ] I have added tests to cover my changes.
• [x] All new and existing tests passed.
• [x] Check your code additions will not fail linting checks:
  • [x] go fmt -s
  • [x] go vet

First off, I know that there is a OAuth issue on https://trello.com/b/59d5kAZ5/tyk-api-gateway-roadmap . This is mainly for clarification/documentation purposes.

What do you believe to be the current state of the OAuth 2 flow? We are in the process of evaluating different API gateways, and need them to fully support OAuth 2 in production with several million API calls a month.

Needed features

• Password Grant flow
• Implicit Grant flow
• Authorization Code flow
• Client Credentials flow
• Ability to revoke refresh and access tokens

Of the above, it looked like to us that client credentials is missing from the current feature set. Is our conclusion correct? Furthermore, the we didn't see any support for refresh tokens either or revoking tokens based on a certain criteria (the authenticated user, for example).

Your perspective on this would be much appreciated. The OAuth implementations of every other API gateway are incredibly young. A good implementation would set this project above the rest. If you have a general idea of what you planned out for this and were to note your plan here, I might be able to code up a pull request.

Do you want to request a feature or report a bug? bug

What is the current behavior? If I run many hot-reloads (in this case I had removed the timer functionality that introduces limits on how many reloads you can run one after the other) then I can see memory consumption gradually increase with each reload. This behaviour is worse when the JSVM is enabled.

When the reloads stopped, the RES and VIRT memory figures did not reduce back down

What is the expected behavior? The memory should be reclaimed

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

1. Set "reload_wait_time": 1 in tyk.conf
2. Comment out time.Sleep(10 * time.Second) in main.go in funvtion doReload()
3. Compile and run
4. Run a looped script that will call many hot reloads:

#!/bin/bash
while [ 1 ]
do
        curl -H "x-tyk-authorization: $SECRET" http://$TYK_GATEWEAY:8181/tyk/reload/group
        sleep .5
done

5. Monitor the memory consumption (in this case, without JSVM it required about 2,600 iterations) to from a standing amount (279M or so) to 500M

This isn't so bad as Gateways will not hot reload that often, and when they do, they do not do so very quickly right after each other, however it is concerning that the memory is not being reclaimed by the OS and in the long term could cause issues for the user.

This also affect RPC reloads (MDCB).

Which versions of Tyk affected by this issue? Did this work in previous versions of Tyk? 2.3.2

Description

The gateway provided segmentation tags behavior as an always-enabled option. In order to implement a config flag that wouldn't change existing behavior, "tags_disabled" was implemented. When converting between OAS and the Tyk API Definition, this means that the configuration flag for the tags is copied between the two API definitions. This means what is disabled=false for tags in the tyk apidef becomes enabled=true in the OAS document.

This adds a cleanup for the OAS document that removes the gatewayTags entry if either the tags are disabled, or if they are enabled and no tags are defined (length=0).

Related Issue

https://tyktech.atlassian.net/browse/TT-5718

Motivation and Context

How This Has Been Tested

Screenshots (if appropriate)

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [ ] Refactoring or add test (improvements in base code or adds test coverage to functionality)

Checklist

• [ ] Make sure you are requesting to pull a topic/feature/bugfix branch (right side). If pulling from your own fork, don't request your master!
• [ ] Make sure you are making a pull request against the master branch (left side). Also, you should start your branch off our latest master.
• [ ] My change requires a change to the documentation.
  • [ ] If you've changed APIs, describe what needs to be updated in the documentation.
  • [ ] If new config option added, ensure that it can be set via ENV variable
• [ ] I have updated the documentation accordingly.
• [ ] Modules and vendor dependencies have been updated; run go mod tidy && go mod vendor
• [ ] When updating library version must provide reason/explanation for this update.
• [ ] I have added tests to cover my changes.
• [ ] All new and existing tests passed.
• [ ] Check your code additions will not fail linting checks:
  • [ ] go fmt -s
  • [ ] go vet

Description

In order to support plugins with multiple tyk versions then was added a logic on how to load them using information such as: tyk version, operative system and architecture in which its running. The load Go Plugin logic will find first if there's an exact match with the provided path, if that file doesn't exist then it will build a path+pluginName like this:

1- Gather information like: os, tyk version and architecture 2- Obtain the clean name of the plugin 3- Obtain the directory where the plugins are stored 4- Build a new plugin name in the format: {plugin-dir}/{plugin-name}_{GW-version}_{OS}_{arch}.so 5- Load the plugin using the new name

Related Issue

https://tyktech.atlassian.net/browse/TT-4354

Motivation and Context

Allow users to upload multiple version of a go plugin, and load it based on where its running

How This Has Been Tested

• created go plugin following the instructions available in https://tyk.io/docs/plugins/supported-languages/golang/#plugin-development-flow
• Created api and added a plugin like:

 "custom_middleware": {
      "pre": [],
      "post": [
        {
          "name": "AddFooBarHeader",
          "path": "./mygoplugin/mygoplugin.so",
          "require_session": false,
          "raw_body_only": false
        }
      ],
      "post_key_auth": [],
      "auth_check": {
        "name": "",
        "path": "",
        "require_session": false,
        "raw_body_only": false
      },
      "response": [],
      "driver": "goplugin",
      "id_extractor": {
        "extract_from": "",
        "extract_with": "",
        "extractor_config": {}
      }
    },

• Name the plugin: mygoplugin_v4.1.0_darwin_amd64.so
• Curl the api: curl -i http://tyk-gateway:8081/goplugin/get
• In the result I can see the header Foo: Bar

Testing the Plugin compiler Now the plugin compiler have the ability to generate the plugins with the name format set as explained above, in order to test it we need to create the plugin and check that the name is set as expected. The plugin compiler have the ability to receive by params the OS and Arch as 3rd and 4th param. To test, lets do:

• Create the plugin directory
• go mod init tyk_plugin
• go mod edit -replace github.com/jensneuse/graphql-go-tools=github.com/TykTechnologies/[email protected]
• go get github.com/TykTechnologies/[email protected]
• Write the plugin following the instructions of https://tyk.io/docs/3-lts/plugins/supported-languages/golang/#write-the-plugin
• Then, to build the plugin lets use the docker image: tykio/tyk-plugin-compiler:v4.1.0-rc3 and at this point we need to test it in 2 ways: sending the arch and os, and not sending thos params:

1- Sending OS/Arch (Skip this section as cross compilation is not working):

• Type docker run --rm -vpwd:/plugin-source tykio/tyk-plugin-compiler:v4.1.0-rc5 plugin.so pluginid testOS testArch and as output it will generate a file named: plugin_v4.1.0_testOS_testArch.so The bad side of this approach is that is always required to send a pluginID.

If we attempt to send an invalid OS or arch, we will receive a message like this:

2- Without sending the OS/Arch:

• Type docker run --rm -vpwd:/plugin-source tykio/tyk-plugin-compiler:v4.1.0-rc5 plugin.so as the docker container is running linux it will detect that OS and architecture and will create a file with a name like: plugin_v4.1.0_linux_amd64.so

Screenshots (if appropriate)

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [ ] Refactoring or add test (improvements in base code or adds test coverage to functionality)

Checklist

• [x] Make sure you are requesting to pull a topic/feature/bugfix branch (right side). If pulling from your own fork, don't request your master!
• [x] Make sure you are making a pull request against the master branch (left side). Also, you should start your branch off our latest master.
• [ ] My change requires a change to the documentation.
  • [ ] If you've changed APIs, describe what needs to be updated in the documentation.
  • [ ] If new config option added, ensure that it can be set via ENV variable
• [ ] I have updated the documentation accordingly.
• [ ] Modules and vendor dependencies have been updated; run go mod tidy && go mod vendor
• [ ] When updating library version must provide reason/explanation for this update.
• [x] I have added tests to cover my changes.
• [ ] All new and existing tests passed.
• [x] Check your code additions will not fail linting checks:
  • [x] go fmt -s
  • [x] go vet

[changelog] fixed: force synchronization for the edge group when slave_options.synchroniser_enabled is set to true.

Description

This PR adds a new groupLogin callback function for RPC connections when slave_options.synchroniser_enabled=true. This changes the groupLogin function, adding an extra param to force the group synchronization in MDCB. It also adds a sync group key in Redis for the group to avoid multiple synchronizations force.

This is complementary to the work done in https://github.com/TykTechnologies/tyk-sink/pull/307

Related Issue

https://tyktech.atlassian.net/browse/TT-6968

Motivation and Context

https://tyktech.atlassian.net/browse/TT-6968

How This Has Been Tested

Added unit tests

Screenshots (if appropriate)

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [ ] Refactoring or add test (improvements in base code or adds test coverage to functionality)

Checklist

• [ ] I ensured that the documentation is up to date
• [ ] I explained why this PR updates go.mod in detail with reasoning why it's required
• [ ] I would like a code coverage CI quality gate exception and have explained why

TT-7455 Delete golangci-lint github action (#4597)

Description

This PR removes the duplicate/misconfigured golangci-lint github action.

Related Issue

https://tyktech.atlassian.net/browse/TT-7455

Motivation and Context

Housekeeping GH actions:

1. We already have a golangci-lint action in ci-tests, which nicely surfaces issues in sonarcloud,
2. Failure from GH action being removed doesn't produce file/line info for errors (misconfiguration?)
3. Github Actions reuse (in future).

Removing this workflow doesn't hurt us, as we cover raising of errors in CI Tests.

https://github.com/TykTechnologies/tyk/actions/runs/3795785568/jobs/6455252799#step:3:87

How This Has Been Tested

Screenshots (if appropriate)

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [x] Refactoring or add test (improvements in base code or adds test coverage to functionality)

Checklist

• [ ] I ensured that the documentation is up to date
• [ ] I explained why this PR updates go.mod in detail with reasoning why it's required
• [ ] I would like a code coverage CI quality gate exception and have explained why

Co-authored-by: Tit Petric [email protected]

TT-7455 Delete golangci-lint github action (#4597)

Description

This PR removes the duplicate/misconfigured golangci-lint github action.

Related Issue

https://tyktech.atlassian.net/browse/TT-7455

Motivation and Context

Housekeeping GH actions:

1. We already have a golangci-lint action in ci-tests, which nicely surfaces issues in sonarcloud,
2. Failure from GH action being removed doesn't produce file/line info for errors (misconfiguration?)
3. Github Actions reuse (in future).

Removing this workflow doesn't hurt us, as we cover raising of errors in CI Tests.

https://github.com/TykTechnologies/tyk/actions/runs/3795785568/jobs/6455252799#step:3:87

How This Has Been Tested

Screenshots (if appropriate)

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [x] Refactoring or add test (improvements in base code or adds test coverage to functionality)

Checklist

• [ ] I ensured that the documentation is up to date
• [ ] I explained why this PR updates go.mod in detail with reasoning why it's required
• [ ] I would like a code coverage CI quality gate exception and have explained why

Co-authored-by: Tit Petric [email protected]

Description

Related Issue

Motivation and Context

How This Has Been Tested

Screenshots (if appropriate)

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [ ] Refactoring or add test (improvements in base code or adds test coverage to functionality)

Checklist

• [ ] I ensured that the documentation is up to date
• [ ] I explained why this PR updates go.mod in detail with reasoning why it's required
• [ ] I would like a code coverage CI quality gate exception and have explained why