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

Unable to use tls with ElasticCache #72

Open
maedhr opened this issue Apr 20, 2020 · 4 comments
Open

Unable to use tls with ElasticCache #72

maedhr opened this issue Apr 20, 2020 · 4 comments

Comments

@maedhr
Copy link

maedhr commented Apr 20, 2020

Apparently ElasticCache needs a specific option set for tls to work. See https://hexdocs.pm/redix/Redix.html#module-ssl .

In a release you cannot serialize the configuration needed. I have a patch that adds a configuration option to set the socket options before connecting to Redix. Wanted to start a discussion on options before submitting a PR though.

@tompave
Copy link
Owner

tompave commented Apr 21, 2020

Hi, thank you for using the library and for bringing this up.

In a release you cannot serialize the configuration needed.

Do you mean that you can't pass a function in the Config when using a release?

Can you please explain what your proposed solution would be?

@maedhr
Copy link
Author

maedhr commented Apr 21, 2020

Yes. You can't serialize the :public_key.pkix_verify_hostname_match_fun(:https) socket option when in a release.

Check out planswell@299250b . It adds a new option, aws for lack of a better option. When present it will deep merge the config required for Redix to connect.

@tompave
Copy link
Owner

tompave commented Apr 23, 2020

I see, thanks for sharing.

To be honest I'm not too keen to add any AWS-specific config keyword. It might be the simplest solution, but it also doesn't seem very clean. This specific case is tricky because you can pass ssl: true, so using SSL with a Redis that is not AWS ElastiCache would work.

The package already provides a solution for this: custom persistence adapters. You could copy and modify the Redis persistence adapter, add ElastiCache support, and then configure it. You could also release it as a standalone plugin package on Hex. The problem perhaps is that you can't do this (yet?) with the notifications adapter[1], but then you can configure the package to use the Phoenix.PubSub notifications adapter instead of Redix.PubSub, and then maybe configure that to use Phoenix.PubSub.Redis under the hood, instead of Phoenix.PubSub.PG2.

How does that sound?

[1]: Customizing the notifications adapter is a less common requirement than customizing the persistence adapter, so I didn't add it to keep the complexity under control.

@chess4ever
Copy link

I have found a workaround, not very clean but it does the job. It is possible to define the config like this:

socket_opts: [
    verify: :verify_none,
    customize_hostname_check: [
      match_fun: &Elixir.MyApp.MyModule.pkix_verify_hostname_match_fun_https/2
    ]
  ]

and then define a specific module in your application:

defmodule MyApp.MyModule do
  def pkix_verify_hostname_match_fun_https(a, b) do
    :public_key.pkix_verify_hostname_match_fun(:https).(a,b)
  end
end

This works because this syntax of anonymous function with arity is serializable during releases in the sys.config file

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants