Unable to set wildcard route

[FlippingBinary]

I have an app that needs all users to be authenticated. There is no public-facing welcome page and no need for one. All users should redirect automatically to /.auth/login/aad if they aren't authenticated.

The way I see it, there are two main ways to handle this. Either check for the x-ms-client-principal header in a hook and throw an error if it's missing, or set allowedRoles for all routes in staticwebapp.config.json. I would prefer the latter option because then pre-rendered pages will be protected without having to make all pages server-side rendered.

Unfortunately, that's not possible because of the way this adapter processes the config.

The workaround seems to be to list each route in the adapter's customStaticWebAppConfig, but that has two problems: The first problem is the hook still has to be used to protect the routes that get added automatically. The second problem is there are now two sources of truth for the list of routes. The file system and svelte.config.js.

I understand there is a need to rewrite routes to ssrFunctionRoute for server-side rendering, but perhaps there could be a more nuanced way of building the route map other than just tacking on permanent routes and blocking wildcard routes. For example, the provided customStaticWebAppConfig could be walked and rules that lack a redirect and rewrite could have a rewrite: ssrFunctionRoute added. Then, if the required routes are missing, they could be added.

Are you receptive to a pull request on this subject? I might be willing to take a stab at it.

[geoffrich]

There is an open PR to allow setting allowedRoles for all routes in #60 - would this do what you need? Or is further customization of the config necessary?

I was waiting for the original author to resolve some comments I made on the PR, though I can clean up the PR myself since it's been a few weeks.

[FlippingBinary]

Ahh, sorry I didn't notice that before. That pull request would not do what I need it to do, and it might interfere if you use a map function to replace the allowedRoles of all routes without testing for the presence of an existing allowedRoles before overwriting it. However, it is a good approach for apps that need a default allowedRoles to catch routes that don't include an explicit allowedRoles.

What I described would give developers the freedom to write routes as described by Microsoft's documentation, with the adapter doing a little cleanup to make sure they run correctly. That cleanup could include inserting an allowedRoles that is specified the way that pull request does it, so these ideas could co-exist. It would just eliminate the need to prohibit the use of the wildcard and it would render the statement about "specific routes" from line 143 of that pull request unnecessary.

I would also ask to let rules be written with a rewrite: 'ssr' (or something like it) to force server-side rendering without statically writing rewrite: '/api/__render'. It would do that by simply replacing the 'ssr' string with the value of ssrFunctionRoute. That way routes that need to be server-side rendered can be specified without interfering with the ability to change ssrFunctionRoute in future versions of the adapter.

[FlippingBinary]

Please take a look at my pull request when you get a minute. It might actually serve as a replacement to #60 because a default allowedRoles can be set with a wildcard route like this:

import azure from 'svelte-adapter-azure-swa';

export default {
  kit: {
    ...
    adapter: azure({
      customStaticWebAppConfig: {
        routes: [
          {
            route: '/*',
            allowedRoles: ['admin']
          }
        ],
        globalHeaders: {
          'X-Content-Type-Options': 'nosniff',
          'X-Frame-Options': 'DENY',
          'Content-Security-Policy': "default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none'",
        },
        mimeTypes: {
          '.json': 'text/json'
        },
        responseOverrides: {
          '401': {
            'redirect': '/login',
            'statusCode': 302
          }
        }
      }
    })
  }
};

The adapter then uses that wildcard route's settings to override the settings of all routes it creates.

[geoffrich]

Great, thank you. I should hopefully be able to take a look in the next few days.