8 ms·

Usually it comes down: - easy client login for template tweaks, uploads, and redirects - forms - extremely minor server-side functionality thing WordPress i

by TIPSIO 2y ago

Usually it comes down: - easy client login for template tweaks, uploads, and redirects - forms - extremely minor server-side functionality thing WordPress is perfect for this.

sroerick 2y ago
“Extremely minor server-side functionality thing” is where SSGs fail miserably. All of a sudden you’re using SaaS forms or whatever else, or your self hosting some other tremendously inferior CMS and your margins go out the window. Wordpress killer that accomplishes these things you mentioned would interest me. Statamic looks interesting in this context but it wasn’t super well formed 4 years ago when I dug deep into this ecosystem
- amluto 2y ago
  20 years ago, CGI covered this use case pretty well. I wonder if anyone has tried to make a modern equivalent. Maybe something along the line of a Cloudflare Worker (but using the open source stack) or possibly something minimal and flexible based on WASM or JS that could be invoked from different servers could work.
  - sroerick 2y ago
    CGI / PHP is really not a bad way to work in 2024, even though I was traumatized by PHP in my early days. I’ve only experimented with it though, I think it would be hard to maintain at scale, and I’ve heard there are not insignificant security concerns. It’s a lot easier to hire somebody to maintain a Wordpress install than it is to mess with Apache or PHP. When I figured out that Wordpress literally is executing every piece of PHP every time the site loads it was kind of a “woah” moment for me Interesting idea with the Cloudflare thing
    - amluto 2y ago
      A problem with Wordpress and with most CGI setups is that there is no privilege separation between the script and anything else on the site. It would be nice to let individual pieces of server side script be deployed such that they can only access their own resources. I don’t think Cloudflare workers, as deployed by Cloudflare, really tick that box either. Some of the university “scripts” systems, with CGI backed by AFS, came kind of close.
      - kentonv 2y ago
        > I don’t think Cloudflare workers, as deployed by Cloudflare, really tick that box either. They mostly do. You can map different Workers to different paths in your site. A Worker can only access the resources it is explicitly bound to. E.g. if you create a KV namespace for storage, a worker can only access that namespace if you configure it with a "binding" (a capability in an environment variable) pointing at the KV namespace. Workers on your account without the binding cannot access the KV namespace at all. Some more on the philosophy in this blog post: https://blog.cloudflare.com/workers-environment-live-object-bindings/ https://blog.cloudflare.com/workers-environment-live-object-... There are a couple of caveats that exist for legacy reasons, but that I'd like to fix, eventually: * The HTTP cache is zone-scoped. Two workers running on the same zone (domain name) can poison each others' cache via the Cache API. TBH I want to rip out the whole Cache API and replace it with something entirely different, it is a bit of a mess (partly the spec's fault, partly our implementation's fault). * Origin servers are also zone-scoped. All workers running on a zone are able to send requests directly to the zone's origin server (without going back through Cloudflare's security checks). We're working on introducing an "origin binding" instead, and creating a compat flag that forces `fetch()` to always go back to the "front door" even when fetching from the same zone. Note that if you want to safely run code from third parties that could be outright malicious, you can use Workers for Platforms: https://developers.cloudflare.com/cloudflare-for-platforms/workers-for-platforms/ https://developers.cloudflare.com/cloudflare-for-platforms/w... (I'm the tech lead of Cloudflare Workers.) (EDIT: lol wrote this without reading your username. Hi, Andy!)
        amluto 2y ago
        The worker binding system seems pretty great. I'm thinking more about the configuration / deployment mechanism. In the old days, if I wanted to deploy a little script (on scripts.myuniversity.edu, for example), I would stick the file in an appropriate location (~username/cgi-bin, for example), and the scripts would appear (be routed, in modern parlance, but the route was entirely pre-determined) at a given URL, and they could access a certain set of paths (actually, anything that was configured appropriately via the AFS permission system). Notably, no interaction was needed between me and the actual administrator of scripts.myuniversity.edu, nor could my script do anything outside of what AFS let it do (and whatever the almost-certainly-leaky sandbox it ran in allowed by accident). But Cloudflare has a fancy web UI [0], and it is 100% unclear that there's even a place in the UI (or the command-line API) where something like "the user survey team gets to install workers that are accessible at www.site.com/surveys and those workers may be bound to resources that are set up by the sane team" would fit. And reading the "role" docs: https://developers.cloudflare.com/fundamentals/setup/manage-members/roles/ https://developers.cloudflare.com/fundamentals/setup/manage-... does not inspire confidence that it's even possible to pull this off right now. This kind of thing is a hard problem to solve. A nice textual config language like the worker binding system (as I understand it) or, say, the Tailscale ACL system, is nice in that a single person can see it, version it, change it, search-and-replace it, ask an LLM about it, etc. But it starts to get gnarly when the goal is to delegate partial authority in a clean way. Not that monstrosities like IAM or whatever Google calls their system are much better in that regard. [1] [0] Which I utterly and completely despise, but that's another story. Cloudflare, Apple, and Microsoft should all share some drinks and tell stories of how their nonsense control panels evolved over time and never quite got fixed. At least MS has somewhat of an excuse in that their control panels are really quite old compared to the others. [1] In the specific case of Google, which I have recently used and disliked, it's Really Really Fun to try to grant a fine-grained permission to, say, a service account. As far as I can tell, the docs for the command line are awful, and the UI kind-of-sort-of works but involves a step where you have to create a role and then wait, and wait, and wait, and wait, and maybe the UI actually notices that the role exists at some point. Thanks, Google. This is, of course, a nonstarter if one is delegating the ability to do something useful like create two resources and link them to each other without being able to see other resources. (Hi Kenton!)
