aiohttp client and JWT authorization header problem #6523
-
|
I'm having problems setting the "Authorization" header in aiohttp. I need to make a request to an authenticated API using JWT but when I add the token manually to the header, aiohttp returns the following errors: ValueError: [TypeError("'URL' object is not iterable"), TypeError('vars() argument must have __dict__ attribute')]The JWT token I have to send in the header is quite long so I guess there is some limitation for the size because if I modify it to use a shorter (and fake) one, the request is sent even though the "Authorization" header is omitted. I guess this has to do with the following warning in the documentation: I couldn't find anything in the docs or the repo to backup these facts so I don't know how to proceed. The following code was used to make the request: try:
# Using fake URL and headers as an example
url = "https://myapi.com/get-data"
headers = {"Authorization": "Bearer eyJ0eXniOiJ2V1QiLCJhcGciOiJS4zI1NiJ9..."}
async with self.session.get(url, headers=headers) as response:
await response.read()
return response
except aiohttp.ClientConnectionError as e:
message = f"Connection error: {e}"
raise RequestErrorException(url=url, detail=message)
except Exception as e:
message = f"Data error: {e}"
raise RequestErrorException(url=url, detail=message)And here is the traceback: |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 6 replies
-
|
Every line of your traceback comes from fastapi... I doubt anybody here is likely to be able to help when the traceback doesn't seem to have anything to do with aiohttp, except that somewhere the |
Beta Was this translation helpful? Give feedback.
-
|
You are absolutely right but I just added it to give a little more context as I don't know how to proceed with the debugging. Is it possible that there is a limit to the size of the headers? I didn't find any information about it in the documentation but I guess this has something to do with it because if I use a shorter token, the request works even though it omits the "Authorization" header. Will try to do this outside of FastAPI to see if there is more information. |
Beta Was this translation helpful? Give feedback.
-
|
Regarding the "silly mistake", that's the only way I found to keep the context of the response (because we're using a wrapper that we made around aiohttp) when sending it to our FastAPI endpoints (thats where we process the response and return whatever we want to return). Something similar to this: https://stackoverflow.com/questions/68693855/aiohttp-getting-response-object-out-of-context-manager |
Beta Was this translation helpful? Give feedback.
-
I was just guessing that you were returning it in an endpoint handler, as there is not enough information. Still, that looks like very bad practice, and I'd rewrite the code to not pass a I suspect this is related to the exception you are seeing, but it's impossible to tell. Without any kind of exception/error in the code you've shared or from aiohttp, we have nothing to look at, it's just blind guessing. You've shared a snippet of code and then an exception that comes from some other code. To figure out if the full header is getting sent, you could just look at what is actually being received. e.g. Just run netcat with |
Beta Was this translation helpful? Give feedback.
-
|
Thank you very much for your time and help and I understand what you are trying to point out.
Indeed it was. I didn't add information regarding how we handle requests because I thought it was unrelated since most of the code works for other endpoints. Outside of FastAPI I am not getting any exceptions so I assume it is working as expected on the aiohttp side.
The "Authorization" header is missing so the endpoint that I'm trying to hit always return a Do I have to wait until v4 to bypass this behaviour? Thanks again for your help! |
Beta Was this translation helpful? Give feedback.
-
|
I think there's a solution at the end of that 2nd thread: #5783 (comment) |
Beta Was this translation helpful? Give feedback.
Every line of your traceback comes from fastapi...
I doubt anybody here is likely to be able to help when the traceback doesn't seem to have anything to do with aiohttp, except that somewhere the
URLobject has ended up in the fastapi code.