You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like to add support for https://github.com/excon/excon, but it doesn't follow the current model of having a request object to decorate. Instead it uses a parameter hash to pass through headers, body, request method, etc.
It seems less than ideal to map any instance of a hash passed to ApiAuth to an excon request driver.
Excon does support middleware, so I was thinking I could build a middleware, then an class that wrapped the params hash, then support mapping that to an excon request driver. So approximately three new classes. I think ApiAuth is the right home for those classes.
I can create a PR to demonstrate the change, but it would mean for excon support people would have to add the middleware rather than call sign directly.
Is that the right approach? Any other suggestions?
The text was updated successfully, but these errors were encountered:
I'd like to add support for https://github.com/excon/excon, but it doesn't follow the current model of having a request object to decorate. Instead it uses a parameter hash to pass through headers, body, request method, etc.
It seems less than ideal to map any instance of a hash passed to ApiAuth to an excon request driver.
Excon does support middleware, so I was thinking I could build a middleware, then an class that wrapped the params hash, then support mapping that to an excon request driver. So approximately three new classes. I think ApiAuth is the right home for those classes.
I can create a PR to demonstrate the change, but it would mean for excon support people would have to add the middleware rather than call sign directly.
Is that the right approach? Any other suggestions?
The text was updated successfully, but these errors were encountered: