Remix.run Logo
pjm331 3 hours ago

https://pragprog.com/titles/lhelph/functional-web-developmen...

don't let the title fool you - the first half of the book is just elixir

over the past 8 years this is the book i've used to ramp back up on elixir and it works like a charm every time - i've never finished it

for me, a mark of a good programming book in this tutorial-project style is that I have started it half a dozen times and never finished it because at some point before the end I've been equipped w/ the tools to go off and do my own thing

mechanicum 2 hours ago | parent | next [-]

FYI, that’s currently available in a Humble Bundle with 16 other PragProg functional programming books: https://www.humblebundle.com/books/ultimate-functional-progr...

roblh 2 hours ago | parent [-]

Great find, grabbed that. Thanks!

kajman 2 hours ago | parent | prev | next [-]

I've heard that Phoenix has changed a lot since that book was written. How relevant are those framework specific parts still?

sevenzero 3 hours ago | parent | prev | next [-]

Yea I've worked through Elixir in Action and appreciate all book recommendations. My issue is, tutorial style books rarely cover security related concerns.

felixgallo 2 hours ago | parent [-]

what do you mean by 'security related concerns'?

sevenzero 2 hours ago | parent [-]

How to properly build a liveview thats safe against hijacking the websocket phoenix uses for liveviews. You can just do it from the devtools on client side. With regular HTTP requests at least I know what to look out for, with liveview there are almost no resources on how to build a view securely. Like I was able to just call the functions in my module by just addressing them from my browsers console. Just to name an example.

OkayPhysicist an hour ago | parent [-]

[1] https://phoenix-live-view.hexdocs.pm/security-model.html

There's a guide in the LiveView docs that walks you through the security model. To be clear, you need to always assume that the user can send you anything. That's a fact of any networked system: Clients need to be assumed to be completely under the control of an evil user, because at the end of the day it is impossible to know whether you're talking to the client you wrote, or some evil program written by an adversary. Any function that acts as a handler for an event/message can be called by the user, at any time. You have to use session/socket state to handle authorization.

parthdesai 2 hours ago | parent | prev [-]

There's also the "bible": https://www.manning.com/books/elixir-in-action-third-edition