React-starter-kit: Limiting exposure of graphql API via fetch calls in client.js

[hluedeke]

I've been working on securing an application I'm writing using this wonderful boilerplate, and I came across an interesting thought.

Currently, this starter kit downloads client.js to anyone's browser that accesses the application, even if they are not logged in. This seems scary to me, as an unauthenticated user can see our internal application structure (including all fetch calls to the /graphql endpoint).

Does it make sense to define separate entries in webpack.config.js: one for client.js, and one for separate login logic? That way, if a user is denied access to a resource, the internals of the application aren't automatically visible.

Thoughts?

[frenzzy]

You may return 401 for /assets/admin.chunk.js chunk on backend for unauthorized users.

[hluedeke]

Forgive me, I'm not completely literate with chunks. Is this something I implement in server.js or in webpack.config.js?

I'm also a bit unclear on how chunks are generated. I see the CommonChunksPlugin, but that only seems to be applied to vendor.js. From the browser, all I can see are client.js and vendor.js

[frenzzy]

Take a look at src/routes/admin/index.js

const route = {
  path: '/protected',
  async action({ store }) {
    if (!store.user) {
      return { redirect: '/login' };
      // or return { component: <NotUnauthorized /> }
    }

    const ProtectedLogic = await require.ensure([], require =>
      require('./protected-logic').default, 'protected-chunk-name');

    // ProtectedLogic()

    return {
      chunk: 'protected-chunk-name',
      component: <Layout><Authorized /></Layout>,
    };
  },
};

then return 401 for /assets/protected-chunk-name.chunk.js in server.js for unauthorized users.

[hluedeke]

Excellent, this is exactly what I need. I just didn't implement admin the way it is set up in the boilerplate, so I missed this. Thank you!