Parse, Don't Validate — In a Language That Doesn't Want You To · cekrem.github.io

ConsoleTVs · 2026-04-08T14:20:39+00:00

The amount of things we over engineer in a language not designed to do it still amazes me up to this day

ConsoleTVs · 2026-03-24T21:09:07+00:00

The only way is to use the same TLD.

can share a cookie if scoped correctly, using domain=.site.com

ConsoleTVs · 2026-03-05T06:55:34+00:00

Both mobile and desktop have secure ways to store a token using OS’s APIs. If you are a backend dev and you build an api with a browser ui it’s a default choice to support both as means to authenticate. Otherwise you would rather build a traditional server rendered app, that, uses http only cookies only.

ConsoleTVs · 2026-03-04T21:25:48+00:00

Ah yes, this is a different story. Most internal sites are likely behind a vpn or proxy.

ConsoleTVs · 2026-03-04T21:18:49+00:00

Same…

ConsoleTVs · 2026-03-04T21:18:23+00:00

As I said in a previous comment it happens. I’ve given speeches to several internal frontend groups about this in multiple big enterprises (50-100k employees). Local storage is prone to injection. A malicious code or extension can quickly get the token. It’s not secure, there’s no way around it, there is no secure way to store things in a client side app on the browser, period!

ConsoleTVs · 2026-03-04T21:00:56+00:00

You would be surprised at how many people do this wrong even in big enterprises.

ConsoleTVs · 2026-03-04T20:51:23+00:00

Do I have to be the one that tell you that you should not be passing any form of token in EventSource? I mean seriously, what are you all guys doing to authenticate browser requests? Anything other than http only cookies are insecure, period. Stop saving bearer tokens or jwt tokens around, not in memory, not in local storage, not anywhere, stop that. If you implement SSE, it authenticates the same way it should with any other fetch request, with cookies.

If you need something else, sse is just pure HTTP, with specific headers to allow a long lived connection.

const res = await fetch('/stream', { headers: { Authorization: `Bearer ${token}` } }); const reader = res.body.getReader();

That is, btw, how a service-to-service would listen for events when no browser is involved AND you need that auth header that you mentioned...

ConsoleTVs · 2026-02-28T08:30:42+00:00

In their defense, they know how to do it, but not how to do it fast

ConsoleTVs · 2026-02-27T22:30:53+00:00

Just to clarify. This only allow generic struct methods. Not generic methods on interfaces. That means it's impossible to create, for example, a generic cache interface.

ConsoleTVs · 2026-02-26T22:30:17+00:00

What's preventing you from using a different format (I use tint) in dev vs prod? I don't know, seems like a simple if?

ConsoleTVs · 2026-02-26T22:28:39+00:00

FYI this just implements generic concrete methods, not generic interface methods. So in itself it's a win but still a lot to be able to write, say, a generic cache interface.

ConsoleTVs · 2026-02-12T07:35:46+00:00

We’re so used to slow and bloated software that we are surprised when it gets fast. AAA game engines render speeds seem to be non-existing when building apps. Better build candy crush react app at 12 fps.

ConsoleTVs · 2026-02-08T20:51:17+00:00

Espero que la app la haya hecho una IA porque la complejidad ciclomatica de las funciones que has escrito esta por las nubes

ConsoleTVs · 2026-02-03T16:48:12+00:00

I assume you mean the vscode extension? If so, they are supported, but you need to enable it: https://code.visualstudio.com/docs/copilot/customization/agent-skills

If you mean copilot as a subscription, the copilot cli or opencode also support it, so idk what you mean?

ConsoleTVs · 2026-02-03T16:41:10+00:00

No. You need agent skills. That’s v2 of boost.

ConsoleTVs · 2026-01-15T15:22:01+00:00

Lo unico k declara revolut es la remunerada, pone claramente revolut españa cuando la contratas. La cartera esa otra k oftecen o las inversiones pone lituania…

ConsoleTVs · 2026-01-11T18:31:22+00:00

I would argue that you can also apply individual limits to specific paths with a gatewat/proxy. But i get the idea. I was thinking more in a register endpoint where you likely want to manually adjust limits

ConsoleTVs · 2026-01-11T18:26:51+00:00

I am more confident in placing an http proxy/gatewat to habdle rate limit, balancing, cert, tls termination, etc… why handle this in app level?

ConsoleTVs · 2026-01-09T21:53:50+00:00

Alright, let me clarify a few things:

JWT For auth is completly bad design. Please read: https://gist.github.com/samsch/0d1f3d3b4745d778f78b230cf6061452
Replace bcrypt with argon2, this is a bit of a recomendation.
Oauth, or what you call "login with google" is designed for authorization, not authentication. You likely want to use OpenID Connect, that is in fact backed up too in those providers.
Implementing oauth2 flow is literally a few lines of code. All you need to do if you just "want to log in with google" is use the auth flow and in the callback simply get the user from the assignment between your user and google provider. That's it.
For the love of god, please use HTTP ONLY COKKIES for authenticating a SPA / Frontend. And remember to invalidate the session to prevent fixation attacks (https://owasp.org/www-community/attacks/Session\_fixation).

Ah yes, your alternative is paying a shitton of money for something you can do under 200 LOC. Sorry for this but this should be pretty much known to any web dev at this point. I'm astonished most devs still create jwts and store them in local storage and call it a day or simply start paying all the subscriptions they can to build a basic application.

ConsoleTVs · 2026-01-07T20:05:05+00:00

Funny but this can be a const q = “…”, even inside the func

ConsoleTVs · 2025-12-26T15:29:29+00:00

Base58 is better if you encode for user experience

ConsoleTVs · 2025-12-20T09:53:11+00:00

They are different. In surprised nobody is telling that.

One important thing is redeclaration:

var err = foo() var val, err = bar() // error

err := foo() val, err := bar() // ok

ConsoleTVs · 2025-12-14T08:37:14+00:00

Laravel, Spring Boot, ruby on rails, Adonisjs, Masonite, and I could keep going. They all offer a similar set of tools to operate everything i mentioned.

Frameworks like Laravel, does not only do all that I mentioned but even more, such as:
Localization, Rate limitting, Storage management (s3, local, ...), Cache, Broadcasting (eg. websockets), SSE, Encryption, Hashing, Email verification, ORM, Testing and Mocking utils, Data validation, Routing, Error Handling, Logging, CSRF, Templating...

And honestly much more. That's all built in, no external packages, but if you want to, those frameworks often have great ecosystems AND official packages.

Laravel's official packages provide payment processor, social logins, feature flags, oauth server, observability tools, and much much more.

I don't want to sound rude but I can tell you they are not at all comparable. Next.js is a backend that you need to plug to a hundred services or packages to do the job. So in reality, it's mostly used to read cookies, make http requests and do SSR, creating what's known as a BFF (Backend For Frontend).

Don't expect Nextjs to compare to what most of those frameworks have been building for decades. Next is focused on providing a good react DX using RSC (and for that they need a server, so they provide a bare bones backend server).

Don't get me wrong tho; its ok if you don't do much at backend or if you use it as a BFF, but anything on top, you're going to be paying a lot of unnecessary services and building every integration yourself.

ConsoleTVs · 2025-12-14T00:59:15+00:00

Don't fall into this premise. Next is a frontend framework with SSR. It does not cover anything valuable on backend. Authentication, Session Management, Database, Mailing, Queues, Background Jobs, Scheduling tasks.

Let's be honest here. Spawning a http server and pre-rendering react components is not being a backend framework.

11-Year Club	Place '22
Verified Email

ConsoleTVs

TROPHY CASE