francislavoie

Because that's not automated, it's a manual command and uses caddyserver.com resources (relatively low powered cloud VMs) with no uptime guarantees. It _should not_ be used in automation scenarios, only for quick manual personal use scenarios.

No, you have to build Caddy with plugins. We provide xcaddy to make it easy. Sign up for notifications on github for releases, and just write yourself a tiny bash script to build the binary with xcaddy, and restart the service. You could potentially do a thing where you hook into apt to trigger your script after Caddy's deb package version changes, idk. But it's up to you to handle.

Actually, you can set the permissions for log files now. See https://caddyserver.com/docs/caddyfile/directives/log#file

A very in-depth article on the topic: https://adam-p.ca/blog/2022/03/x-forwarded-for/

I implemented those recommendations in Caddy to enable a "trusted proxies" system which informs the proxy, logging, request matching etc to safely use the client IP taken from proxy headers.

Typically a boolean issue like this is a cause for escalation if you use it in combination with some auth handler, like "if has session cookie then serve protected files" and since the condition always passes then it could bypass auth. For example.

See the README, this results in only changed layers being sent instead of _everything_ which can save a lot of time.

If you read the README, you'll see that replacing the "save | upload | load" workflow is the whole point of this, to drastically reduce the amount of data to upload by only sending new layers instead of everything, and you can use this inside your ansible setup to speed it up.

No, it's because TS adds information. Pure JS doesn't know what variable "foo" is (is it a potato? is it an array? can it be null?), but if you assign it a type like Map<string> then now it knows what kind of data it can hold, what you can do with it, etc. Now you know you can do foo.get() and your IDE will tell you as soon as you've typed `foo.`, but if you used pure JS, lol how is it supposed to have any idea what methods exist?

It lets you chain data from one task to another based on knowing what possible and available given the types. That information just straight up doesn't exist in JS code, unless you write JSDoc comments all over with that information as static analysis hints. But why not just embed that information in the language itself instead of tacking it at the top of every chunk of code, much more elegant and allows way more power.

Even if you used JSDoc, you still need that static analysis tool to exist, and hey, that's exactly what TypeScript is. It's both a language definition for augmenting JS with types, but it's also a transpiler which takes TS code and spits out JS code, _and_ it will tell you if there's problems with the types. But since that engine exists, you can plug it into LSP and so on.

Remember, LSP exists _because_ of TypeScript. VSCode exists because of TypeScript. The team that works on VSCode and came up with LSP did it because they wanted TypeScript to integrate with VSCode and they had the foresight to build something generalized that could be used for ANY language.

He's involved with https://grayjay.app/ btw. Of all people to criticize for using YouTube as a platform, he's the last.

Very cool, but CLI tools with a JVM language? :( I'd be much quicker to try this out with a static binary.

There is one, there's a toggle for it on the right

The spec is fundamentally flawed. The fixed spec would be a different spec, i.e. something like PASETO.

It's not about the curves being cracked. https://auth0.com/blog/critical-vulnerability-in-json-web-en...

Yes it allows Ed25519, but it doesn't disallow other curves. That's the whole point. If you allow primitives that have potential issues, it's risky to use.

The point is that the JWT spec leaves it open to the implementer which primitives to use, which invites bad implementations to be insecure. PASETO requires a small subset of known secure primitives, preventing that problem altogether. It's not "just nonsense".

Here's a list of "alg: none" JWT vulns. Every one of these would've been avoided had the standard been something like PASETO which didn't allow that. https://github.com/zofrex/howmanydayssinceajwtalgnonevuln/bl...

You say "I am not going to watch the talk" and then you continue to argue in bad faith. Please walk away if you're not going to engage honestly.

I don't like it much, using JSON as the transport has some problems if encoded in a URL as required by many auth flows. Paseto encodes the whole version+payload+signature to make it easier to transport. Of course you could just base64 encode the whole Coze JSON, but that isn't part of the spec, which means the spec is weak.

As others have said, JWT, in practice, is effectively forced by the extensions/OIDC, I was just being short.

It shouldn't be about demand. It's about solving the danger of these poorly designed APIs to improve overall web security.

Watch the talk at the bottom of the page. JWT/JOSE are chock full of dangerous footguns that aren't just theoretical, they have repeatedly been shown to be poorly designed and too risky to implement correctly as written. Using fewer, known secure cryptographic primitives as part of the spec ensures it's impossible to get the security wrong, can't be misused.

Paseto is better https://paseto.io/, but unfortunately OAuth forces the usage of JWT.

But isn't using LLM for that really expensive? Seems wasteful.

I use xplorer2, works pretty well. I don't do anything fancy with it, but I like the two-panel layout and the "scrap" panel for quick links

Production ready, 10 year old project. It's not new, it's older than Kubernetes even.

Logs are just written out to stderr by default, and when you use systemd it ingests it automatically. If you run it with alpine, it's up to you to wire that up.

You can shorten it:

    @oldPath path_regexp ^/old/([\w-]+)
    rewrite @oldPath /new/{re.oldPath.1}.php

Having matching and handling be separate steps are a huge benefit to composability of config, you can have pluggable matchers and handlers.

Re you issue with netdata, ask on the forums for help.

Yeah, tech debt sucks a lot.

Caddy v0/1 was just built up naturally bit by bit, never had a proper design/structure around its config. Caddy v2 was a complete rewrite from the ground up, including thinking a lot more about config design, so it had to be a breaking change for the project's future to thrive.

Yes, it has events on cert issuance/renewal you can hook into with Go plugins (which can trigger your python script). But generally you want all Caddy instances to share storage via storage modules (e.g. Redis or Consul or a DB, or synced filesystem) and Caddy manages locks through the storage so they don't step on eachother's toes.

Yes, stable and production ready

Hahaha, this is basically some clever clickbait. Tl;dr Paul is retiring and Jack is taking sole ownership of Fathom. Nothing really changes.

I feel like I remember StackOverflow (and related sites) having OpenID login as an option, but I don't see it anymore. I figure they removed it due to low popularity.