-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug?]: getAuthProviderHeader
does not support getting headers from a plain Request
object
#11649
Comments
Hi @cdubz I dug into the code and it might be that underneath we're looking for a WHATWG Request vs http or Node Request. See:
import { Headers, Request as PonyfillRequest } from '@whatwg-node/fetch' It could be that when getting the event header here redwood/packages/api/src/transforms.ts Line 46 in 4a7b887
Worth trying? If so, we should fix that type to be clearer. |
Ah, yeah I didn't notice that. We're integrating the We're having to get the auth provider here because we are using a custom provider alongside It does work for us with import { getEventHeader } from '@redwoodjs/api'
const authProvider = getEventHeader(request, 'Auth-Provider') Re: I was wondering if it would make sense to adjust |
Interesting -- the reason we use the WHATWG request is in fact because that's what the Guild uses in all GraphQL Yoga. This https://github.com/ardatan/whatwg-node is managed by Arda from The Guild -- so I'd have though them to be compatible. I'll ask. const operationId = request.headers.get('If-None-Match'); Maybe it this case since it is custom auth, it makes sense just to get the raw request headers and authorize? That said when I look at: export const getAuthProviderHeader = (
event: APIGatewayProxyEvent | Request,
) => {
const authProviderKey = Object.keys(event?.headers ?? {}).find(
(key) => key.toLowerCase() === AUTH_PROVIDER_HEADER,
)
if (authProviderKey) {
return getEventHeader(event, authProviderKey)
}
return undefined
} and your
Seems like should work. Have you tried:
or
But append should mutate the headers in place so kind of scratching my head why. I still think just getting headers on own for this custom auth may make sense -- at least add a workaround? until we can identify the cause and fix? Maybe? |
To be clear -- The alternative approach uses export const getEventHeader = (
event: APIGatewayProxyEvent | Request,
headerName: string,
) => {
if (isFetchApiRequest(event)) {
return event.headers.get(headerName)
}
return event.headers[headerName] || event.headers[headerName.toLowerCase()]
} It is only checking for const authProvider = getEventHeader(request, 'Auth-Provider') works fine, but const authProvider = getEventHeader(request, AUTH_PROVIDER_HEADER) does not work (if the header is anything other than exactly It's a minor thing really, but it might be nice to adjust export const getEventHeader = (
event: APIGatewayProxyEvent | Request,
headerName: string,
) => {
if (isFetchApiRequest(event)) {
return event.headers.get(headerName)
}
const headerKey = Object.keys(event?.headers ?? {}).find(
(key) => key.toLowerCase() === headerName.toLowerCase(),
)
return headerKey ? event.headers[headerKey] : undefined
} And from there export const getAuthProviderHeader = (
event: APIGatewayProxyEvent | Request,
) => getEventHeader(event, AUTH_PROVIDER_HEADER) This would make things work regardless of the casing of the passed in
Yes, absolutely. That is what I'm doing and it's really fine. Just trying to think if we can improve these helpful utilities. |
Sounds good! Note I just made a small edit to fix my example code. I was returning the key name not it's value 🤦 |
What's not working?
The current definition of
getAuthProviderHeader
says it supports getting the auth provider header from aAPIGatewayProxyEvent
orRequest
:This works as expected for
APIGatewayProxyEvent
, but not forRequest
.How do we reproduce the bug?
In the above example,
authProvider
should betest
, but it isundefined
.What's your environment? (If it applies)
Are you interested in working on this?
The text was updated successfully, but these errors were encountered: