existing users activity to test your apps http://gortool.com • In active development for 3+ years • 5500+ stars on Github • Trusted by hundreds of companies including large ones like: TomTom, theguardian or gov.uk • Commercially supported
traffic from app running on port 80 to your staging environment Works if you app is stateless or test environment database synced with production, so all the user specific data (like user ids or api keys) are the same. https://github.com/buger/gor/wiki/Getting-Started
api-key:^(1|2|3) … Replay only traffic with api keys with values 1, 2 or 3 (accepts regex) If you can’t afford fully sync test environment with production, you can partially sync only a few accounts, and replay only their traffic Partial syncing https://github.com/buger/gor/wiki/Request-filtering
api_key=test … For all requests set api_key param to value of “test” user If test environment can’t be synced with production, even partially, you may override requests, and force headers or params to have specific values Rewriting requests https://github.com/buger/gor/wiki/Request-rewriting
payload at STDIN and emits modified requests at STDOUT. You can implement any custom logic like stripping private data, advanced rewriting, support for oAuth and etc. Middleware can access original request and response as well as replayed response, and can be written in any language Implementing custom logic https://github.com/buger/gor/wiki/Middleware
permissions 2. Server responds with dynamically generated token 3. User should provide this token on each request There is plenty of cases, usually security related, when request need to sign itself with token which was dynamically generated by server: oAuth, JWT, CSRF tokens and etc. Example workflow
can analyze responses of original and replayed requests, which contain tokens, and create map with token aliases. For all the following requests we will replace original auth tokens with their aliases from test environment. See the code: examples/middleware/token_modifier.go