- pier25 2y ago
  > is where SSGs fail miserably It's trivial to bundle and deploy some server-side code with a static site on Vercel, Cloudflare, Firebase, or Netlify. Usually you simply create a /functions directory wth your JS code and that's it.

by TIPSIO 2y ago

Usually it comes down: - easy client login for template tweaks, uploads, and redirects - forms - extremely minor server-side functionality thing WordPress is perfect for this.

sroerick 2y ago

“Extremely minor server-side functionality thing” is where SSGs fail miserably. All of a sudden you’re using SaaS forms or whatever else, or your self hosting some other tremendously inferior CMS and your margins go out the window. Wordpress killer that accomplishes these things you mentioned would interest me. Statamic looks interesting in this context but it wasn’t super well formed 4 years ago when I dug deep into this ecosystem

amluto 2y ago
20 years ago, CGI covered this use case pretty well. I wonder if anyone has tried to make a modern equivalent. Maybe something along the line of a Cloudflare Worker (but using the open source stack) or possibly something minimal and flexible based on WASM or JS that could be invoked from different servers could work.
- sroerick 2y ago
  CGI / PHP is really not a bad way to work in 2024, even though I was traumatized by PHP in my early days. I’ve only experimented with it though, I think it would be hard to maintain at scale, and I’ve heard there are not insignificant security concerns. It’s a lot easier to hire somebody to maintain a Wordpress install than it is to mess with Apache or PHP. When I figured out that Wordpress literally is executing every piece of PHP every time the site loads it was kind of a “woah” moment for me Interesting idea with the Cloudflare thing
  - amluto 2y ago
    A problem with Wordpress and with most CGI setups is that there is no privilege separation between the script and anything else on the site. It would be nice to let individual pieces of server side script be deployed such that they can only access their own resources. I don’t think Cloudflare workers, as deployed by Cloudflare, really tick that box either. Some of the university “scripts” systems, with CGI backed by AFS, came kind of close.
    - kentonv 2y ago
      > I don’t think Cloudflare workers, as deployed by Cloudflare, really tick that box either. They mostly do. You can map different Workers to different paths in your site. A Worker can only access the resources it is explicitly bound to. E.g. if you create a KV namespace for storage, a worker can only access that namespace if you configure it with a "binding" (a capability in an environment variable) pointing at the KV namespace. Workers on your account without the binding cannot access the KV namespace at all. Some more on the philosophy in this blog post: https://blog.cloudflare.com/workers-environment-live-object-bindings/ https://blog.cloudflare.com/workers-environment-live-object-... There are a couple of caveats that exist for legacy reasons, but that I'd like to fix, eventually: * The HTTP cache is zone-scoped. Two workers running on the same zone (domain name) can poison each others' cache via the Cache API. TBH I want to rip out the whole Cache API and replace it with something entirely different, it is a bit of a mess (partly the spec's fault, partly our implementation's fault). * Origin servers are also zone-scoped. All workers running on a zone are able to send requests directly to the zone's origin server (without going back through Cloudflare's security checks). We're working on introducing an "origin binding" instead, and creating a compat flag that forces `fetch()` to always go back to the "front door" even when fetching from the same zone. Note that if you want to safely run code from third parties that could be outright malicious, you can use Workers for Platforms: https://developers.cloudflare.com/cloudflare-for-platforms/workers-for-platforms/ https://developers.cloudflare.com/cloudflare-for-platforms/w... (I'm the tech lead of Cloudflare Workers.) (EDIT: lol wrote this without reading your username. Hi, Andy!)
      - amluto 2y ago
        The worker binding system seems pretty great. I'm thinking more about the configuration / deployment mechanism. In the old days, if I wanted to deploy a little script (on scripts.myuniversity.edu, for example), I would stick the file in an appropriate location (~username/cgi-bin, for example), and the scripts would appear (be routed, in modern parlance, but the route was entirely pre-determined) at a given URL, and they could access a certain set of paths (actually, anything that was configured appropriately via the AFS permission system). Notably, no interaction was needed between me and the actual administrator of scripts.myuniversity.edu, nor could my script do anything outside of what AFS let it do (and whatever the almost-certainly-leaky sandbox it ran in allowed by accident). But Cloudflare has a fancy web UI [0], and it is 100% unclear that there's even a place in the UI (or the command-line API) where something like "the user survey team gets to install workers that are accessible at www.site.com/surveys and those workers may be bound to resources that are set up by the sane team" would fit. And reading the "role" docs: https://developers.cloudflare.com/fundamentals/setup/manage-members/roles/ https://developers.cloudflare.com/fundamentals/setup/manage-... does not inspire confidence that it's even possible to pull this off right now. This kind of thing is a hard problem to solve. A nice textual config language like the worker binding system (as I understand it) or, say, the Tailscale ACL system, is nice in that a single person can see it, version it, change it, search-and-replace it, ask an LLM about it, etc. But it starts to get gnarly when the goal is to delegate partial authority in a clean way. Not that monstrosities like IAM or whatever Google calls their system are much better in that regard. [1] [0] Which I utterly and completely despise, but that's another story. Cloudflare, Apple, and Microsoft should all share some drinks and tell stories of how their nonsense control panels evolved over time and never quite got fixed. At least MS has somewhat of an excuse in that their control panels are really quite old compared to the others. [1] In the specific case of Google, which I have recently used and disliked, it's Really Really Fun to try to grant a fine-grained permission to, say, a service account. As far as I can tell, the docs for the command line are awful, and the UI kind-of-sort-of works but involves a step where you have to create a role and then wait, and wait, and wait, and wait, and maybe the UI actually notices that the role exists at some point. Thanks, Google. This is, of course, a nonstarter if one is delegating the ability to do something useful like create two resources and link them to each other without being able to see other resources. (Hi Kenton!)
pier25 2y ago
> is where SSGs fail miserably It's trivial to bundle and deploy some server-side code with a static site on Vercel, Cloudflare, Firebase, or Netlify. Usually you simply create a /functions directory wth your JS code and that's it.