-
-
Notifications
You must be signed in to change notification settings - Fork 796
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
Serverless Offline only supports retrieving JWT from the headers (undefined) #1311
Comments
Investigating further I found that serverless-offline tries to set up a JWT authorizer despite the fact that it is declared as provider:
name: aws
stage: ${self:custom.stage}
runtime: nodejs12.x
region: us-west-2
httpApi:
shouldStartNameWithService: true
authorizers:
msAuthorizer:
type: request
functionName: authorizeMemberstack
functions:
- postProposalV1:
handler: handler.postProposalV1
timeout: 900
events:
- httpApi:
path: /v1/proposal
method: post
authorizer:
name: msAuthorizer
- authorizeMemberstack:
handler: handler.authorizeV1 Triggers the same error:
Can anyone tell me what am I doing wrong? @daniel-cottone @abdulghani |
@medikoo is this library still actively maintained? Seems like it has problems supporting |
@vadymhimself we have limited time handling this library. Still, we'll open for maintainers that may help us with that. Also, we'll try to look into every PR that addresses some important issue. If you know how to fix it, please propose a PR, and we'll do our best to take it in. |
Getting the same issue here, @vadymhimself (or anyone else landing here) if you still want to be able to still make and partially handle offline requests, you can use the
Of course, this will disable the authorization step for offline calls, but given the alternative of literally nothing working?... it may be useful to have at least partial functionality. If you depend on this plugin to validate your authorization, and you deploy directly to production, then this won't work for you. For those who practice good development practices and can deploy to a personal or at least development/staging environment and run automated tests against that, then this may be a reasonable compromise in the meantime. Edit: added extra details so this comment isn't misconstrued by others |
@vadymhimself I also try to implement the So, I tried to set the "Function" and use
Disappointment... Perhaps it is better not to use a separate authorizer and let each function do it. It might even work faster. @mohoromitch disable authorization and hopes that it will work in production, thanks for the advice. |
I'm not sure if this is directly relevant to the issue/goals from OP, but in case anyone lands here and is are having issues using a custom authorizer with an httpApi (v2) endpoint, the trick seems to be to add the custom:
serverless-offline:
ignoreJWTSignature: true
provider:
httpApi:
authorizers:
api-authorizer:
type: request
functionName: api-authorizer
resultTtlInSeconds: 300
identitySource:
- $request.header.Authorization # this is ignored by serverless-offline but will default to the Authorization header anyway
functions:
api-endpoint:
events:
- httpApi:
method: '*'
path: /
authorizer:
name: api-authorizer
type: request # <-- this is the key part which will "trick" serverless-offline into using a custom authorizer
handler: '...' The immediate cause of the issue appears to come from these lines: serverless-offline/src/events/http/HttpServer.js Lines 376 to 386 in 8d61bde
Here, none of the settings configured in |
I hope i will hear good news soon ! In the meantime, we are telling developers to comment some code in serverless.yml :( when running "sls offline" |
This answer #1078 (comment) helps me, but still i have to comment the event |
I just ran into this issue recently, with a perhaps newer version of the plugin (v8.7.0) and what I found was that if you were using a configuration similar to this: provider:
name: aws
runtime: nodejs12.x
profile: AWS-profile
stage: ${opt:stage, 'dev'}
region: AWS-region
httpApi:
authorizers:
authTokenAuthorizer:
identitySource: '$request.header.Authorization'
issuerUrl: https://issuer.url/
audience: https://audience.url
functions:
profile:
handler: src/function/function.router
events:
- httpApi:
path: /function/{parameter}
method: post
authorizer:
name: authTokenAuthorizer What actually ends up happening is that when attempting to build the JWT handling function we end up failing because the plugin doesn't have the capability to actually validate JWTs but we haven't told it not to bother. If you take a look at the following code in serverless-offline/src/events/http/authJWTSettingsExtractor.js Lines 27 to 34 in 81a81a1
You can see that there's a cool TODO about actually validating JWTs and then a hard "successful null" exit for this function if you don't have the serverless-offline/src/events/http/HttpServer.js Lines 307 to 310 in 10afe5e
The null check here seems extraneous since an object will always be returned no matter the outcome. And then slightly later we just pass this serverless-offline/src/events/http/HttpServer.js Lines 330 to 331 in 10afe5e
And hit this code serverless-offline/src/events/http/createJWTAuthScheme.js Lines 6 to 15 in 10afe5e
And bam, our error: The long-term solution is to support JWT signature validation but that's of an unknown complexity/effort level. However, in the short term it's probably a good idea to surface this error in a more clear way, it's probably not a big deal for most people to disable signature validation in a local dev environment. Edit: Better links to source and minor clarity changes |
After digging a lot, I found this example. This works in my particular case since I don't have control over the authorizer I use in production, however, I know that this authorizer injects some particular fields on the Following the example, what I did was: custom:
offline:
customAuthenticationProvider: ./src/localAuth And then create the file module.exports = (endpoint, functionKey, method, path) => {
return {
getAuthenticateFunction: () => ({
async authenticate(request, h) {
const context = {
expected: 'it works',
awesomeField: request.headers['x-field1'],
equallyAwesomeField: request.headers['x-field2'],
particularlyAwesomeField: request.headers['x-field3'],
}
return h.authenticated({
credentials: {
context,
},
})
},
}),
name: functionKey,
scheme: functionKey,
}
} Inside your function, you can of course call these fields using |
so I guess we still don't have a solution for this as the maintainers have limited time in reviewing the issues that are being raised |
This PR fixes the description for enabling custom authentication providers in serverless.yml files. In addition to using the correct keys, I added an usage example and direct linked the referenced integration test example. Related to dherault#1311
Bug Report
I am trying to implement a jwt authorizer as per this guide
Current Behavior
Sample Code
Environment
serverless
version: 2.67.0serverless-offline
version: 8.3.1The text was updated successfully, but these errors were encountered: