Design and security implications for reverse API

[silviogutierrez]

The reverse export from @reactivated works as intended right now. See https://www.reactivated.io/documentation/api/

But the way it works means that, ultimately, every named URL in your project URLs will be included in the bundle. It'll me minified and obfuscated in production, but they'll be there.

Is this a security issue?

I argue that no, it isn't. If this were a frontend app with frontend-only routes using React Router or the like, they'd be there anyway. Hiding them would just be security through obscurity. Your views should be guarded by the login_required decorator or stronger authorization anyway.

But if you feel strongly that it is a security issue, there are a few options.

Option 1: Tree Shaking

First option is to make this API work with tree-shaking. Basically, you'd import reverse and use something like reverse.my_view_name({post_id: 1}) or reverse.home_page(). All the unused URLs will be tree-shaken and disappear.

It sounds too good to be true. First problem is the API wouldn't be quite as clean. Instead of importing from @reactivated like we do all other imports, you'd have to do import * as reverse from @reactivated/reverse. This is because esbuild does not support tree-shaking for re-exports. It may never. If you know a work around, let me know.

Second downside: sensitive URLs, if actually used in a template, will still be present anyway. But at least not all URLs will be included.

Options 2: Server-only usage

I could manipulate the bundler to only include the URLs in the server-side bundle. If you try to use reverse in client-only code, we could raise a warning. This hides all urls from the client.

Major downside? If you have say, addAnotherInvite and that dynamically inserts code blocks that use reverse, it'll fail. And there's no way to statically type this. It would be a runtime error.

There's some black magic that could be used to make dynamic behavior work, but it'd be extremely complex.

What are your thoughts?