start-basic-auth example is not secure

[ensconced]

Which project does this relate to?

Start

Describe the bug

I think it's reasonable to expect that in the start-basic-auth example, the posts should only be accessible if you're logged in.

But in fact they are accessible without logging in. i.e. the example is a poor demonstration of how to actually secure the posts information.

Your Example Website or App

The issue can be seen on the codesandbox from the docs.

Steps to Reproduce the Bug or Issue

1. Open the codesandbox linked above
2. In the codesandbox preview, edit the URL so that it ends with /_server/app_utils_posts_ts--fetchPosts_createServerFn_handler?payload=%7B%22data%22%3A%7B%22%24undefined%22%3A0%7D%2C%22context%22%3A%7B%7D%7D, then hit enter to go to this page. You successfully retrieve the posts as JSON, despite not being logged in.
3. Do the same for /_server/app_utils_posts_ts--fetchPost_createServerFn_handler?payload=%7B%22data%22%3A%223%22%2C%22context%22%3A%7B%7D%7D and see that you get a single post in the response

Expected behavior

When following the start-basic-auth example, it shouldn't be possible to get the posts without being properly authenticated.

Screenshots or Videos

Platform

not relevant

Additional context

No response

[ensconced]

I guess the proper solution would be to check the session in middleware, ideally global middleware so you don't have to remember to use it on every server fn?

[schiller-manuel]

PR welcome!

[ensconced]

@schiller-manuel I'm not quite sure the best way to go about this. I want to do something like this

const protectedServerFns = [
  'app_utils_posts_ts--fetchPosts_createServerFn_handler',
]

const authMiddleware = createMiddleware().server(
  async ({ next, functionId }) => {
    if (protectedServerFns.includes(functionId)) {
      const session = await useAppSession()
      if (session.data.userEmail) {
        return next()
      }
      throw redirect({ statusCode: 403 })
    }
    return next()
  },
)

registerGlobalMiddleware({
  middleware: [authMiddleware],
})

...but this has a couple of problems:

1. I thought a 403 response would be the most appropriate here, but doing redirect({ statusCode: 403 }) actually results in a response with status code 200, but with the content {"statusCode":403,"isRedirect":true,"reloadDocument":false}. I guess it does the job (of avoiding actually exposing the posts data), but I suspect I'm doing something wrong here.
2. I would like to be able to declaratively list which server fns need to be behind this auth protection (or even better, which don't, i.e. make it secure by default instead). But I'm having to use the generated 'app_utils_posts_ts--fetchPosts_createServerFn_handler' string here, which as I understand it is not guaranteed to be stable and is meant as more of an implementation detail.

Any ideas?

[NotAmaan]

Not sure if this is a library issue or just a limitation of the example. The "server" in the example doesn’t actually enforce authentication, which isn’t how things work in a real app. Normally, the client would have a JWT, use it to show user info in the UI, and include it in requests (headers or cookies) so the server can validate it.

For example, if I ran this exact setup but used a secured Supabase instance instead of JSONPlaceholder, Supabase would expect auth headers and reject unauthenticated requests. Right now, this example just assumes security without actually enforcing it.

If I had to fix it, I’d add a proxy between JSONPlaceholder and the client to handle authentication properly.