Setting necessary for allowing custom authentication/transport for http backend

liminspace / django-mjml

The simplest way to use MJML in Django templates.

MIT License

260 stars 32 forks source link

Setting necessary for allowing custom authentication/transport for http backend #163

Open alex-kowalczyk opened 2 years ago

alex-kowalczyk commented 2 years ago

Current architecture does not allow for any other authentication than 'static' HTTPBasicAuth user+password. It is impossible to authenticate MJML server via API Keys, OAuth2, custom auth header without monkey-patching or forking the code.

Simplest idea: there could be provided a new MJML_HTTP_TRANSPORT setting with a string being dotted module path to a transport function, accepting kwargs: url, auth, data, headers, timeouts. Such a config would allow users to procure custom authentication inside and call requests.post or any other transport from user's code. If not provided, requests.post could be used as-is.

Using dotted path string will avoid importing this function in settings.py - this follows typical django pattern. The transport function can be imported lazily before use through django.utils.module_loading.import_string

liminspace commented 1 year ago

@alex-kowalczyk Is there any MJML backed that uses API Keys or OAuth2?

alex-kowalczyk commented 1 year ago

@liminspace I don't think that backends support that authentication directly, but it is quite common for self-hosted setups to host services behind authentication proxy, for instance with OAuth2-based JWTs in Google Cloud. Custom transport allowing to plug any authentication would be useful to integrate with such self-hosted backends.

Alexerson commented 1 year ago

@liminspace would you be open for a PR for this? We are hosting the MJML function in AWS Lambda with an API Gateway and one easy way to limit access to it would be to add ApiKey Auth. There are 2 ways I seed that could handle this use-case:

adding a different key to the settings (like API_KEY) and simply add it to the headers in https://github.com/liminspace/django-mjml/blob/main/mjml/tools.py#L119 (but this would be maybe too specific)
allow HTTP_AUTH to be whatever is accepted by requests, and not just a tuple.

I think the 2nd solution would be easy to implement and non-breakable. If you’re willing to consider it, I can propose a PR.

liminspace commented 1 year ago

@Alexerson sure, you can show your solution and I'll take it in implementing the feature

Alexerson commented 1 year ago

Thanks. See PR.