When trying to connect to Lambda (Access Key) via AWS’s relatively new “Lambda function URLs”, I receive a 403 - Credentials should be scoped to correct service: ‘lambda’. What I can not tell because the notehub is forming the header, does it look something like the following (where the service is include, lambda in this case):
Credential=AKIAIOSFODNN7EXAMPLE/20120224/us-west-1/lambda/aws4_request
Hey @JimC, you can try sending data from that route to webhook.site instead of AWS and you’ll be able to see the header that Notehub creates.
I hope that helps, and please let me know the result. If there’s something we need to adjust on the Notehub side, that would be good to know.
Brandon
Webhook is really slow, so hard for me to tell, but it seems like you are missing the service header in the request based on what I see in postman.
Usually webhook.site is really fast (meaning, as soon as an event appears in Notehub, it’s visible there only a second or two afterwards). POSTing data to webhook.site is nice because you can see the full context and headers to debug your routes:
webhook did not help much, can not see the auth header. Lambda should be part of the auth header like the following:
Credential=Asdfsjkhjkshfjksdhfjdhf/20220801/us-east-2/lambda/aws4_request
Hi @JimC,
Did you create the Notehub route as an “AWS” type or a “General HTTP/S Request/Response” type? I’m thinking since Lambda function URLs are dedicated HTTPS endpoints, you should try the latter. You can also specify the exact headers you need with that route type.
I am a bit ignorant of these function URLs though, so we may need to do some more research to properly support these under the “AWS” route type in Notehub.
Rob
The Service header needs to be set to lambda, if not, the only way to use this in an unsecured mode. Once the Service header is set, Credential (see above) will now contain the lambda service, thus avoiding the scoping error.
Got it. I’ve created an internal feature request for us to support Lambda function URLs as part of the AWS route type. Will post updates here as they come in!
Rob
Great
Really appreciate all the help
Hi Rob, just curious about the status of this feature. I’m not sure how to manually specify the headers through the route. I tried a few things but it didn’t work.
Any tips on what to use for manually specified headers when using the Lambda function URL? Got it working without access key but obviously don’t want to use that method.
Hi @group1guy and welcome to the Blues Wireless community!
Unfortunately I don’t have an update on this feature for you just yet. We have seen this request come in multiple times though, so just know it’s on our radar for implementation.
Thanks,
Rob
Hey, @group1guy and @JimC.
We’re working on this and wanted to reach out and get your feedback on implementation before it’s solidified.
Would you be ok with the approach where we just handle the auth transparently in the backend and "Do the Right Thing"™ for you, or would you prefer to see a separate route type for AWS Lambda Function URL?
We’re just leaning towards handling it transparently, but would appreciate your feedback.
Thanks!
JT
So the credentials will be stored in the hub and passed along with the correct service header?
Exactly. You’ll use the same “Lambda (Access Key)” route type, add your URL, credentials and region just like normal.
Whether it’s using an AWS API gateway, or a Lambda Function URL, we send the correct header to Amazon.
Hey, JimC!
I wanted to follow up here. This feature got pushed to production a couple weeks ago. If you have a chance to check it out, I’d love to know if it works for you.
Thanks!
JT
