(no title)
joseferben | 1 year ago
the main issue i wanted to highlight is that things are not caught at type-check time. maybe vercel could provide eslint plugins? this could codify a lot of the caveats
> There's no way to get around thinking about AuthN/Z with any server APIs
very true! maybe there is a way to make the default secure somehow by making it awkward to publicly expose a POST route by accident. awesome that next.js 15 is doing things in that regard.
thanks for addressing the points leerob, shows the great governance mentioned in the end of the post :)
joseferben|1 year ago
imo it's easier to spot the authn/authz issue here
export default function handler( req: NextApiRequest, res: NextApiResponse<ResponseData> ) { // updating user details without authn/authz }
than here
"use server"
export async function updateUser(email: string, age: number) { // updating user details without authn/authz }
without having read any next docs. engineers got trained to consider authn/authz the moment they see "http route/endpoint", maybe being more explicit about what happens in the api would help?
or next could provide an authn api for server actions that authn providers would implement?