OAuth with Cloudflare workers on a statically generated site
abyteofcoding.com
abyteofcoding.com
> Connections from CloudFlare’s reverse proxy are dropped. Do not help one private company expand its control over all internet traffic.
We really to not let the internet become so centralized.
If it wasn't for them most of my sites won't be accessible for more than half of the internet.
Also maybe there is a reasons for most of the internet not to care about ipv6 or current implementation, but that is another different big debate
https://github.com/makeworld-the-better-one/amfora/issues/19...
Yeah, it's usually used in the context of the unilateral issuing of decrees.
SSL is a solved problem since let's encrypt, cloudflare actually decreases performance (by adding an hop when serving dynamic content). For most websites, DDoS attacks are a non-issue.
It just feels like, unnecessary technology?
Their CAPTCHAs are annoying, though, and I wouldn't miss them an ounce if they went away.
I mostly get crosswalks and traffic lights. I occasionally get mountains, motorcycles, and bicycles.
As an end user, I agree they are annoying. These two things may or may not help (hCaptcha is the engine used by Cloudflare*):
1) You can set an accessibility cookie that should be good for a while: https://www.hcaptcha.com/accessibility
2) There is also the Privacy Pass beta, which lets you redeem CAPTCHA solves for "tokens" that can be used for later CAPTCHAs https://www.hcaptcha.com/privacy-pass
But yeah, hCaptcha is really annoying, especially compared to the auto-solve of reCAPTCHA when you're logged in to a Google account.
* Cloudflare switched to hCaptcha in 2020: https://blog.cloudflare.com/moving-from-recaptcha-to-hcaptch...
The free tier is great for serving low-value (that is, not enough value that you need a SLA from your vendor) static sites for pennies a month.
Having so much in one place is really nice for small shops.
But they 100% are on track to be the next Big Bad of the tech world, and they're heading that way very much on purpose. Their entire strategy for how they've positioned themselves is, transparently, bent toward making themselves the Web's #1 middle-man.
Only if you remember to update your cert chains, and your web servers have to keep up with TLS etc. updates too
> cloudflare actually decreases performance (by adding an hop when serving dynamic content).
If your dynamic content doesn't require true real-time updates (like a forum or chat or something), but can be limited to once a minute updates or similar (like a reddit-style front page), caching and global CDNs can still drastically speed that up for users who aren't near your data center.
And that's just their static cache offering. If you build your site around their edge infrastructure (workers, workers KV, durable objects), you can entirely remove the last hop by handling client requests and sharing state across the CDN itself. Two of their demos show IRC-like chat and Doom (the game) running entirely on the edge: https://github.com/cloudflare/workers-chat-demo https://blog.cloudflare.com/doom-multiplayer-workers/
They also do other performance boosts, like auto-optimizing images, converting to webp, minifying stylesheets & scripts, dynamic loading, http QUIC, etc. And they offer a edge streaming solution for video (although Vimeo is probably much cheaper for most use cases).
> For most websites, DDoS attacks are a non-issue.
It can also help with things like Google Analytics bot spam, drive-by vulnerability scans against certain web servers or Wordpress, etc. It's not just a IP blacklist but does some degree of traffic analysis.
And all of that is available for free or cheap. It's very difficult to do all that yourself as a small-biz or solo web dev, even if you had full time dev-ops.
As for "the internet shouldn't be controlled by a single entity", sure, but it's always been a corporate network. Choose your nemesis: Cloudflare, Google, Amazon, Facebook, Verisign/network solutions (in the old days)... there's never been a truly free internet. At least Cloudflare is doing a darned good job of stewarding the internet.
Page load time tends to be dominated by static content.
But even for dynamic content, this isn't necessarily true. Setting up a TLS connection requires multiple network round trips. When using an edge network, those round trips only need to go to the nearest PoP rather than all the way to the server. If the PoP already has connections open to your server (which is probably the case if you have consistent traffic) then the network round trips back to your origin server are avoided, and your dynamic content ends up being served faster.
Additionally, Cloudflare's Argo Smart Routing is often able to route packets across the internet faster than than default network routing, which speeds up the communications between Cloudflare and your origin server.
So it turns out "adding a hop" does not necessarily decrease performance.
(Disclosure: I work for Cloudflare.)
QUIC significantly reduces the cost of the TLS handshake, I think now it's only a single additional packet-exchange: https://blog.cloudflare.com/the-road-to-quic/
And you'd be surprised how much bot traffic that most sites get that you may or may not want to allow. Not every user feels comfortable setting up Let's Encrypt (though I agree it's awesome) or even has sufficient privileges to do so.
Compared to other services like AWS Cloudfront/WAF/etc., Fastly, Akamai, etc. IMO their offerings are quite powerful and economical.
I added the ability to do captcha submissions from my site and send alerts to slack myself. I opted not to go the worker route as I found the language a bit hard to use and I could get the same effect with just javascript pulling other dynamic javascript hosted elsewhere.
(You can see an example with the submission form at the bottom of this page: https://mrsteinberg.com/how-to-kill-your-startup-co-founder-...)
I'm confused by this since the default language for Workers is javascript. Do you mean their api is confusing?
EDIT: guessing by the delay in response, someone just told all of HN they exposed their API key?
Well, when you think of Workers as Nginx, Squid, Memcached as-a-service, the possibilities simply present themselves. It is absolutely appalling that AWS has Lambda@Edge (relatively, uber expensive) and CloudFront Functions (uber lame) positioned against Workers.
Full-stack week starting today, and it is very likely that Cloudflare launch Container support for Workers: https://blog.cloudflare.com/full-stack-week-2021/
Let's see if Adam Selipsky announces anything compelling at re:invent aloof from their Lightsail initiatives which are priced similar to Cloudflare (and cheap only if you're running toy products atop, but not any SaaS-like services).
... one might think implementing OAuth sign up is relatively trivial; after all, you just need to write a fetch request that redirects the user to the OAuth page, then another request that sends their email to the newsletter service of choice to sign them up. Well, the issue is that in order to do the second step of that process, one needs to hit an API endpoint that requires authentication (an API key). That is essentially a password and not something you want to expose on the front end and give everyone access to.
This article Auth0 does a good job of explaining PKCE: https://auth0.com/docs/authorization/flows/authorization-cod...
OAuth uses a client key and/or a client secret, for the application that is requesting access on behalf of the client.
While non-human client-credentials can be used in-conjunction with a human-user's credentials it's largely unnecessary as an unauthorized client wouldn't be able to authenticate with a human-user because the redirect_uri sent from the client would be rejected automatically (and if that worked, there's always 'aud' audience filtering too), so the human-user wouldn't even be prompted to authenticate, they'd get an error message.
The title of the article says OAuth, and hence assumed that you wanted an authenticated client to be able to make the call to the backend for subscribing.
This is what is happening, except instead of a backend endpoint hosted on my own VPS, I'm using a Cloudflare worker.
"The title of the article says OAuth, and hence assumed that you wanted an authenticated client to be able to make the call to the backend for subscribing."
An authenticated client is necessary in order to retrieve the email of the client.
The conflating part here is that using the callback as a mechanism to imply subscription.
This works for your situation.
However, if you need to start making multiple backend calls, then, you will likely need to separate the authentication part from the subscription part.
Generally, OAuth implies that the requirement is to get authenticated by a provider and making multiple subsequent calls to some backend. Additionally, the backend will verify the authenticity of the short-lived token before allowing the operation to proceed.
Conventional web-applications let the application server store per-user secrets (e.g. access_tokens). If the application server needs to be stateless then secrets are packed into a web-browser cookie with the "httponly" and "secure" attributes which prevents any and all client-scripts from accessing them. Of course browser cookies are not the same thing as a true Bearer Token, so this means that when using an SPA the SPA cannot make its own HTTP requests to other RPs, it needs to use some non-local secret-storing-proxy to make the request for it... which starts to make a mockery of how microservices should operate.
Code Flow with PKCE does not replace the Implicit flow. Also, the Auth0 article you linked to is not a "good job". On the contrary, that article talks about using client-secrets - which you *must never have* in a JS-only/SPA/static client.
The only real solution would be some kind of opaque OIDC client built-in to a browser that handles secrets-storage on-behalf of JS applications (such that JS code never gets to see or handle any secrets, including the auth code and access_token, but the OIDC identity_token should be exposed, of course). I'm surprised Google and Mozilla haven't done this already...
As far as I can tell, Cloudflare Access doesn't allow you to run arbitrary code in an environment that isn't exposed to the user, which is kind of the whole purpose of this setup. The sole purpose of the OAuth part of this operation is so that the user doesn't have to type in their email. Session persistence/selective access isn't relevant here, and that appears to be the only thing the Cloudflare Access really offers.
tl;dr: Orchestrating many cloudflare workers at scale has not been a great experience.
I didn't make a point of vendor lock-in because migrating this process flow to a self-hosted HTTP server would take about 5 minutes. On top of that, this flow is going to be very similar for any vendor offering javascript functions.
Perhaps it is my fault for not including a section discussing this, but I assumed that the audience for this would primarily be people understand basic javascript and could deduce the portability of the code by looking at it.
There's also Deno, which is very similar in technology to Workers [1].
Others are building "Workers" atop WebAssembly, and things are looking up on that front as well [2][3].
See also: https://github.com/debarshibasak/awesome-paas
[0] https://github.com/cloudflare/miniflare
This isn't even a technical accomplishment in any way, it's just slapping together a few managed services together to sign up someone for a newsletter. I cannot imagine being the one to maintain a signup flow like this, it certainly looks unnecessarily painful from here.
A big motivator for this was definitely just to try out Cloudflare workers and see how they are. I've set up countless servers for APIs. In terms of time, I'd say Cloudflare workers is a bit faster when you get over the initial learning curve. Obviously you could write a deploy script for a server and have it set up everything automatically, and I have done that in the past, but sometimes it's fun to try new things right?
I never intended for this to come across as a technological accomplishment. I even end the article with "That’s pretty much it. It’s fairly simple with no real catches". I'm merely presenting what I thought would be useful information for some people. Personally I think maintaining a server is more work than maintaining this, but to each their own.
In that context, setting up a VPS would now mean that you have to be responsible for a new pet, including security updates and monitoring. You would also have to change your deployment tooling / workflow to something quite different (pushing and restarting a running service, rather than just running aws s3 sync ...)
Of course I don't think I would take this approach if I already had a backend service hosting a site, but I certainly would experiment with it if I were in your situation.