Skip to content
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

Support for async/await with typescript? #5

Open
jsancho opened this issue Apr 11, 2020 · 5 comments
Open

Support for async/await with typescript? #5

jsancho opened this issue Apr 11, 2020 · 5 comments

Comments

@jsancho
Copy link

jsancho commented Apr 11, 2020

Hi Emmanuel,

I've absolutely loved the approach on this project.
It does open up a familiar and elegant mechanism to plug common functionality that is sadly missing from the official SDK.

In my case, I have a custom handler to validate JWT from a provider that is not supported by Azure Functions.

The issue is that my project is using typescript and the async/await pattern, so it couldn't work out of the box.
I've butchered your code to the best of my abilities, but not gotten all that far - I'm more of a c# dev.

What I've managed to use handler to invoke my logic and do the JWT validation but I'm at a loss on how to do the hand-off from the middleware back to the entry function.

Seeing that there's been official typescript support from Microsoft for a while.

Would you consider adding support for it?

I'd be absolutely invaluable for me and I bet many others as well :)

@diegoazh
Copy link

@jsancho I made a PR #13 I hope that @emanuelcasco could review it and merge it as soon as possible

@diegoazh
Copy link

For someone that is finding a solution similar to middy and full typescript support can take a look at @racy/azure-middleware package.

@JamesIde
Copy link

JamesIde commented Aug 21, 2022

Just following up after a long time - I have exactly the same issue @jsancho. How did you solve this? The approach I thought of taking was to have nested try catch to first verify the token, then pass it to another try catch to fetch protected resources. Hacky at best.

@jsancho
Copy link
Author

jsancho commented Aug 22, 2022

Just following up after a long time - I have exactly the same issue @jsancho. How did you solve this? The approach I ended up taking was to have nested try catch to first verify the token, then pass it to another try catch to fetch protected resources. Hacky at best.

I did not end up using this project after all.
There might be other project that provide the middleware setup like diego suggests, but I've not been keeping track of them.

Mind, that It's been more than 2 years since I opened this issue and things have changed for the better with the Azure Functions SDK.

Azure Functions v4 can now be created with a typescript template and support for async await [out-of-the-box].(https://docs.microsoft.com/en-us/azure/azure-functions/functions-reference-node?tabs=v2-v3-v4-export%2Cv2-v3-v4-done%2Cv2%2Cv2-log-custom-telemetry%2Cv2-accessing-request-and-response%2Cwindows-setting-the-node-version#use-async-and-await)

The documentation could be a little bit more organised, but it's definitely doable.

What I ended up doing in my case for auth purposes, was to have a helper function in a shared file that did the token verification.
So instead of using a middleware style configuration, I have an imperative function call to check on the token validity.

const httpTrigger: AzureFunction = async function (
    context: Context,
    req: HttpRequest
): Promise<void> {

    try {
        // I use AWS Cognito, you would call whichever verifier util to your auth system
        const claims = await CognitoVerifier(req);

        if (!claims.isValid){
          sendErrorCode(401, claims.error, context);
          return;
        }

        // [your business logic here...]     
        
    } catch (error) {
        context.log.error(error);
        context.res.status(500).send(error.message);
    }
};

export default httpTrigger;

Not an ideal config, because it peppers a fair bit of boilerplate to every function.
It could also lead to some security issues since editing this entry point file cold affect the auth logic somewhat.

@JamesIde
Copy link

Thanks for the response. I ended up solving it in a similar fashion. A helper isAuth method with context as a parameter, erroring out in the helper function if something happened. Then a simple if check wrapped around the business logic to see if a token was returned from the helper. Not the finest code to exist but it works and some rudimentary checks with postman seems to be fine. In terms of middleware solutions, scouring the web yielded very little. So a helper function was the best way forward.

All the best

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants