-
Notifications
You must be signed in to change notification settings - Fork 12
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
[Feature] Add request/fetch/AJAX support to lambdas #267
Comments
Suggestion: Wouldnt it be handy if one could have some url-parameter in the authorization request, and have that accessible via the jwt_populate function? the 'state' parameter could be used to stay within the openid standard, but a custom url var could suffice too. |
@jerryhopper The thing is, the code in the relying party is not always under control. The nice thing about the lambda’s is that in such cases they glue any discrepancies together. |
I'll note that the main limitation here is that we are using an old JS engine, and we will have to upgrade this soon as it being removed from the JDK. So when we deliver issue #571 and replace Nashorn with something more modern, such as v8we hope to get this support for free more/less. This is getting close to being on the short list due to the impending deprecation and removal of Nashorn from the JDK. We are currently on version 14, and it will be removed in 15 - and we plan to upgrade to 16 once available. So this deadline is approaching quickly. AdoptOpenJDK shows version 16 availability in March of 2021. https://adoptopenjdk.net/support.html |
Could possibly be a premium feature. |
We could consider that - it may be tricky to enforce this unless we parse the lambda or can turn off the feature within whatever engine we end up using. |
It looks like there are some permissions levels you can set in graaljs: https://www.graalvm.org/reference-manual/embed-languages/#access-restrictions Not sure which of them applies to network access. Could also provide a custom node fetch library: https://github.com/node-fetch/node-fetch (maybe) or expose |
I'd like to lobby against making this a paid feature. Unlike the other paid features (e.g. breached password detection, LDAP/legacy integration, advanced MFA, customizable forms) which are primarily of interest to established companies and/or are add-ons not likely to influence the architecture of customer applications, this has use cases that are pretty fundamental for building a new app, such as fetching app-specific data (e.g. permissions) to be included in each JWT. To put it another way, I'd like to be able to build my app the best way I know how with free/community FusionAuth. Once it's generating revenue, I'd be happy to upgrade to support FA and get all the nice add-ons, but I wouldn't want to start reworking my authorization model at that point. |
@trevorr thanks for the feedback. We spend a fair bit of time internally discussing what makes sense as a paid feature and what makes sense to put in the community edition and always appreciate feedback from the community. |
Thanks @mooreds. I definitely appreciate you having some of that discussion here and giving us the opportunity for feedback. |
To add to what @mooreds said - this is not necessarily going to be paid feature, but anything is possible. This was opened a while back when we just knew that we wanted to support this in some fashion - and we didn't know if we'd have to build this ourselves or get it for free within the script engine. We are going to have to ditch Nashorn very shortly for something better since it is now deprecated in Java 15. See #571 My guess is that whatever option we pick to replace Nashorn will come with AJAX support and we won't have to write it ourselves. In this context, I don't know that it would make sense to lock any of this down. |
Do you have any thoughts on how this affects lambda types to support asynchronous code? That seems to be the other piece of this. For example: function populate(jwt, user, registration) {
fetch(...).then(() => {
// How do I let FusionAuth know I'm done populating?
});
} If using a modern JS engine, I suppose you could return a promise to let FA know it needs to wait. That should be compatible with existing lambdas (which don't return promises). |
This is a show stopper for the app I am currently working on (I need to be able to augment my JWT with session level data during login). I actually find #267 (comment) about simply passing in the value as a variable, to address my needs just fine. It's also the simplest solution, given that you wouldn't need to worry about async). They way I see it, my application can do the lifting for the AJAX immediately before sending the login api call, so I don't need FusionAuth to be able to do it from within the lambda. |
What's the latest on this? This is preventing us from rolling out FusionAuth |
@franklouwers we're been discussing this internally, the update to java17 (included in release 1.32) makes it more straightforward to implement. But in general we can't commit to timelines outside of a signed professional services statement of work. I'm sure you understand that we have multiple competing priorities (haha, doesn't everyone!), but we'd love to get this out because it looks really useful. Here's our general roadmap guidance: https://fusionauth.io/docs/v1/tech/core-concepts/roadmap/ |
Internal note: https://inversoft.slack.com/archives/C026DDDPQRY/p1640110581003100?thread_ts=1640110546.002900&cid=C026DDDPQRY has a useful example of possible lambda code. |
PSA: Support for HTTP requests will be out in 1.35.0. With this support you'll be able to make a REST call to FusionAuth over localhost, so in theory that should open a lot of doors for getting more data in the lambda. If you can get it with a FusionAuth API, you can get it in the lambda. The first release is just a tech preview, we'll be adding more features shortly such as secret management. |
Is there documentation / examples on how this works? Edit: I found it via https://fusionauth.io/docs/v1/tech/lambdas/#using-lambda-http-connect |
Add the ability to make HTTP requests from lambdas
Problem
Currently, lambdas are not able to make HTTP calls to external services. This makes it difficult to pull in additional data for users or to call APIs during different workflows.
Solution
Implement one of the standard JavaScript APIs for lambdas to make HTTP requests.
Alternatives/workarounds
None currently.
Related Issues
How to vote
Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.
The text was updated successfully, but these errors were encountered: