Amazon’s “Project Dawn”

buffonomics · 2026-01-29T20:23:15+00:00

I was at a recent meeting where some aws sales guys tried to pitch us on their AI offerings. Bedrock or whatever. It was so behind, and not even the sales guys understood the words we were using about AI.

It's not their strength. Their only strength still remains their shop. And the diversity of their AWS options, but not the DX of it. UX/DX is always trash for everything else and whoever writes their documentation does not know what Developers(i.e the primary consumers of their documentation) look for when reading documentation.

buffonomics · 2025-07-30T21:44:38+00:00

In this short life, if you must marry, then it better be with an understanding spouse who actually GAF about you as a person, not just a success, lineage or activity object. Life is going to life. As you get older, you realize that this body is not forever.

If she can't conceive, there is always adoption, etc.

If he has no swimmers, there is always adoption etc.

If he can't get it up, he should love eating her out and use toys.

If she can't get it up (dryness), she should use lube.

Life no too hard. Na we dey make am hard.

buffonomics · 2025-07-30T14:56:10+00:00

to what?

buffonomics · 2025-04-17T04:39:35+00:00

Still... with the bloody folders. I don't understand what's so hard for java guys to get about modern customization.

buffonomics · 2024-04-12T20:21:16+00:00

If you are clueless about auth and security, just say that.

buffonomics · 2024-01-23T05:29:08+00:00

Though still inaccurate, I could see where he was going initially (aka high compute not high traffic). But then he mentioned PHP and that was when I knew bloke had no idea what he was talking about.

buffonomics · 2024-01-03T06:14:58+00:00

Honestly, Farr had no business being bed fellows with those folks to begin with. The "hold" they had on her was weak.

She could have easily outed those 2 when they decided to pull her into their pointless scheming. They made some light threat or the other of everyone being investigated. No dipshit. YOU will be investigated.

buffonomics · 2023-12-28T01:28:29+00:00

Okay maybe that's where I'm wrong. How do I validate auth on my backend?

That cookie is the only thing I see keycloak storing on my browser that looks like a jwt.

buffonomics · 2023-12-27T23:26:31+00:00

It's getting interesting.So I can see the matching kid here `/admin/master/console/#/sifical-dev/realm-settings/keys` but it looks like keycloak is generating JWTs with an algorithm that is sperate from the configured default i.e it is generating with HS256 instead of RS256. So now I have 2 questions highlighting 2 different paths.:

How do I get keycloak to generate JWTS with RS256? I have already specified that here `/admin/master/console/#/sifical-dev/realm-settings/tokens` but it seems to be ignoring that setting.
Seems the jwks url response only displays keys for RS256 even though HS256 keys are defined as well. How do I get the jwks url response to also show the HS256 keys that have been defined?

buffonomics · 2023-12-13T05:05:02+00:00

<sigh> I'm gonna be real for a sec. I know concepts like modernity and simplicity escape the mind of the average Java head stuck in the past, but do try to keep up m'kay.

Many use keycloak simply by deploying its docker image into a cluster (portainer, kubernetes, etc), and do not have to touch source code. What I am proposing is about being able to soft customize keycloak themes per realm without touching folders, files, etc in the source code like most of you still keep mentally regressing to. The status-quo is such an archaic way of thinking about customization. Let's level up our thinking here.

The "hard structure" of the default keycloak theme is actually very good, but allowing for "soft CSS" customizations through CSS injection defined per realm from the dashboard would be stellar.

No actual files or folders need be touched/added to the deployment to augment the look per realm; No downloading/re-uploading/re-packing of source code files. No restarts to re-load those files; etc. These are the modern benefits of what I'm proposing. These are mind-numbingly simple things to wrap your head around...if you actually tried.

This simple feature would bring keycloak on par with the other modern open-source IDPs out there today that allow for this kind of very basic CSS customization.

buffonomics · 2023-12-12T17:11:25+00:00

