Validate frontend prefixes

[brylie]

API Umbrella does not seem to validate frontend prefixes. This has been observed in two ways:

• duplicate frontend prefix for separate API Backend(s)
• overriding base prefix ( '/' route)

It may also be possible to override internal routes, such as /admin.

Feature request

Add validation to frontend prefixes, such as:

• checking for duplicate strings (e.g. prefix collision)
• checking for restricted strings (e.g. '/', '/admin', etc.)

[GUI]

Good points. Semi-related to the prefix collision issue is: 18F/api.data.gov#186

Regarding restricted prefixes, in our environment, we've sort of solved that in the reverse fashion by only white-listing where admins can operate with the Admin Scopes & Admin Groups permissions. So, for example, we limit teams so they can only operate under api.example.com/foo/*. But I also think preventing some restricted paths is probably a good idea too.

Although, I believe /admin/ should always be routed ahead of API matches, so I don't think it's possible to override that, but we need to double check (but you won't currently get any errors, it just won't route). We also need to be careful if we place any restrictions on the root prefix of /, since actually do need to allow that prefix for secondary domains (we have a couple of these in our case, where we essentially have API-only domains CNAMEd to API Umbrella without a website or admin, and just APIs at the root route).

Thanks for reporting this!

[KrishnaPG]

+1 for the 'preventing restricted paths`.

A validation criteria (regEx or similar) that works across the Admin Scopes for rejections (of say, inappropriate words, well-known bad routes etc.) should resolve this situation.

For example, the rejection regExs run before the white-listings of Admin-scopes and system could ship with couple of in-built regExs, such as:

• /admin/*
• /$

This way, it protects the in-built paths required by the system, as well as providing the Admins more control over the route specifications.