Alternative white lisiting method because `configuration.allowlist_regexp` is error prone about stitches HOT 6 OPEN

The thinking was that a micro service would not have a ton of non-authed routes. The app you are referring too is a full stack app that exposes a microservice, which is a pattern we recommend against and that we should avoid. I think this is why your allow list is so complicated.

The simplest way I can think of to clean it up would be to accept an array of regexps:

configuration.allow_list = [
  "/referrals/foo",
  "/resque-web",
  # etc.
]

and then wrap those with %r{\a{#val}\Z} or something.

I'm not understanding how this plays into the need to store the api client in the environment that. Those should be totally separate concerns from what is allowed/denied.

from stitches.

I think this is why your allow list is so complicated.

Correct. The team is taking steps to move to the recommended architecture in this specific case.

The simplest way I can think of to clean it up would be to accept an array of regexps:

configuration.allow_list = [
  "/referrals/foo",
  "/resque-web",
  # etc.
]

and then wrap those with %r{\a{#val}\Z} or something.

That would be a big improvement in readability within the Stitches initializer within an app and would address some of the pain. But the discoverability of the allow_list is still pretty poor when you're rolling in to an application and trying to understand why some endpoints give you a 401 and others don't. I want to move API auth to a place that is closer to where someone might look, such as in routes.rb or in the controller.

from stitches.

Yeah, the allow list was added kinda hastily as we realized we needed a way to easily opt out some routes from auth—I would agree it's a "thing about routing" and thus kinda belongs in the routes file (thus your point that it's more discoverable). The main "feature" I would want to keep is "auth by default", i.e if you add a route in config/routes.rb in "the normal Rails Way" it should require auth. I think a routing constraint could do this?

from stitches.

I think a routing constraint could do this?

Correct.

What it can't do is set the client on the response as is currently happening here:

from stitches.

It might not need to, but to leave the api_key middleware in would require two lookups to the api client per request. I guess the proposed routing constraint could simply check for the existence of the key in the header and handle the allow list and we keep the middleware the same? I dunno, we'll have to think this through.

from stitches.

I'll put a PR together to give us something concrete to point to

from stitches.