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

[Feature] Add request/fetch/AJAX support to lambdas #267

Closed
voidmain opened this issue Aug 13, 2019 · 18 comments
Closed

[Feature] Add request/fetch/AJAX support to lambdas #267

voidmain opened this issue Aug 13, 2019 · 18 comments
Assignees
Labels
feature paid-feature Targeted for the paid editions of FusionAuth
Milestone

Comments

@voidmain
Copy link
Member

voidmain commented Aug 13, 2019

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.

@jerryhopper
Copy link

jerryhopper commented Oct 19, 2020

Suggestion:
Instead of requesting data from within the lambda function, how about passing a variable to the lambda via the auth-request?

Wouldnt it be handy if one could have some url-parameter in the authorization request, and have that accessible via the jwt_populate function?
This way, the authorization request could send data like the 'device-id' or alike - and have that reflected in the token after succesfull login.

the 'state' parameter could be used to stay within the openid standard, but a custom url var could suffice too.

@fdlk
Copy link

fdlk commented Oct 20, 2020

@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.

@robotdan
Copy link
Member

robotdan commented Oct 27, 2020

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

@mooreds
Copy link
Collaborator

mooreds commented Dec 9, 2020

Could possibly be a premium feature.

@mooreds mooreds added the paid-feature Targeted for the paid editions of FusionAuth label Dec 9, 2020
@robotdan
Copy link
Member

robotdan commented Dec 9, 2020

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.

@mooreds
Copy link
Collaborator

mooreds commented Dec 9, 2020

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 fetch via a java object which performs a check before making the call?

@trevorr
Copy link

trevorr commented Jan 27, 2021

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.

@mooreds
Copy link
Collaborator

mooreds commented Jan 27, 2021

@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.

@trevorr
Copy link

trevorr commented Jan 27, 2021

Thanks @mooreds. I definitely appreciate you having some of that discussion here and giving us the opportunity for feedback.

@robotdan
Copy link
Member

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.

@trevorr
Copy link

trevorr commented Jan 27, 2021

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).

@robotdan
Copy link
Member

Good question @trevorr - no idea. ;-) That is future @robotdan 's problem. TBD.

@lilyannh
Copy link

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.

@franklouwers
Copy link

What's the latest on this? This is preventing us from rolling out FusionAuth

@mooreds
Copy link
Collaborator

mooreds commented Dec 16, 2021

@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/

@mooreds
Copy link
Collaborator

mooreds commented Dec 21, 2021

Internal note: https://inversoft.slack.com/archives/C026DDDPQRY/p1640110581003100?thread_ts=1640110546.002900&cid=C026DDDPQRY has a useful example of possible lambda code.

@robotdan robotdan added this to the 1.34.0 milestone Jan 11, 2022
@robotdan robotdan modified the milestones: 1.35.0, 1.34.0 Feb 7, 2022
@robotdan robotdan modified the milestones: 1.34.0, 1.35.0 Feb 17, 2022
@robotdan robotdan changed the title Add request/fetch/AJAX support to lambdas [Feature] Add request/fetch/AJAX support to lambdas Mar 9, 2022
@robotdan
Copy link
Member

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.

@theogravity
Copy link

theogravity commented Dec 13, 2022

Is there documentation / examples on how this works?

Edit:

I found it via

https://fusionauth.io/docs/v1/tech/lambdas/#using-lambda-http-connect

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature paid-feature Targeted for the paid editions of FusionAuth
Projects
None yet
Development

No branches or pull requests

9 participants