Clojurians Log v2

@dominicm apparently some services will reject xhr calls if they come from insecure pages, for example AWSElasticLoadBalancer endpoints that are secured with ssl will reject requests

but in general, it seems that most developers use https locally when they actually don’t need to

That seems, hmm. How do they even know. Unless it's a layer of security they've manually added. I've never heard of that in OWASP advice or anything.

Personally I'd solve this by using a proxy. Rather than messing with trust. I seem to recall using a public one many years ago.

Let's encrypt article is great on this: > Fortunately, modern browsers consider http://127.0.0.1:8000/ to be a “potentially trustworthy” URL because it refers to a loopback address. Traffic sent to 127.0.0.1 is guaranteed not to leave your machine, and so is considered automatically secure against network interception. That means if your web app is HTTPS, and you offer a native app web service on 127.0.0.1, the two can happily communicate via XHR. Unfortunately, localhost doesn't yet get the same treatment. Also, WebSockets don't get this treatment for either name.

Looks like the ip gets a free pass.

(Doesn't really help here, totally unrelated)

that’s definitely interesting about 127.0.0.1