htmx Web Security Basics
95 points
4 months ago
| 3 comments
| htmx.org
| HN
eddd-ddde
4 months ago
[-]
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.

reply
indigodaddy
4 months ago
[-]
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
reply
bitexploder
4 months ago
[-]
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.

reply
KronisLV
4 months ago
[-]
> 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.

reply
bitexploder
4 months ago
[-]
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.
reply
Joker_vD
4 months ago
[-]
Oh, so you can use something other than * in Access-Control-Allow-Origin? That's good to know!
reply
indigodaddy
4 months ago
[-]
Ok right so at web server or r. proxy level
reply
aitchnyu
4 months ago
[-]
I disable htmx.config.allowScriptTags, which is true by default and "determines if htmx will process script tags found in new content". Also htmx.config.selfRequestsOnly which prevents cross-origin requests.

https://v2-0v2-0.htmx.org/reference/#config

reply
deisteve
4 months ago
[-]
anybody remember there was a library that combined htmx + alpinejs as one ?
reply
indigodaddy
4 months ago
[-]
Alpine Ajax maybe?

https://alpine-ajax.js.org/

reply
deisteve
4 months ago
[-]
there was actually another library but alpine ajax is close tooo
reply
moritzwarhier
4 months ago
[-]
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/

reply
deisteve
4 months ago
[-]
i found it https://data-star.dev/

never used it curious to know if anybody have

https://news.ycombinator.com/item?id=41482052

reply
moritzwarhier
4 months ago
[-]
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".

reply
deisteve
4 months ago
[-]
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
reply
imacrayon
4 months ago
[-]
Help me understand why you need the JSON in these examples…You’re rendering JSON data on the frontend just to transform it into HTML. The HTML is rendered server-side, so you should be able to skip the JSON and embed the data in HTML, right? `<input name="firstName" value="John">`
reply
indigodaddy
4 months ago
[-]
Cool I’d be interested as well then
reply
lenkite
4 months ago
[-]
https://unpoly.com/ ? The name is really hard to remember for some reason.
reply
JodieBenitez
4 months ago
[-]
unpoly is excellent !
reply
deisteve
4 months ago
[-]
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
reply
recursivedoubts
4 months ago
[-]
reply
deisteve
4 months ago
[-]
yup!
reply