[HN Gopher] htmx Web Security Basics
___________________________________________________________________
htmx Web Security Basics
Author : indigodaddy
Score : 63 points
Date : 2024-09-08 14:40 UTC (8 hours ago)
(HTM) web link (htmx.org)
(TXT) w3m dump (htmx.org)
| eddd-ddde wrote:
| You don't have to disable CORS to call routes on a different
| domain. Just configure your server properly so it knows which
| sites can have access to the routes.
|
| That's literally the whole point of CORS.
| indigodaddy wrote:
| So like for Python just use request referrer and then have some
| logic for allowed referrer/URLs on all routes or something like
| that? Or is that something you'd more want to do at the web
| server or proxy level like with gunicorn/nginx/caddy? I have
| gunicorn in front and have been doing similarly at the
| Python/route level
| bitexploder wrote:
| This is overthinking it:
|
| https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
|
| You configure it mostly in HTTP headers, generally at your
| HTTP server/static asset serving level.
| Joker_vD wrote:
| Oh, so you can use something other than * in Access-
| Control-Allow-Origin? That's good to know!
| indigodaddy wrote:
| Ok right so at web server or r. proxy level
| KronisLV wrote:
| > If the server specifies a single origin (that may
| dynamically change based on the requesting origin as part
| of an allowlist) rather than the "*" wildcard, then the
| server should also include Origin in the Vary response
| header to indicate to clients that server responses will
| differ based on the value of the Origin request header.
|
| I dislike this about CORS, especially when you'd want to
| configure it at the web server/ingress level, but suddenly
| need dynamic logic to return the appropriate header, for
| example here's an older example I used when fronting some
| apps with Apache: https://stackoverflow.com/a/22331450
|
| I understand why it's in place (because you probably
| shouldn't leak all of the allowed domains), but dealing
| with that can be a bit awkward.
| bitexploder wrote:
| Yeah, browser security on the whole is surprisingly
| complicated. SameSite cookies, CORS, CORS Preflight, the
| in the weeds behaviors of many things are just invisible
| or not intuitive until you are deep into them.
| deisteve wrote:
| anybody remember there was a library that combined htmx +
| alpinejs as one ?
| indigodaddy wrote:
| Alpine Ajax maybe?
|
| https://alpine-ajax.js.org/
| deisteve wrote:
| there was actually another library but alpine ajax is close
| tooo
| indigodaddy wrote:
| Cool I'd be interested as well then
| moritzwarhier wrote:
| I'm not an active user of both (but used Alpine in the
| past), but this is not what you are seeking, or is it?
|
| https://v1.htmx.org/extensions/alpine-morph/
| deisteve wrote:
| i found it https://data-star.dev/
|
| never used it curious to know if anybody have
|
| https://news.ycombinator.com/item?id=41482052
| moritzwarhier wrote:
| Ah OK, thanks for your reply.
|
| Wasn't sure what you meant by "bringing together".
|
| I assumed you were meaning to connect both, not replace.
|
| Fair though.
|
| I'm wondering whether the next big thing in this space is
| going to be more BE-driven and include streaming larger
| fragments or some other sort of improvement.
|
| Anything that does more than Alpine and htmx so far seems
| to struggle bringing innovation.
|
| It was fun once working on a Laravel project where it was
| somdtimes confusing for a new collaborator to make sense
| of which "x-attributes" were Alpine, so client-JS-related
| and which ones were part of server-side Blade templates,
| so dynamic but not "reactive".
|
| This naming collision was preventable and misleading, but
| it somehow still "felt right".
| deisteve wrote:
| I also think server-rendered reactive apps are the
| future. Elixir/Pheonix comes to mind but the liveview
| stuff seems complex for most FE apps which don't require
| more efficient data diff over the wire.
|
| i'd say most FE apps are just fetching stuff from BE via
| rest api and while i think rpc, tanquery all this stuff
| hides all that plumbing by blending it, but if you get BE
| to render it from the get go with all the state is
| handled on the server you wouldn't need FE devs
|
| an entire BE team could create a REACTy application even
| with existing solutions like inertia.js
|
| going back to htmx, this is interesting aspect of morph:
| <div hx-target="this" hx-ext="alpine-morph" hx-
| swap="morph"> <div x-data="{ count: 0,
| replaced: false, message:
| 'Change me, then press the button!' }">
| <input type="text" x-model="message"> <div
| x-text="count"></div> <button
| x-bind:style="replaced && {'backgroundColor': '#fecaca'}"
| x-on:click="replaced = true; count++"
| hx-get="/swap"> Morph
| </button> </div> </div>
|
| but then in datastar its very straight forward but its
| doing different things I understand.
| data-store="{ id: 1, firstName:
| 'John', lastName: 'Doe', email:
| 'joe@blow.com' }"
|
| gets appended as an attribute to id=contact_1 similar to
| htmx-morph but this is far more readable and intuitive
| imho <div id="contact_1">
| <label>First Name: John</label> <label>Last Name:
| Doe</label> <label>Email: joe@blow.com</label>
| <div> <button data-on-
| click="$$get('/examples/click_to_edit/contact/1/edit')">
| Edit </button> <button data-on-
| click="$$get('/examples/click_to_edit/contact/1/reset')">
| Reset </button> </div> </div>
|
| one thing that concerns me about datastar is that its
| quite new but seems at least its updated weekly although
| the last release i see is 4 months ago
| lenkite wrote:
| https://unpoly.com/ ? The name is really hard to remember for
| some reason.
| JodieBenitez wrote:
| unpoly is excellent !
| deisteve wrote:
| i never got used to it. I want to get into it but im not
| sure what it is that stops me from using unpoly more
| recursivedoubts wrote:
| maybe https://data-star.dev/?
| deisteve wrote:
| yup!
___________________________________________________________________
(page generated 2024-09-08 23:01 UTC)