use auth when requesting a custom api without the api wrapper
Hello !
I'm having a small trouble, I've seen the example here to implement streaming capabilities.
https://github.com/wasp-lang/wasp/tree/main/examples/streaming/src/client
I tried to do the same thing and it is working.
I am now adding authentification and I can't make it work, indeed since I'm using "fetch" and not the API wrapper I don't get the context.user to do auth.
The problem, when I try to access "context.user" it doesn't exist and I cannot make it work. Do you have any ideas ?
See the code below.
GitHub
wasp/examples/streaming/src/client at main ยท wasp-lang/wasp
The fastest way to develop full-stack web apps with React & Node.js. - wasp-lang/wasp
9 Replies
Hi @TomD. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
The issue you're facing is related to the fact that you're using the
fetch
API directly, which doesn't automatically include the authentication context that the Wasp API wrapper provides.
In Wasp, the context.user
is populated by the auth
middleware when you make a request using the API wrapper. This is why you're not seeing the context.user
when you're using fetch
directly.
To solve this, you can use the API wrapper provided by Wasp, which automatically includes the authentication context. Here's an example of how to use it:
(Source: Using the API from the Client (https://wasp-lang.dev/docs/advanced/apis#using-the-api-from-the-client))
However, if you need to use fetch
directly for some reason (like in your case, for streaming), you'll need to manually include the authentication token in your request. The exact way to do this depends on how you've set up authentication in your app, but it usually involves setting an Authorization
header with the user's token.
Unfortunately, the provided knowledge sources do not include information on how to manually include the authentication token when using fetch
directly. You might want to check the Wasp documentation or ask in the Wasp community for more specific guidance on this.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @TomD, 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?Our expert for both Auth and streaming @miho will be best able to answer this one ๐
If we take a look at the custom API feature reference: https://wasp-lang.dev/docs/advanced/apis#api-reference there is a
auth
field that if set to true
will attempt to extract the user from the JWT into the context.user
.
The issue with using fetch
in this case is that the regular request headers that we set for you by default are not set ... because we use axios
for our RPC and not fetch
.
So, this leads me to the following:
- either we use axios
for the streaming request
- or we set the JWT token manually for the fetch
streaming requestCustom 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.
Let me try implementing the example with Axios, and I'll report back ๐
Ok thanks for the clarification, if I just switch to axios things should work ? I'll try this then.
For the second solution with the JWT token, how can I access it to pass it in the header of my request ?
Using Axios
+
+
This worked for me ๐ Axios doesn't support streaming properly since it's based on XHR and that's the reason I went with
fetch
in the initial example.
Using fetch
Similar to the axios one, but you have to add the sessionId
to the headers.
So, this get weird because Axios doesn't have a nice way of supporting streaming and Wasp is using Axios by default.
On the other hand, it's weird to set the session manually like this, but it's okay since it's nothing too custom.Indeed it's working ! I went the sessionId solution fow now to not change to axios but I will probably come back to your message and implement this clean solution if I have time !
Thanks a lot !
@miho if I am correct you didn't just use new instance of axios, but you instead imported Wasp's
api
which is our instance of axios that we configured to use auth and stuff, right?You are correct, I forgot to mention that ๐
It needs to be imported from
wasp/client/api