Implement auth0-forwarded-for header passing in Authentication Client

[kjarmicki]

Changes

This PR implements auth0-forwarded-for header passing in the Authentication Client.
User-facing methods now accept an additional argument options, right before callback, for example:

client.passwordGrant(userData, {forwardFor: '1.2.3.4'}, callback);

This change is non-breaking. If there is no options object, the callback as a second argument will still work.

References

#191

Testing

• This change adds unit test coverage

I have also npm linked the module to my existing project and it seemed to do it's job.

Checklist

• I have read the Auth0 general contribution guidelines
• I have read the Auth0 Code of Conduct
• All existing and new tests complete without errors

[luisrudge]

Does it make sense to use this as an option per method? Maybe it's better to use as a global config instead?

[kjarmicki]

It would be neat to use as a global config, but I don't think it's possible. The IP value has to be taken from individual requests.

[luisrudge]

Why would it change on every request?

[kjarmicki]

Because as I understand it, it's about forwarding individual client's IP to Auth0 backend in order to tie brute force attempts with particular IPs.
Reference: https://auth0.com/docs/api-auth/tutorials/using-resource-owner-password-from-server-side#configuring-the-auth0-application-to-receive-and-trust-the-ip-sent-by-your-server

[luisrudge]

@kjarmicki ahh! Of course 😝

[damieng]

@luisrudge Let's make sure we have a cross-platform strategy/design for the other SDKs before we progress too far on this. Auth0.Net already has an issue open about providing similar functionality auth0/auth0.net#274

Whether you need to change IP per request really depends on whether you imagine the lifecycle of the client object being per user request or if you want to pool/hold it around to use it across multiple user requests. I don't think there is anything in it today that forces it to be used one way or another.

[luisrudge]

@damieng I agree, that's a good point. But, considering node-auth0 doesn't hold any state, there's no hard requirement to create one instance per request, right?

@kjarmicki how do you use this in your app? do you create one Management instance per request or one per application?

[kjarmicki]

@luisrudge we're initializing the client object once at the start of the application and reusing it throughout the life of the app. I think having a global initialization option would force the module users to re-initialize the client for each request while having it as a method option enables both use cases @damieng mentioned.

Personally, I think a global option way is a bit counterintuitive :) By definition auth0-forwarded-for header is tied to a particular request, so it's kind of like having username and password available as global options too.
I get that it seems like a good idea at first glance (I want to enable it for every request) and originally I wanted to use headers constructor option, but it fell apart when I realized that each time IP will be different.

[luisrudge]

@kjarmicki perfect. Thanks for your feedback. I'll discuss this internally and get back to you.

[kjarmicki]

@luisrudge howdy :) any news? If I can help in any way let me know.

[luisrudge]

@kjarmicki we're having some internal discussions on how to tackle this across all of our SDKs. Sorry about the wait. I'll get back to you when I have more information.

[luisrudge]

@kjarmicki did you test this with all the methods? I just contacted our protocols team and only two grant types do this: password and password-realm. Can you modify the PR to apply this header only in those methods? Thanks!

[kjarmicki]

@luisrudge I did not, I assumed that all HTTP-based login methods support this header and checked the one we use (passwordGrant). I'll adjust my PR to affect only password and password-realm grant type methods.

[luisrudge]

Thanks for the PR! 🎉

[kjarmicki]

Yay! Thank you for support and merge :)
When do you guys plan to release it to npm?

[luisrudge]

Thursday!

[kjarmicki]

Perfect 👌

[luisrudge]

released in [email protected]

[cloudworkpro-derek]

This is not in types :( !