#elixir-lang - 24 June 2019
« Back 1 day
[02:07:04] ariedler: hypercore: the feelz when you find a ticket that has been open for > 3 years; or has been closed
[05:52:34] serafeim: Nicd-: hey do you feel there wouild be any problems if I put my codestats key in my (public) VS Code settigns repo: https://github.com/spapas/vscode-settings ?
[08:48:20] dysfun: one assumes he'd like to apply an ORDER BY to the list of entries that will get preloaded
[11:45:33] nickjj: if you wanted to call the same function in 2 controllers but you didn't want that function to be in a context since it depends on phoenix, where would you place that function?
[11:47:37] nickjj: for reference, this isn't a plug either, it's just something i want to do in both controllers but the thing i'm doing isn't related to either controller specifically
[11:48:27] nickjj: thanks, i was thinking something similar by having a utils.ex file in controllers/ but controller_helpers.ex sounds a lot better and follows the style of other similar files
[11:50:01] serafeim: no prob! i'm doing something similar with view_helpers.ex: https://github.com/spapas/phxcrd/blob/master/lib/phxcrd_web/views/view_helpers.ex to hold a bunch of useful global functions for views
[11:55:15] serafeim: nickjj: correct i think you should name it view_helpers or view_utils or something
[11:56:04] nickjj: the functions you have in _helpers.ex are being used in your templates , where as the _view.ex files are really rendering responses for a specific view?
[11:58:03] serafeim: i have included an `import xx.ViewHelpers` to my _web.ex so these are easily available to my templates: https://github.com/spapas/phxcrd/blob/master/lib/phxcrd_web.ex
[12:02:47] nickjj: so here's a fun question, taking this 1 step further, if you wanted to share a function between a controller and a channel , where would that go?
[12:04:49] Nicd-: in a helpers/utils file in the web app, on a level higher than controllers/channels
[12:07:05] nickjj: thanks, this use case is for signing and verifying phoenix tokens -- Phoenix.Token is pretty short, but i'm reading certain things from env variables which makes the call kind of long (especially in case condition 1 liners in my controller)
[12:09:24] serafeim: hm from what I see i've just dumped `Phoenix.Token.verify` in my `user_socket.ex` and `Phoenix.token.sign` in the `layout\app.html.eex`
[12:09:37] serafeim: maybe it's no the best way to do it but i just use the defaults from what i see
[12:09:58] nickjj: i'm currently using phoenix token in my controllers too, because my authentication is done by magic links and phoenix.token handles the token in the link
[12:11:50] nickjj: so i wound up with this in an accounts context https://gist.github.com/nickjj/60992c76fe1c95a74ff1cdb168bd6fb5 , which now i'm seeing is a problem because it still depends on phoenix (i just got to the umbrella app part of the programming phoenix book and it hints that your non-web app shouldn't depend on phoenix)
[12:12:49] serafeim: nickjj: i think i had a discussion here before some days that the value of the salt you pass doesn't matter
[12:13:41] serafeim: nickjj: actually it's safe to just use "user salt" for your token verification. at least that's what I remember
[12:14:15] serafeim: nickjj: it *does* seem strange though so don't take my word for it maybe somebody else can explain if that's the fact
[12:14:50] nickjj: i'm googling now and the general census seems to be that the salt value is app wide, but it doesn't mention whether or not it should be publicly available (think of an open source project for example)
[12:17:13] serafeim: dysfun: we are talking about the value you pass to the sign/verify token function
[12:17:54] nickjj: in my case, "user salt" is coming from an env variable that is then set in a config file -- so it's app wide but out of version control
[12:19:59] nickjj: but the interesting thing is https://elixirforum.com/t/phoenix-token-for-api-auth-salt-per-user-or-per-app/13361
[12:20:42] nickjj: some of those replies hint that maybe it's just a namespace and not really a traditional salt
[12:23:10] griffinbyatt: It's best practice not to re-use secrets in different contexts, so there is key generation functionality to generate different keys based on the same secret key base
[12:24:18] nickjj: what is a context in this case? would you be expected to use different values for generating an email auth token for a magic link vs. a channel auth token?
[12:25:33] nickjj: ok, so when in doubt keep doing what i'm doing -- since you probably can't go too wrong keeping it private in the end?
[12:32:26] serafeim: yes but would that be a problem if i just used "user salt" and put it on version control or even publish it on the internet ?
[12:36:52] nickjj: well, clear in the sense that either option is equally as safe, encryptor vs signer is black hole of wiki articles for another day hah a
[13:18:22] keathley: josevalim: One of my services runs a nightly CI build using ecto master (amongst other things) and I think I just discovered a regression around the PARTITION syntax for postgres. I saw that there was some changes done to partition in ecto recently. Didn't know if you wanted me to open an issue and if so what repo it should be on.
[15:33:21] josevalim: tristan__: i don't know if you are notified when it goes from draft to reaedy for review, but this is good to go! https://github.com/howistart/howistart-hakyll/pull/5