This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-06-15
Channels
- # announcements (11)
- # aws (5)
- # babashka (69)
- # beginners (138)
- # calva (5)
- # cider (11)
- # cljsrn (3)
- # clojure (86)
- # clojure-europe (8)
- # clojure-italy (2)
- # clojure-nl (5)
- # clojure-norway (13)
- # clojure-uk (21)
- # clojurescript (13)
- # conjure (58)
- # core-typed (2)
- # data-science (2)
- # datomic (5)
- # degree9 (4)
- # emotion-cljs (4)
- # figwheel-main (8)
- # fulcro (29)
- # graalvm (70)
- # interop (2)
- # joker (1)
- # lein-figwheel (2)
- # leiningen (13)
- # liberator (4)
- # off-topic (21)
- # pedestal (2)
- # re-frame (10)
- # shadow-cljs (42)
- # spacemacs (29)
- # spire (1)
- # tools-deps (11)
- # vim (26)
- # xtdb (5)
@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.