Functions doesn't allow function name or route /api/admin

[omkarmore83]

By default functions has a route prefix of "/api". When I try to create a function with the name "admin", Function gives an error saying

Error:

Function ($admin) Error: The specified route conflicts with one or more built in routes. Session Id: 19b72d6133b2489987185f757f8c1fe2

Timestamp: 2017-08-11T18:18:36.311Z

Functions built in route uses /admin. Its understandable that this is reserved. However functions with route /api/admin or with any other route prefix should be allowed.

Infact it doesnt even allow function names like administrator or anything that starts with admin.

[christopheranderson]

This likely needs to stay blocked because you can change the base route to "/" and then you'd have "/admin" with you function named admin. We'd need a safer way to evaluate this.

[jyn514]

This doesn't give a warning if you have it in a regex constraint, it took me a while even to figure out that this was intentional. If I change it to say "route": "admin" it gives a warning. Sample code:

{
"bindings": [
     {
        "route": "{url:regex(admin)}"
     }
]
}

[CastleArg]

I'm having a problem here with getStatusQueryUris, eg http://myApp/runtime/webhooks/durabletask/instances/xxxxxxx

I have a catch all proxy to route to SPA UI and have more specific proxies e.g /api/myFunc for actual backend stuff. However it is now impossible to query status.

Hitting the statusQueryUri will be routed to SPA UI, and I cannot make a proxy to force tit to the backend due to this issue.

[rithinch]

Workaround

You can change the route name from /admin to something likev2/admin in your function code.

Example:

[FunctionName("ExampleAdminRoute")]
public static async Task<IActionResult> Run([HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = "v2/admin")]HttpRequest req, ILogger log)
{
    //your function code
}

Then, you can add a proxy to the route (more info on azure function proxies here). Proxies are stored in proxies.json.

Make sure this file is copied to the build output directory i.e. including in .csproj file.

Example proxies.json:

{
  "$schema": "http://json.schemastore.org/proxies",
  "proxies": {
    "AdminProxy": {
      "matchCondition": {
        "methods": [ "GET" ],
        "route": "/api/admin"
      },
      "backendUri": "https://localhost/api/v2/admin"
    }
  }
}

Now, when you run the functions app, you should see console output like:

Now listening on: http://0.0.0.0:7071
Application started. Press Ctrl+C to shut down.
Listening on http://0.0.0.0:7071/
Hit CTRL-C to exit...

Http Functions:

    AdminProxy: http://localhost:7071/api/admin

    ExampleAdminRoute: http://localhost:7071/api/v2/admin

Any requests coming to api/admin will automatically be redirected to api/v2/admin.

Proxies are flexible enough to match different types of requests (GET/POST) with parameters etc.

The same applies to functions app written in any language i.e. Node.js, Python etc.

More info in the stackoverflow question here.

[ggailey777]

Do we plan to address this, or should we just document it? I have a related doc issue where the customer wants to name the function admin-results-email. https://github.com/MicrosoftDocs/azure-docs/issues/80267

I understand blocking admin but not admin-*

[gabr1elt-arc]

admin-* should be allowed to group admin apis!

[briandunnington]

This likely needs to stay blocked because you can change the base route to "/" and then you'd have "/admin" with you function named admin. We'd need a safer way to evaluate this.

you could also change your function name from "notadmin" to "admin" and it would also break, but it shouldnt try to protect you from something you havent done yet.

if the resolved routes arent in conflict when the app is built, it shouldnt cause an error.

we got bit by this going the other way. originally, we had a routePrefix of api and some routes like "something/admin/whatever" which worked fine. then we changed our routePrefix to "api/something" and the route to "admin/whatever" (so the net effect was that the final route didnt change at all) and it started erroring out, even though 1) the actual route didnt change and 2) api/something/admin is not in conflict with any built-in routes.