W
Wasp3w ago
genyus

Custom endpoint missing context user

I've created a custom API endpoint that needs to be authenticated. As per the documentation, I set the auth field to true, but when a request is received, there's no Authorization header and the context.user object is null even though the user is logged in. I'm not sure what I'm missing? Do I need to set the header manually? For context, I have an API namespace applied to prevent the CORS errors I was experiencing initially.
api getDocumentMarkupApi {
fn: import { getDocumentMarkup } from "@src/server/api/documents.js",
entities: [Document],
httpRoute: (GET, "/api/documents/:id/render"),
auth: true
}

apiNamespace customApi {
middlewareConfigFn: import { apiMiddleware } from "@src/server/utils",
path: "/api"
}
api getDocumentMarkupApi {
fn: import { getDocumentMarkup } from "@src/server/api/documents.js",
entities: [Document],
httpRoute: (GET, "/api/documents/:id/render"),
auth: true
}

apiNamespace customApi {
middlewareConfigFn: import { apiMiddleware } from "@src/server/utils",
path: "/api"
}
Custom HTTP API Endpoints | Wasp
In Wasp, the default client-server interaction mechanism is through Operations. However, if you need a specific URL method/path, or a specific response, Operations may not be suitable for you. For these cases, you can use an api. Best of all, they should look and feel very familiar.
2 Replies
kapa.ai
kapa.ai3w ago
Hi @genyus. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave: ---------------------- Based on the information provided in the knowledge sources, I can offer some insights into your issue with the custom API endpoint and authentication. First, it's important to note that setting auth: true in the API declaration doesn't automatically block unauthenticated requests. As mentioned in the API Reference, this setting only attempts to parse the JWT in the Authorization header and provide a context.user object if successful. The behavior you're experiencing, where context.user is null even though the user is logged in, suggests that the Authorization header might not be present in the request. This could be due to how the request is being made from the client side. To address this issue, you should ensure that you're using the api wrapper from Wasp when making requests from the client. As shown in the Using the API from the Client section, you should import and use the Axios wrapper like this:
import { api } from "wasp/client/api";

async function fetchCustomRoute() {
const res = await api.get("/api/documents/:id/render");
console.log(res.data);
}
import { api } from "wasp/client/api";

async function fetchCustomRoute() {
const res = await api.get("/api/documents/:id/render");
console.log(res.data);
}
This wrapper automatically includes the necessary headers, including the Authorization header with the JWT token. If you're already using this approach and still experiencing issues, it's worth noting that there have been some reported problems with CORS and custom API endpoints. As mentioned in a GitHub issue, some users have experienced CORS errors even when using the api wrapper. Regarding your API namespace for CORS, that's a good approach. However, make sure that your apiMiddleware function is correctly configured to handle CORS and authentication headers. You might want to double-check its implementation. If you continue to face issues, you might need to manually check for authentication in your API implementation, similar to how it's done in queries and actions. For example:
export const getDocumentMarkup = async (req, res, context) => {
if (!context.user) {
throw new HttpError(401);
}
// Rest of your API logic here
};
export const getDocumentMarkup = async (req, res, context) => {
if (!context.user) {
throw new HttpError(401);
}
// Rest of your API logic here
};
Lastly, it's worth mentioning that the Wasp team is aware of some inconsistencies in the current auth middleware behavior and is considering improvements, as discussed in this GitHub issue. If these suggestions don't resolve your issue, you might want to double-check your client-side code to ensure the request is being made correctly, and possibly reach out to the Wasp community for further assistance. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @genyus, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?
genyus
genyusOP3w ago
Thanks, the client code was making a fetch request, switching to the api wrapper fixed it

Did you find this page helpful?