Except of course they could just scrape a page every time they want to hit the websocket again. 
Websocket’s security is far different from pages. 
It’s not really page based or even page-safe, it’s only permissions/token safe (assuming the permissions and tokens are safe to begin with, I.E. a page-specific token is not really).
Sure. But they need to keep the scraper connected, if they want to reuse the token. It is going to be invalid after disconnection. Not very handy method of attack
Got your point. Yes, you may open the browser, keep it connected and just try to run random handler names, using the common name like “button_clicked” or “Overmind.generate_form”, etc, to find out the function which is a Drab Handler (it is in the connected commander, or it is public in the shared one).
Now I am thinking about whitelisting handlers also in the “standard” commanders. Now you need to keep in mind that public functions there are actually handlers, all of them (with arity of 2 or 3). It is mentioned in the docs, but who reads the docs those days
Hi Grych
I had some trouble using Drab on a very simple case : I just need to toogle a button and change its format depending on Drap’s. Since I render this button n times on the page, I couldn’t use Drap assign. My point is in the Drab.Element module functions answer tupples like {:ok, 3} which makes it hard to use in a pipe.
I ended up with this (which I am not very proud of).
Any suggestion on how better I could do ?
Is there a way to render a partial for this button from Drab ?
case Contents.toogle_pack_item(item_id, pack_id) do
{:created, pack_item} ->
socket
|> Drab.Browser.console("PackItem created for item #{item_id} and pack #{pack_id}")
|> set_attr("a.item[id='#{item_id}']", class: "item waves-effect waves-light btn validate")
socket
|> set_prop("a.item[id='#{item_id}']", innerHTML: "Remove")
socket
|> insert_html("a.item[id='#{item_id}']", :beforeend, "<i class='toogle_btn material-icons left'>remove_circle_outline</i>")
{:deleted, pack_item} ->
socket
|> Drab.Browser.console("PackItem removed for item #{item_id} and pack #{pack_id}")
|> set_attr("a.item[id='#{item_id}']", class: "item waves-effect waves-light btn light")
socket
|> set_prop("a.item[id='#{item_id}']", innerHTML: "Add")
socket
|> insert_html("a.item[id='#{item_id}']", :beforeend, "<i class='toogle_btn material-icons left'>add_circle_outline</i>")
{:error, _} ->
socket
|> Drab.Browser.console("Couldn't create PackItem between item #{item_id} and pack #{pack_id}")
end
Hi @thib,
it looks OK.
Drabs API is a little bit chaotic now, as some of bang functions returns sockets (so they could be stacked), and some not it must be changed before going stable. Also, there is a plan to group instructions like this (series of set_prop, set_attr, etc) into one, so behind the scenes it would not send this instructions one by one (and wait for the answer!), but in one bunch.
About the partials, you may use it with Drab! Take a look here. I need to add an example of this feature on the demo page.
Hi folks,
quick update about what’s cooking in the Drab kettle.
The next big release will be about Commanders and there will be changes in the API. Sorry for this, but I believe it makes sense. Please comment.
use Drab.Controller is going to be optional, if the corresponding commander exists
all event handlers, even those in the “normal” commander, must be declared as handlers; and instead of using existing public [:handler1, :handler2] macro, I am thinking about something like defhandler clicked(socket, payload). This is because I want to make sure when you are writing a public function in the commander, you are aware that it could be run from the client side!
shared commanders must behave like the standard commanders, so all callbacks must work
for the above (for onload, onconnect and ondisconnect), Drab must somehow know which commanders are used on the page. I could read it on the client side, but I do not consider it safe. For now I think I’m gonna force to declare shared commanders with use Drab.Controller, commanders: [Shared1, Shared2] in the controller, which generated the page.
when using shared commander inside the <tag drab-commander=MyCommander>, all the reads and updates are going to be done only inside this tag.
Hello, I am using drab to update queues on server.
In my app, i call poke frequently, and it worked perfectly :).
but i just wonder if there is any way to disable logs.
defp monitor_exq(socket) do
processes = Sally.Utils.Exq.current_processes()
jobs = Sally.Utils.Exq.current_jobs()
poke socket, processes: processes, jobs: jobs
:timer.sleep(3000)
monitor_exq(socket)
end
[debug] INCOMING "event" on "__drab:same_path:/admin" to Drab.Channel
Transport: Phoenix.Transports.WebSocket
Parameters: %{"event_handler_function" => "Drab.Live.Commander.save_assigns", "payload" => %{"__assigns" => %{"gi2tombvguydmnrs" => %{"jobs" => "QTEyOEdDTQ.8ZgkqtnP4eel91aB7QlQB_hDn4XxIgH0X_TeSclbEyFGcEfc4Vfs-UTJd3M.nVU40XJ4mpIPpb9d.Ct_sPkU-pVNrIUo6iB0TqbRul3IvtosrV1KIng.N6bBncQ-51JhWUlUtRe_Rg", "processes" => "QTEyOEdDTQ.8N6RjPO91gN4DcUg-6nDapu4vOoQAy6UXcQVuI0-Y151g9amiPMV_auNOOQ.kvtCWx8kwfyVEl4T.iehsOHUn.Gmvf8LpDDfpRyrfi-ZpZ3Q"}}, "__index" => "gi2tombvguydmnrs"}, "reply_to" => "e78b550d-bd72-465e-9df3-4a7d8579cad2"}
Not currently, but it is a way to pass the logging options to Phoenix.Channel. Could you please create a github issue with this, so it won’t be forgotten?
