Drab: remote controlled frontend framework for Phoenix

Are you updating the assigns with the partial given?

poke socket, "hero_slides.html", hero_slides: ...

?

Thanks, I’ve totally forgot to include partial template when I call poke.

Cool.
I am thinking about changing this behavior, so when you not specify the template name, it changes it in all.

Did you manage to do that? Having to return to eex templates would be a real show-stopper for me.

No, sorry, I didn’t try. I’ve started aorking on my own thing instead…

Drab looks really interesting and I am hoping it will be a fit for an experimental project I m working on. I am trying to get drab working but running into an error “Erlang error: :notsup” when executing page render DrabExample.PageView.“index.html”/1

After digging a bit it seems to be coming from lib/plug/crypto/message_encryptor.ex. The call that fails is :crypto.block_encrypt(:aes_gcm, key, iv, {aad, plain_text})

This is likely an issue with my environment (OS X Sierra 10.12.6), OpenSSL 1.0.2l 25 May 2017

iex> :crypto.supports()
[hashs: [:sha, :sha224, :sha256, :sha384, :sha512, :md4, :md5, :ripemd160],
ciphers: [:des3_cbc, :des_ede3, :des3_cbf, :des3_cfb, :aes_cbc, :aes_cbc128,
:aes_cfb8, :aes_cfb128, :aes_cbc256, :aes_ctr, :aes_ecb, :aes_ige256,
:des_cbc, :des_cfb, :des_ecb, :blowfish_cbc, :blowfish_cfb64, :blowfish_ofb64,
:blowfish_ecb, :rc2_cbc, :rc4],
public_keys: [:rsa, :dss, :dh, :ec_gf2m, :ecdsa, :ecdh, :srp]]

iex> :ssl.versions
[ssl_app: ‘8.1.1’, supported: [:“tlsv1.2”],
available: [:“tlsv1.2”, :“tlsv1.1”, :tlsv1, :sslv3]]

My past Phoenix projects have not hit any issue, but may not have exercised this particular crypto path. Asking here in case anyone has had this issue or has an idea how to resolve it.

Any advice is greatly appreciated.

That does not seem like a drab error, rather that sounds like some application is not started that should have been started. What is your entire mix.exs file and your projects application file?

Hey @piex,
Yes, Drab is using Plug’s MessageVerifier to sign the tokens.
And yes, it looks like your environment issue. You are missing :aes_gcm.

On my system it’s there:

ex(3)> :crypto.supports()[:ciphers]
[:des3_cbc, :des_ede3, :des3_cbf, :des3_cfb, :aes_cbc, :aes_cbc128, :aes_cfb8,
 :aes_cfb128, :aes_cbc256, :aes_ctr, :aes_ecb, :aes_gcm, :aes_ige256, :des_cbc,
 :des_cfb, :des_ecb, :blowfish_cbc, :blowfish_cfb64, :blowfish_ofb64,
 :blowfish_ecb, :rc2_cbc, :rc4]

Not sure it is openssl version or erlang. I am using built-in openssl in macOS Sierra (OpenSSL 0.9.8zh 14 Jan 2016) and OpenSSL 1.0.1t 3 May 2016 on Debian.

Thanks grych, that confirmation was all I needed. I had been using the Erlang Solutions installer to manage switching between several Erlang versions but all of their builds seem to be missing :aes_gcm cipher. I switched to point to the brew installed version of Erlang and it includes :aes_gcm and now works. Thanks much.

Maybe it would be good to report it to plug team? They may want to check if you have a cipher before trying to use it, and change it, or at least give a better error message.