django-mjml icon indicating copy to clipboard operation
django-mjml copied to clipboard

Setting necessary for allowing custom authentication/transport for http backend

Open alex-kowalczyk opened this issue 3 years ago • 5 comments

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

alex-kowalczyk avatar Mar 28 '22 09:03 alex-kowalczyk

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

liminspace avatar Oct 07 '22 00:10 liminspace

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

alex-kowalczyk avatar Feb 27 '23 14:02 alex-kowalczyk

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

Alexerson avatar Apr 24 '23 20:04 Alexerson

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

liminspace avatar May 01 '23 17:05 liminspace

Thanks. See PR.

Alexerson avatar May 01 '23 17:05 Alexerson