Add extended routing capability, fixes #639 #1146
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@buger @lonelycode I'm discussing about the UX with @nickReyn @ViolaMarku already, but can you please enable the dashboard api for this functionality, or let me know where will these data sit in the existing Dashboard API responses (I'm assuming in the api designer object at |
|
There is no dashboard API needed here. The example you see here is part of API definitions url_rewrites object, mentioned by you. |
|
@lonelycode @buger @lghiur I've sketched out the below for how I see this could work. Can you guys take a look and feedback thoughts pls. In terms of how a user get's to this, i see a few options. Number 1 is my preferred.
I'm not sure if there are different fields that need to show up if a user selects one of the other
|
|
Round two of this based on feedback from @lghiur and @buger. This will be another plugin on the Endpoint designer, because it's too complex to create it as an extension of the current URL rewrites functionality, as discussed with Leon. Check out a simple flow here: https://www.figma.com/proto/JJXxlc0Cr7yKaHgAYWSx2kRR/Routing-rules?scaling=contain&node-id=49%3A18&redirected=1 |
|
@buger @lghiur and I had some slack convos about this and decided it's not ideal to have another plugin for this. I propose we have it as a separate section below the standard url rewrites which is activated on checkbox, labelled "Enable advanced url rewrites". The flow is here: https://www.figma.com/proto/JJXxlc0Cr7yKaHgAYWSx2kRR/Routing-rules?scaling=contain&node-id=86%3A2 |
|
@lonelycode @buger |
|
Will check |
|
@lghiur works fine for me. How do you run it, using dev env via docker? For some reason, it does not see changes in "apidef". If you trying to use this new fields in dashboard, you should govendor new Going to merge this server-side PR. |
letzya
pushed a commit
that referenced
this pull request
Jan 11, 2018
Fixed #639 This PR adds rewrite "triggers" on top of the existing rewrite functionality. These are essentially sub-matches to allow a rewrite rule to have variations. For example, for the URL `/foo/bar/baz` I want to rewrite to `/fooble/barble/bazble` if the query string variable `culprit` is set to `kronk`, but I want to redirect to `/foozle/barzle/bazzle` if the variable `culprit` is set to `yzma`. I can do this with the new URL Rewriter as follows: ``` { "url_rewrites": [ { "path": "/foo/bar/baz", "method": "GET", "match_pattern": "/foo/bar/baz", "rewrite_to": "/foo/bar/baz", "triggers": [ { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "kronk" } } } "rewrite_to": "/fooble/barble/bazble" } { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "yzma" } } } "rewrite_to": "/foozle/barzle/bazzle" } ] } ] } ``` Here if there is no trigger match, the rwrite will fallback to the parent `rewrite_to`, but if either of the other two are triggered, the rewrite target is changed. Each trigger also sets a context variable for each match it finds, these context vars can then be used in the rewrites, so the above example with context vars could be rewritten to: ``` { "url_rewrites": [ { "path": "/foo/bar/baz", "method": "GET", "match_pattern": "/foo/bar/baz", "rewrite_to": "/foo/bar/baz", "triggers": [ { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "kronk" } } } "rewrite_to": "/fooble/barble/bazble?victim=$tyk_context.trigger-0-culprit-0" } { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "yzma" } } } "rewrite_to": "/foozle/barzle/bazzle?victim=$tyk_context.trigger-1-culprit-0" } ] } ] } ``` Trigger contexts take the format: `$tyk_context.trigger-{n}-{name}-{i}` where `n` is the trigger index in the array, `nam` is the rx matcher name and `i` is the index of that match (since querystrings and headers can be arrays of values). The Trigger functionality supports: 1. Header matches 2. Query string variable/value matches 3. Path part matches, i.e. components of the path itself 4. Session meta data values 5. Payload matches For each trigger, the trigger can either use the `on: any` or `on: all` formatting, for `any`, if any one of the options in the trigger is true, the rewrite rule is fired. for `all`, all the options must be satisfied. This is limited to triggers, not groups of triggers, these will be evaluated one by one.
letzya
pushed a commit
that referenced
this pull request
Jan 11, 2018
Fixed #639 This PR adds rewrite "triggers" on top of the existing rewrite functionality. These are essentially sub-matches to allow a rewrite rule to have variations. For example, for the URL `/foo/bar/baz` I want to rewrite to `/fooble/barble/bazble` if the query string variable `culprit` is set to `kronk`, but I want to redirect to `/foozle/barzle/bazzle` if the variable `culprit` is set to `yzma`. I can do this with the new URL Rewriter as follows: ``` { "url_rewrites": [ { "path": "/foo/bar/baz", "method": "GET", "match_pattern": "/foo/bar/baz", "rewrite_to": "/foo/bar/baz", "triggers": [ { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "kronk" } } } "rewrite_to": "/fooble/barble/bazble" } { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "yzma" } } } "rewrite_to": "/foozle/barzle/bazzle" } ] } ] } ``` Here if there is no trigger match, the rwrite will fallback to the parent `rewrite_to`, but if either of the other two are triggered, the rewrite target is changed. Each trigger also sets a context variable for each match it finds, these context vars can then be used in the rewrites, so the above example with context vars could be rewritten to: ``` { "url_rewrites": [ { "path": "/foo/bar/baz", "method": "GET", "match_pattern": "/foo/bar/baz", "rewrite_to": "/foo/bar/baz", "triggers": [ { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "kronk" } } } "rewrite_to": "/fooble/barble/bazble?victim=$tyk_context.trigger-0-culprit-0" } { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "yzma" } } } "rewrite_to": "/foozle/barzle/bazzle?victim=$tyk_context.trigger-1-culprit-0" } ] } ] } ``` Trigger contexts take the format: `$tyk_context.trigger-{n}-{name}-{i}` where `n` is the trigger index in the array, `nam` is the rx matcher name and `i` is the index of that match (since querystrings and headers can be arrays of values). The Trigger functionality supports: 1. Header matches 2. Query string variable/value matches 3. Path part matches, i.e. components of the path itself 4. Session meta data values 5. Payload matches For each trigger, the trigger can either use the `on: any` or `on: all` formatting, for `any`, if any one of the options in the trigger is true, the rewrite rule is fired. for `all`, all the options must be satisfied. This is limited to triggers, not groups of triggers, these will be evaluated one by one.
|
How can I add this feature to my APIs? |
|
The documentation will be released with v2.5 |
letzya
pushed a commit
that referenced
this pull request
Jan 12, 2018
Fixed #639 This PR adds rewrite "triggers" on top of the existing rewrite functionality. These are essentially sub-matches to allow a rewrite rule to have variations. For example, for the URL `/foo/bar/baz` I want to rewrite to `/fooble/barble/bazble` if the query string variable `culprit` is set to `kronk`, but I want to redirect to `/foozle/barzle/bazzle` if the variable `culprit` is set to `yzma`. I can do this with the new URL Rewriter as follows: ``` { "url_rewrites": [ { "path": "/foo/bar/baz", "method": "GET", "match_pattern": "/foo/bar/baz", "rewrite_to": "/foo/bar/baz", "triggers": [ { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "kronk" } } } "rewrite_to": "/fooble/barble/bazble" } { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "yzma" } } } "rewrite_to": "/foozle/barzle/bazzle" } ] } ] } ``` Here if there is no trigger match, the rwrite will fallback to the parent `rewrite_to`, but if either of the other two are triggered, the rewrite target is changed. Each trigger also sets a context variable for each match it finds, these context vars can then be used in the rewrites, so the above example with context vars could be rewritten to: ``` { "url_rewrites": [ { "path": "/foo/bar/baz", "method": "GET", "match_pattern": "/foo/bar/baz", "rewrite_to": "/foo/bar/baz", "triggers": [ { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "kronk" } } } "rewrite_to": "/fooble/barble/bazble?victim=$tyk_context.trigger-0-culprit-0" } { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "yzma" } } } "rewrite_to": "/foozle/barzle/bazzle?victim=$tyk_context.trigger-1-culprit-0" } ] } ] } ``` Trigger contexts take the format: `$tyk_context.trigger-{n}-{name}-{i}` where `n` is the trigger index in the array, `nam` is the rx matcher name and `i` is the index of that match (since querystrings and headers can be arrays of values). The Trigger functionality supports: 1. Header matches 2. Query string variable/value matches 3. Path part matches, i.e. components of the path itself 4. Session meta data values 5. Payload matches For each trigger, the trigger can either use the `on: any` or `on: all` formatting, for `any`, if any one of the options in the trigger is true, the rewrite rule is fired. for `all`, all the options must be satisfied. This is limited to triggers, not groups of triggers, these will be evaluated one by one.
letzya
pushed a commit
that referenced
this pull request
Jan 12, 2018
Fixed #639 This PR adds rewrite "triggers" on top of the existing rewrite functionality. These are essentially sub-matches to allow a rewrite rule to have variations. For example, for the URL `/foo/bar/baz` I want to rewrite to `/fooble/barble/bazble` if the query string variable `culprit` is set to `kronk`, but I want to redirect to `/foozle/barzle/bazzle` if the variable `culprit` is set to `yzma`. I can do this with the new URL Rewriter as follows: ``` { "url_rewrites": [ { "path": "/foo/bar/baz", "method": "GET", "match_pattern": "/foo/bar/baz", "rewrite_to": "/foo/bar/baz", "triggers": [ { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "kronk" } } } "rewrite_to": "/fooble/barble/bazble" } { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "yzma" } } } "rewrite_to": "/foozle/barzle/bazzle" } ] } ] } ``` Here if there is no trigger match, the rwrite will fallback to the parent `rewrite_to`, but if either of the other two are triggered, the rewrite target is changed. Each trigger also sets a context variable for each match it finds, these context vars can then be used in the rewrites, so the above example with context vars could be rewritten to: ``` { "url_rewrites": [ { "path": "/foo/bar/baz", "method": "GET", "match_pattern": "/foo/bar/baz", "rewrite_to": "/foo/bar/baz", "triggers": [ { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "kronk" } } } "rewrite_to": "/fooble/barble/bazble?victim=$tyk_context.trigger-0-culprit-0" } { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "yzma" } } } "rewrite_to": "/foozle/barzle/bazzle?victim=$tyk_context.trigger-1-culprit-0" } ] } ] } ``` Trigger contexts take the format: `$tyk_context.trigger-{n}-{name}-{i}` where `n` is the trigger index in the array, `nam` is the rx matcher name and `i` is the index of that match (since querystrings and headers can be arrays of values). The Trigger functionality supports: 1. Header matches 2. Query string variable/value matches 3. Path part matches, i.e. components of the path itself 4. Session meta data values 5. Payload matches For each trigger, the trigger can either use the `on: any` or `on: all` formatting, for `any`, if any one of the options in the trigger is true, the rewrite rule is fired. for `all`, all the options must be satisfied. This is limited to triggers, not groups of triggers, these will be evaluated one by one.
letzya
pushed a commit
that referenced
this pull request
Jan 12, 2018
Fixed #639 This PR adds rewrite "triggers" on top of the existing rewrite functionality. These are essentially sub-matches to allow a rewrite rule to have variations. For example, for the URL `/foo/bar/baz` I want to rewrite to `/fooble/barble/bazble` if the query string variable `culprit` is set to `kronk`, but I want to redirect to `/foozle/barzle/bazzle` if the variable `culprit` is set to `yzma`. I can do this with the new URL Rewriter as follows: ``` { "url_rewrites": [ { "path": "/foo/bar/baz", "method": "GET", "match_pattern": "/foo/bar/baz", "rewrite_to": "/foo/bar/baz", "triggers": [ { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "kronk" } } } "rewrite_to": "/fooble/barble/bazble" } { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "yzma" } } } "rewrite_to": "/foozle/barzle/bazzle" } ] } ] } ``` Here if there is no trigger match, the rwrite will fallback to the parent `rewrite_to`, but if either of the other two are triggered, the rewrite target is changed. Each trigger also sets a context variable for each match it finds, these context vars can then be used in the rewrites, so the above example with context vars could be rewritten to: ``` { "url_rewrites": [ { "path": "/foo/bar/baz", "method": "GET", "match_pattern": "/foo/bar/baz", "rewrite_to": "/foo/bar/baz", "triggers": [ { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "kronk" } } } "rewrite_to": "/fooble/barble/bazble?victim=$tyk_context.trigger-0-culprit-0" } { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "yzma" } } } "rewrite_to": "/foozle/barzle/bazzle?victim=$tyk_context.trigger-1-culprit-0" } ] } ] } ``` Trigger contexts take the format: `$tyk_context.trigger-{n}-{name}-{i}` where `n` is the trigger index in the array, `nam` is the rx matcher name and `i` is the index of that match (since querystrings and headers can be arrays of values). The Trigger functionality supports: 1. Header matches 2. Query string variable/value matches 3. Path part matches, i.e. components of the path itself 4. Session meta data values 5. Payload matches For each trigger, the trigger can either use the `on: any` or `on: all` formatting, for `any`, if any one of the options in the trigger is true, the rewrite rule is fired. for `all`, all the options must be satisfied. This is limited to triggers, not groups of triggers, these will be evaluated one by one.
letzya
pushed a commit
that referenced
this pull request
Jan 12, 2018
Fixed #639 This PR adds rewrite "triggers" on top of the existing rewrite functionality. These are essentially sub-matches to allow a rewrite rule to have variations. For example, for the URL `/foo/bar/baz` I want to rewrite to `/fooble/barble/bazble` if the query string variable `culprit` is set to `kronk`, but I want to redirect to `/foozle/barzle/bazzle` if the variable `culprit` is set to `yzma`. I can do this with the new URL Rewriter as follows: ``` { "url_rewrites": [ { "path": "/foo/bar/baz", "method": "GET", "match_pattern": "/foo/bar/baz", "rewrite_to": "/foo/bar/baz", "triggers": [ { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "kronk" } } } "rewrite_to": "/fooble/barble/bazble" } { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "yzma" } } } "rewrite_to": "/foozle/barzle/bazzle" } ] } ] } ``` Here if there is no trigger match, the rwrite will fallback to the parent `rewrite_to`, but if either of the other two are triggered, the rewrite target is changed. Each trigger also sets a context variable for each match it finds, these context vars can then be used in the rewrites, so the above example with context vars could be rewritten to: ``` { "url_rewrites": [ { "path": "/foo/bar/baz", "method": "GET", "match_pattern": "/foo/bar/baz", "rewrite_to": "/foo/bar/baz", "triggers": [ { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "kronk" } } } "rewrite_to": "/fooble/barble/bazble?victim=$tyk_context.trigger-0-culprit-0" } { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "yzma" } } } "rewrite_to": "/foozle/barzle/bazzle?victim=$tyk_context.trigger-1-culprit-0" } ] } ] } ``` Trigger contexts take the format: `$tyk_context.trigger-{n}-{name}-{i}` where `n` is the trigger index in the array, `nam` is the rx matcher name and `i` is the index of that match (since querystrings and headers can be arrays of values). The Trigger functionality supports: 1. Header matches 2. Query string variable/value matches 3. Path part matches, i.e. components of the path itself 4. Session meta data values 5. Payload matches For each trigger, the trigger can either use the `on: any` or `on: all` formatting, for `any`, if any one of the options in the trigger is true, the rewrite rule is fired. for `all`, all the options must be satisfied. This is limited to triggers, not groups of triggers, these will be evaluated one by one.
letzya
pushed a commit
that referenced
this pull request
Jan 12, 2018
Fixed #639 This PR adds rewrite "triggers" on top of the existing rewrite functionality. These are essentially sub-matches to allow a rewrite rule to have variations. For example, for the URL `/foo/bar/baz` I want to rewrite to `/fooble/barble/bazble` if the query string variable `culprit` is set to `kronk`, but I want to redirect to `/foozle/barzle/bazzle` if the variable `culprit` is set to `yzma`. I can do this with the new URL Rewriter as follows: ``` { "url_rewrites": [ { "path": "/foo/bar/baz", "method": "GET", "match_pattern": "/foo/bar/baz", "rewrite_to": "/foo/bar/baz", "triggers": [ { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "kronk" } } } "rewrite_to": "/fooble/barble/bazble" } { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "yzma" } } } "rewrite_to": "/foozle/barzle/bazzle" } ] } ] } ``` Here if there is no trigger match, the rwrite will fallback to the parent `rewrite_to`, but if either of the other two are triggered, the rewrite target is changed. Each trigger also sets a context variable for each match it finds, these context vars can then be used in the rewrites, so the above example with context vars could be rewritten to: ``` { "url_rewrites": [ { "path": "/foo/bar/baz", "method": "GET", "match_pattern": "/foo/bar/baz", "rewrite_to": "/foo/bar/baz", "triggers": [ { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "kronk" } } } "rewrite_to": "/fooble/barble/bazble?victim=$tyk_context.trigger-0-culprit-0" } { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "yzma" } } } "rewrite_to": "/foozle/barzle/bazzle?victim=$tyk_context.trigger-1-culprit-0" } ] } ] } ``` Trigger contexts take the format: `$tyk_context.trigger-{n}-{name}-{i}` where `n` is the trigger index in the array, `nam` is the rx matcher name and `i` is the index of that match (since querystrings and headers can be arrays of values). The Trigger functionality supports: 1. Header matches 2. Query string variable/value matches 3. Path part matches, i.e. components of the path itself 4. Session meta data values 5. Payload matches For each trigger, the trigger can either use the `on: any` or `on: all` formatting, for `any`, if any one of the options in the trigger is true, the rewrite rule is fired. for `all`, all the options must be satisfied. This is limited to triggers, not groups of triggers, these will be evaluated one by one.
excieve
pushed a commit
to excieve/tyk
that referenced
this pull request
Feb 9, 2018
…logies#1146) Fixed TykTechnologies#639 This PR adds rewrite "triggers" on top of the existing rewrite functionality. These are essentially sub-matches to allow a rewrite rule to have variations. For example, for the URL `/foo/bar/baz` I want to rewrite to `/fooble/barble/bazble` if the query string variable `culprit` is set to `kronk`, but I want to redirect to `/foozle/barzle/bazzle` if the variable `culprit` is set to `yzma`. I can do this with the new URL Rewriter as follows: ``` { "url_rewrites": [ { "path": "/foo/bar/baz", "method": "GET", "match_pattern": "/foo/bar/baz", "rewrite_to": "/foo/bar/baz", "triggers": [ { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "kronk" } } } "rewrite_to": "/fooble/barble/bazble" } { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "yzma" } } } "rewrite_to": "/foozle/barzle/bazzle" } ] } ] } ``` Here if there is no trigger match, the rwrite will fallback to the parent `rewrite_to`, but if either of the other two are triggered, the rewrite target is changed. Each trigger also sets a context variable for each match it finds, these context vars can then be used in the rewrites, so the above example with context vars could be rewritten to: ``` { "url_rewrites": [ { "path": "/foo/bar/baz", "method": "GET", "match_pattern": "/foo/bar/baz", "rewrite_to": "/foo/bar/baz", "triggers": [ { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "kronk" } } } "rewrite_to": "/fooble/barble/bazble?victim=$tyk_context.trigger-0-culprit-0" } { "on": "any", "options": { "query_val_matches": { "culprit": { match_rx": "yzma" } } } "rewrite_to": "/foozle/barzle/bazzle?victim=$tyk_context.trigger-1-culprit-0" } ] } ] } ``` Trigger contexts take the format: `$tyk_context.trigger-{n}-{name}-{i}` where `n` is the trigger index in the array, `nam` is the rx matcher name and `i` is the index of that match (since querystrings and headers can be arrays of values). The Trigger functionality supports: 1. Header matches 2. Query string variable/value matches 3. Path part matches, i.e. components of the path itself 4. Session meta data values 5. Payload matches For each trigger, the trigger can either use the `on: any` or `on: all` formatting, for `any`, if any one of the options in the trigger is true, the rewrite rule is fired. for `all`, all the options must be satisfied. This is limited to triggers, not groups of triggers, these will be evaluated one by one.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixed #639
This PR adds rewrite "triggers" on top of the existing rewrite functionality. These are essentially sub-matches to allow a rewrite rule to have variations.
For example, for the URL
/foo/bar/bazI want to rewrite to/fooble/barble/bazbleif the query string variableculpritis set tokronk, but I want to redirect to/foozle/barzle/bazzleif the variableculpritis set toyzma.I can do this with the new URL Rewriter as follows:
Here if there is no trigger match, the rwrite will fallback to the parent
rewrite_to, but if either of the other two are triggered, the rewrite target is changed.Each trigger also sets a context variable for each match it finds, these context vars can then be used in the rewrites, so the above example with context vars could be rewritten to:
Trigger contexts take the format:
$tyk_context.trigger-{n}-{name}-{i}wherenis the trigger index in the array,namis the rx matcher name andiis the index of that match (since querystrings and headers can be arrays of values).The Trigger functionality supports:
For each trigger, the trigger can either use the
on: anyoron: allformatting, forany, if any one of the options in the trigger is true, the rewrite rule is fired. forall, all the options must be satisfied. This is limited to triggers, not groups of triggers, these will be evaluated one by one.