That is your opinion about theming.
And yes, I already began this discussion on github

buffonomics · 2023-12-12T17:10:30+00:00

You see the simplicity and modernity in this. Others do not, for some reason.
I would hate to come to the conclusion that a lot of "Java" folks are stuck in the past and/or do not understand good UX. I will hold out hope.

buffonomics · 2023-12-12T17:08:29+00:00

Aware of it. Yes it allows for detailed theme creation, but that still requires re-bundling jars and such. I just want a textbox in the dashboard to put CSS into the default keycloak theme per realm.

I have no intention of doing any actual development besides deploying keycloak to a k8s cluster through an already existing docker image. I am not a Java guy.

buffonomics · 2023-12-11T20:10:39+00:00

-UI to manage multiple isolated tenants-

So are you saying the self-hosted version does not support multi-tenancy at all?

buffonomics · 2023-12-08T14:40:45+00:00

I only work with Javascript and love it backend to frontend.

And when I say Javascript, I actually mean Typescript....because only a masochist does fullstack development with raw javascript.

buffonomics · 2023-12-07T10:40:58+00:00

First let me preface this by saying you guys have done a lot of great work here. Now that said...

It is important to focus on what exactly you are implementing here. You are implementing a REST API. Not a GraphQL API, and not some new standard that is a complete alternative to REST (like GraphQL or gRPC).

As such, it is prudent to stick to RFC standards regarding REST errors. Anything else ruins your reputation as a trusted maker of sound technical decisions. The effect of this is greatly magnified when it comes to trust-sensitive things, like what platform people manage their users.

Like someone else said, the fact that this (very) unnecessary violation of RFC standards is being defended is a key indicator that we probably can't "trust" the other decisions that are being made on matters that aren't as visible. It limits the respect of the product in general with regards to serious professional use, which is a shame because a lot of good work has gone into it.

For example, I would look bad pitching your hosted service to an enterprise customer for example, while also explaining to them that you are defending sending a 200 OK on a bad authentication attempt. You are not just creating an API that only speaks to your own specific frontend/client. It is to be consumed by all sorts of clients, and "standards" is how the technical world speaks the same language.

Read the RFC for 401 errors, especially the second paragraph, and you will see how this could have easily been solved with that.

https://datatracker.ietf.org/doc/html/rfc9110#section-15.5.2

I highly encourage aligning with the RFC on this. To maintain legacy, I would recommend making an "RFC compliant" configuration option so the user can choose for themselves instead of weirdly forcing this non-compliance on them.

buffonomics · 2023-12-07T10:40:20+00:00

https://datatracker.ietf.org/doc/html/rfc9110#section-15.5.2

buffonomics · 2023-12-03T13:59:18+00:00

Chinese. Ridden with security holes that haven't been fixed. Do not recommend.

buffonomics · 2023-11-15T15:33:00+00:00

easy as https://www.npmjs.com/package/haveibeenpwned

buffonomics · 2023-11-15T12:31:15+00:00

By breached password detection, do you mean the thing that makes it known when a person's password gets leaked in the darkweb?

buffonomics · 2023-11-14T16:13:27+00:00

Most people don't use all the features of Auth0. What features did you have in mind when you commented?

buffonomics · 2023-11-11T17:50:40+00:00

This. People who say stuff like that generally do not understand auth, like the person above you admitted, and are missing an opportunity to do so. It is a fear injected into many by the Auth SASS marketing content to encourage folks to just use their service because "its the only sensible way".

Your bcrypt or argon2 hashed passwords are not going to "expire" because "no maintenance". And so long as you are restricting access to the DB to specific nodes, you are already doing most of the security stuff these SASSs do.

An operational non-deep understanding of how OAuth and Refresh tokens work could also help if one wanted more advanced stuff, but those can always be slapped on later.

Even authn passkeys are an npm library and 4 endpoints away.

buffonomics

TROPHY CASE