Seems that attachments are stripped on this list. Examples pasted below
*rules.json*
[
{ "host": "localhost", "path": "/login", "forward":
"localhost:9004", "scheme": "https", "auth": false },
{ "host": "localhost", "path": "/api/1.2/innovation/", "forward":
"localhost:8004", "scheme": "http", "auth": true, "routes-file":
"innovation.json" },
{ "host": "localhost", "path": "/api/1.2/", "forward":
"localhost:3000", "scheme": "http", "auth": true, "routes-file":
"traffic-ops-routes.json" },
{ "host": "localhost", "path": "/internal/api/1.2/", "forward":
"localhost:3000", "scheme": "http", "auth": true, "routes-file":
"internal-routes.json" }
]
*traffic-ops-routes.json (partial)*
.
.
.
{ "match": "/cdns/health", "auth": { "GET":
["cdn-health-read"] }},
{ "match": "/cdns/capacity", "auth": { "GET":
["cdn-health-read"] }},
{ "match": "/cdns/usage/overview", "auth": { "GET":
["cdn-stats-read"] }},
{ "match": "/cdns/name/dnsseckeys/generate", "auth": { "GET":
["cdn-security-keys-read"] }},
{ "match": "/cdns/name/[^\/]+/?", "auth": { "GET":
["cdn-read"] }},
{ "match": "/cdns/name/[^\/]+/sslkeys", "auth": { "GET":
["cdn-security-keys-read"] }},
{ "match": "/cdns/name/[^\/]+/dnsseckeys", "auth": { "GET":
["cdn-security-keys-read"] }},
{ "match": "/cdns/name/[^\/]+/dnsseckeys/delete", "auth": { "GET":
["cdn-security-keys-write"] }},
{ "match": "/cdns/[^\/]+/queue_update", "auth": { "POST":
["queue-updates-write"] }},
{ "match": "/cdns/[^\/]+/snapshot", "auth": { "PUT":
["cdn-config-snapshot-write"] }},
{ "match": "/cdns/[^\/]+/health", "auth": { "GET":
["cdn-health-read"] }},
{ "match": "/cdns/[^\/]+/?", "auth": { "GET":
["cdn-read"], "PUT": ["cdn-write"], "PATCH": ["cdn-write"], "DELETE":
["cdn-write"] }},
{ "match": "/cdns", "auth": { "GET":
["cdn-read"], "POST": ["cdn-write"] }},
.
.
.
On Sun, May 7, 2017 at 12:39 PM Amir Yeshurun <[email protected]> wrote:
> Attached please find examples for forwarding rules file (rules.json) and
> the authorization rules file (traffic-ops-routes.json)
>
>
> On Sun, May 7, 2017 at 10:39 AM Amir Yeshurun <[email protected]> wrote:
>
>> Hi all,
>>
>> I am about to submit a PR with a first operational version of the API GW,
>> to the "experimental" code base.
>>
>> The API GW forwarding logic is as follow:
>>
>> 1. Find host to forward the request: Prefix match on the request path
>> against a list of forwarding rules. The matched forwarding rule defines
>> the
>> target's host, and the target's *authorization rules*.
>> 2. Authorization: Regex match on the request path against a list of
>> *authorization
>> rules*. The matched rule defines the required capabilities to perform
>> the HTTP method on the route. These capabilities are compared against the
>> user's capabilities in the user's JWT
>>
>> At this moment, the 2 sets of rules are hard-coded in json files. The
>> files are provided with the API GW distribution and contain definitions for
>> TC 2.0 API routes. I have tested parts of the API, however, there might be
>> mistakes in some of the routes. Please be warned.
>>
>> Considering manageability and high availability, I am aware that using
>> local files for storing the set of authorization rules is inferior to
>> centralized configuration.
>>
>> We are considering different approaches for centralized configuration,
>> having the following points in mind
>>
>> - Microservice world: API GW will front multiple services, not only
>> Mojo. It can also front other TC components like Traffic Stats and Traffic
>> Monitor. Each service defines its own routes and capabilities. Here comes
>> the question of what is the "source of truth" for the route definitions.
>> - Handling private routes. API GW may front non-TC services.
>> - User changes to the AAA scheme. The ability for admin user to makes
>> changes in the required capabilities of a route, maybe even define new
>> capability names, was raised in the past as a use case that should be
>> supported.
>> - Easy development and deployment of new services.
>> - Using TO DB for expediency.
>>
>> I would appreciate any feedback and views on your approach to manage
>> route definitions.
>>
>> Thanks
>> /amiry
>>
>
