Do we care that the bug here was a horizontal scrollbar showing and the fix after all this insane tool writing was to add a very obvious overflow-x: hidden to the element?
We dont mind because its so fast a writing these tools and tricks but step back and if a human tool took this path i would seriously question thief gras of fundamentals.
And how is that even a fix? The problem is that a seemingly empty textarea has overflow in the first place. Adding `overflow: hidden` just sweeps the issue under the rug.
I did some tiny digging because I remembered that there is a way to report individual messages in a structured machine readable way to abuse@ for these things --- i suspect that this is technically supported by gmail (if not given a lot of signal weight)
Shows you how to use googles thing if you are a sender to know if @gmail folks are reporting you. It doesnt address what to do if someone's @gmail is doing this to you (a workspace custom domain yes)... @gmail are rate-limited to a few 1000s per day per gmail address but this is still a lot obviously
Good memories of the open source world. I couldn't find my commits in either repo and i'm afraid i might have been shy to upstream them and just did them in a fork. it was tiny, There was some issue in some less number formatting variation involving currencies in multiple locales. we needed xlsx for its ability to do some nice formatting etc but i really wanted to have a need for things like generating charts, embedding scripts etc just for the sheer nerdiness
I wonder, can we not turn all threads into a "when will AI do this creative thing better than humans".
Humans need basic income (or at least resources) and to have culturally valuable work to do. Art and craft esp as a form of human expression seems like we should ASSUME that humans want to do this, that we as a society value the human energy that goes into it.
Yes, humans want to make art. But most humans would also want their art to be seen, appreciated at minimum. Would be nice if they can make a living out of it.
I am not trying to turn all threads into AI debate, but AI threat to art is a legit concern. If AI mass produces art at comparable quality level to humans, it would be near impossible for humans to compete for other humans' attention. If nobody sees my art, would I still make art? Maybe some humans will, because creating art makes them happy and they don't care if anyone sees their art or not. But many humans will give up
I would love to see alternatives of educational code that implements these things in a "compliant" way.
Security does not come from Compliance (sometimes they are at odds) but as someone who is not an academically trained security professional but who has read NIST* in detail, implements such code and has passed a number of code reviews from security professionals. And who has been asked to do things like STRIDE risk assessment on products I write code for I do appreciate the references and links along side actual code of any kind.
Now to be fair, I have not yet looked at any of the code here, it's commit history or its level of AI-induced fantasy confidence in the validity of the specific solutions. That could be good or bad but the intent of this is really on point for me.
- the db select runs before the password has so you can detect if the account exists with timing attacks
- there is no enforced minimum nor maximum length on the stored secret (e..g para 5.1.1.1 and 5.1.1.2 recommend length range of 8 to 64 unicode printable chars normalized to some form i forget)
- there is no enforced min max length on the account identifier (in this case email) and no normalization
At least not in the code i saw. so there is still a lot of basics/low hanging fruit from NIST recommendations at least you would find in any production grade auth framework missing
On the login... when failing either via user lookup, or password mismatch, I'll usually put a random 500-2500ms (or more) delay before logging and sending the response to handle timing attacks.
You can try a db transaction against a lock table for IP and Username as part of multi-request mitigation during any given request. CF offers Durable objects that can be used for this purpose. Return "too many requests" error if a request is sent before another is finished... this will slow things down.
On the minimum passphrase, there are some libraries you can use to get the printable character length... note: you should always normalize (NFC or NFKC) before doing any hashing or validation.
function getPrintableLength(str) {
// Use Intl.Segmenter for accurate, user-perceived character count
const segmenter = new Intl.Segmenter("en-US", { granularity: "grapheme" });
return [...segmenter.segment(str)].length;
}
Personally, I usually just transparently set a max of 1024 bytes, I don't display a hint for it at runtime, only an error on submit though... if someone exceeds that, they deserve the generic error I return.
Email validation can be a bit rough, depending on how permissive or restricting you want to be. If you're willing to wait for a DNS/MX check on the domain, that's a good place to start. You most likely don't want less than 5 characters or more than 100.
Pretty sure all those are covered, upon more careful review. PRs open!
Edit: The create account I hadn't thought of for the email enum. Thanks!
Edit 2: Fixed up two schema issues identified and the last mitigated already via call: await passwords.rejectPasswordWithConstantTime(validatedData.password)
Marginally better for sure but in this case the path would also have been "leaked" to the sentry instance owned by developers of the the NAS device phoning home. This can happen in zillions of ways and is a good reason to use relatively opaque urls in generally and not "friendly ids" and generally being careful abou putting secrets in URLs.
I worked at a company where the security team disliked wildcard certificates because it exposed us to the risk of someone, somehow, hosting something malicious on a subdomain.
I feel the same, 72 million monthly page views is about 8 pages per second even if in a single timezone (72e6 / 8h * 30d * 3600h/s) - even with today's heavy weight pages we are talking under well under 1000 req/s. Assuming they are not super image/asset heavy i would expect this to comfortably be served by a couple of reasonable old school ngnix servers[1]. If each page was a full megabyte of uncached content we are < 10Gbits/sec. Probably under 1
The build logic to decide which things to rebuild of course is probably the interesting bits but we dont need all these services... </grey-beard-rant>
edit: to be less ranty they are more or less building static sites out of their Next.js codebase but on-demand updated etc which is indeed interesting but none of this needs cloudflare/hyerscaler tech
Not sure how many customers/sites they have. Perhaps they don't want to spend CPU regenerating all sites on every deployment? They do describe a content-driven pre-warmer but I'm still unclear why this couldn't be a content-driven static site generator running on some build machine
The thing is you can still stick a CDN in front of your old school servers and just use a 'stale-while-revalidate' header to get exactly the effect described here.
We do this, but if you're redeploying fast enough thre's a change that a user loads a cached old page (or performs a client-side navigation to an old page) and makes a requests for a URL that's no longer served by the origin nor is cached by the CDN.
Yeah, as a salty greybeard i tried to tell our FE tech-lead to just render the proper HTTP Cache-Control headers in the Next.js site we recently built. He tried and then linked me to https://nextjs.org/docs/app/guides/caching and various version of their docs on when you can and cannot set Cache-Control headers (e.g. https://nextjs.org/docs/app/api-reference/config/next-config...) and I got several hours of head-ache before calling it a problem for another day. That site is not high traffic enough to care but this is not the first time that i've gotten the "not the Next.js way" talk and was not happy.
I obviously can be done but clearly is not the intended solution which really bothers me
Well, part of the Vercel game is to lock you in to their platform and extract $$$, but as I recall you can spec out headers in NextJS config?. And possibly on CloudFlare itself via cache rules?
I am self hosting using Docker. Next.js config to change header didn't work for me. I had cache rules in Cloudflare, but Next.js header for page (no-cache) doesn't allow Cloudflare to apply stale-while-revalidate.
Now that I have proper header added by HAProxy, Cloudflare cache rules for stale-while-revalidate works.
If anyone can reach Cloudflare. Please let us forcefully use stale-while-revalidate even when upstream server tells otherwise.
Stale-while-revalidate as implemented in the post was easier for us and required less resources than migrating from our dynamic site architecture to static. Ideally we would have migrated to fully static sites, but the engineering effort required to make that happen wasn't in scope.
Does it? I watched this video and the explanation of how they (mostly Bill in Vermont) did it had barely enough room for the song data. I think the line graphics might have been some good story telling
It was likely just a proof of concept run in the emulator. I'd guess it would be wildly impractical to get even that version of doom on real paper tape
We dont mind because its so fast a writing these tools and tricks but step back and if a human tool took this path i would seriously question thief gras of fundamentals.
reply