googleapis / googleapis/google-cloud-python

Auth: Align async token endpoint request helper with google.auth.aio.transport spec

Aperta
#17,139 1 commento 0 reazioni 0 assegnatari Vedi su GitHub
auth priority: p2 type: bug
Lingua principale
Python
Stelle
5.4k
Fork
1.8k
Merge medio
3g 4h
PR unite (30g)
122

Descrizione

### Summary of the issue

#### **Problem Description**
Currently, the core asynchronous token endpoint helper `_token_endpoint_request_no_throw` inside `google/oauth2/_client_async.py` assumes that the async transport `Request` callable returns a legacy response object (such as `_aiohttp_requests.Response` or `_CombinedResponse`) that exposes `.status` (as a property) and `.content()` (as an awaitable coroutine returning bytes):

```python
# google/oauth2/_client_async.py
response_body1 = await response.content()
...
if response.status == http_client.OK:
```

However, the modern public asynchronous transport interface specification defined in **`google.auth.aio.transport.Response`** specifies the property **`status_code`** and the method **`async def read(self) -> bytes`** instead (it does not define `.status` or `.content()`).

If a developer passes a fully compliant modern `google.auth.aio` transport (exposing only `.status_code` and `.read()`), executing any token grant or refresh methods (e.g., `jwt_grant`, `id_token_jwt_grant`, or `refresh_grant`) will instantly raise an `AttributeError` on `status` or `content`, crashing the primary authentication flow.

---

#### **Proposed Solution**
Update `_token_endpoint_request_no_throw` inside `google/oauth2/_client_async.py` to defensively support both legacy and modern AIO transports by using `hasattr()` fallback checks:

1. **Status Code fallback**:
```python
status_code = (
response.status_code
if hasattr(response, "status_code")
else response.status
)
```
2. **Body Read fallback**:
```python
if hasattr(response, "read"):
response_body1 = await response.read()
else:
response_body1 = await response.content()
```

*(Note: To prevent unhandled connection/socket exceptions during asynchronous response body streaming, these `read()`/`content()` calls should also be securely enclosed within the method's primary `try...except` block).*

---

#### **Testing Requirements**
- Update the unit tests in `test__client_async.py` to verify this compatibility.
- Implement dedicated test cases to ensure that both legacy and modern transport specifications are cleanly exercised in CI/CD without regressions.

Guida per i contributori

Apri la guida per i contributori

Valutazione

Questa issue non è ancora stata valutata.

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.