feat: improved insecure `getSession()` warning

[hf]

Previously when attempting to use getSession() from insecure storage such as cookies in SSR on the server, a disruptive warning was logged.

It's been a long while and most developers should already be conditioned that general use of getSession() for authorization on the server should not be used. There are, however, some valid use cases for getSession() that used to log a warning but now won't:

Does (any) session exist or not?

Most applications want to redirect the user to a login page if there's no session and probably are not interested in validating that the session is actually OK. This can be achieved with the following sample code:

const supabase = createServerClient(/* ... */)

const { data: session, error } = await supabase.auth.getSession()

if (!session) {
  // no warning logged
  return NextResponse.redirect('/login')
}

Simple boolean user check?

Note that this does not answer what user is there.

const supabase = createServerClient(/* ... */)

const { data: session, error } = await supabase.auth.getSession()

if (!session?.user) {
  // no warning logged
  return NextResponse.redirect('/login')
}

// but if you use
if (session?.user?.id === '284e7abb-785c-453c-bca4-a93da0825776') {
  // this will be true but a warning will be logged
}

// same for app_metadata or user_metadata

Just access an up-to-date access token to send to a private API?

const supabase = createServerClient(/* ... */)

const { data: session, error } = await supabase.auth.getSession()

await fetch(URL, {
  headers: {
    Authorization: `Bearer ${session.access_token}`
  },
})