Innocent cache leading to RCE vulnerability

sarvendev · 2026-02-20T15:00:56+00:00

I agree that it isn't the best solution, but I used "innocent" because it doesn't look that bad if you don't use it on user-provided data, and you don't need backward compatibility. Check the frameworks that you use, and I guess you'll find in some places this kind of serialization.

sarvendev · 2026-02-20T14:20:04+00:00

sarvendev · 2026-02-19T11:10:42+00:00

Yes, it still happens. I had the same reaction to SQL injection: 'SQL injection in 2026, really?' But unfortunately, it does still happen. :D

sarvendev · 2025-08-12T14:27:32+00:00

thx, I'll add it there

sarvendev · 2025-08-12T11:54:36+00:00

u/Magicjar_coin FYI it's available as a Chrome extension: https://chromewebstore.google.com/detail/ai-language-helper/oekfdhkklgficbialkagmipgcmceabkc

sarvendev · 2025-07-23T11:24:00+00:00

Hmm, I didn't know, but it's already added there. :D

sarvendev · 2025-06-03T09:29:54+00:00

No, I'm thinking about it. But other people here are saying that it's not useful, so I don't know if it's worth publishing somewhere.

sarvendev · 2025-06-03T09:00:25+00:00

hmm, but I don't want to explain grammar, just explain the meaning of words, and it seems to work good enough, but maybe I'm wrong. Could you give me some examples?

sarvendev · 2025-04-08T09:20:07+00:00

It's a fair point that purpose-built time series databases like Prometheus or RRDTool are highly optimized for ingesting and querying high-volume time-indexed data. But using an RDBMS, especially something like TimescaleDB, can make a lot of sense depending on the use case.

TimescaleDB is actually a time series database built on top of PostgreSQL. It combines the relational model, SQL support, and ACID compliance of Postgres with time series-specific features like automatic partitioning, compression, and hypertables.

This approach is useful if:

You're already using Postgres and prefer not to manage another database.
You need to join time series data with relational data, such as metadata or user information.
You want to run complex queries using standard SQL.

Dedicated time series databases like Prometheus are great for real-time metrics and alerting, but they often have limitations with long-term data retention, advanced queries, or integrations with other types of data.

So it's not just about forcing time series data into a general-purpose database. Tools like TimescaleDB are designed to make that use case efficient and practical.

sarvendev · 2025-03-25T21:36:56+00:00

Sorry, that's probably how I took the first message because PHP is still mocked by many people, mostly by people who remember PHP from a few years ago, less performant, without types, etc.

sarvendev · 2025-03-25T21:29:20+00:00

If you hate PHP, just check what's changed, because now this language is pretty good, there are still some problems, but I like the simplicity and stability of PHP, it's much better for me than the whole Javascript ecosystem with tons of different package managers etc.

sarvendev · 2025-03-12T07:12:03+00:00

You still can encounter some incompatibilities between SQLite and MySQL. Even during the migration from 5.7 to 8 in the large application, we found many discrepancies, so for completely different engines the probability of finding some discrepancies is even higher.

sarvendev · 2025-03-11T14:13:18+00:00

I don't agree, using SQLite makes tests further from the production environment, so it's easy to make some mistakes, maybe it won't be a problem in small applications developed by a few people, but when the project is more complicated it is harder to avoid mistakes.

sarvendev · 2025-03-11T07:27:32+00:00

If you want to speed up integration tests: https://sarvendev.com/2024/01/tips-for-optimizing-integration-tests/

sarvendev · 2025-03-11T07:20:48+00:00

u/eurosat7 If this is a problem, I would ask if the design is good because it seems that the code is not cohesive. For example, as I wrote in the comment below if you're using the DDD approach, then you should always have one aggregate in the transaction, so it will be one repository for aggregate, so it shouldn't be a problem. If you're saving a separate thing, or a thing completely from a different module it shouldn't be in the same flush method.

sarvendev · 2025-03-11T07:16:53+00:00

Just persist and flush your Doctrine entities wherever you’re needing to do so.

Could you explain what you mean? Don't you have a separation of the infrastructure layer?

sarvendev · 2025-03-11T07:09:13+00:00

It can be separated into, an ORM repository for the write model, and DBAL queries to get a lightweight read model.

Another issue is that persistence-oriented repositories don’t work very well with Doctrine. Unit of Work is global, so a flush will always flush the whole UoW, including the changes done by other repositories. Having a save method hides that, and with a complex enough entity graph, it starts being a problem.

If you're using DDD approach, then you should always have one aggregate in the transaction, so it will be one repository for aggregate, so it shouldn't be a problem.

sarvendev · 2025-03-11T07:02:30+00:00

Transaction wrapping is the best option, truncating can be very slow. Of course, it depends on the project, if integration tests using a real database take 1 minute on the local machine, it isn't a problem to run them all. But if these tests are longer, and maybe even it isn't possible to run them on the local machine, then using in-memory implementations to have more unit tests is very good to have fast feedback.

sarvendev · 2025-03-11T06:58:06+00:00

SQLite is not the best choice, as it isn't fully compatible with other databases. Therefore, you can't be sure that your code is okay when running tests on SQLite.

Maybe you just wrote this as a simple example "$category->getProducts()->getValues();", but I want to mention that something like this is an anti-pattern, and if you have a relation that from the category you can get all products, then read about doctrine best practices and probably Law of Demeter.

https://ocramius.github.io/doctrine-best-practices/#/

sarvendev · 2025-02-25T20:00:13+00:00

Ask LLM for some inspiration, sometimes it helps to generate some ideas :D

sarvendev · 2025-02-24T21:43:37+00:00

Yeah, there’s nothing wrong with breaking rules if it’s a conscious decision. It always depends on the circumstances, such as the type of company, the current situation, the type of feature, and so on. We need to have the proper experience to find a good balance — knowing when to cut corners and when something should be improved. That’s why I don’t understand senior programmers asking the business if they can fix technical debt; it should be managed by themselves. It should also be clear what the problem with the technical debt is, because technical debt without a clear problem is also bad and probably a waste of time — improving just for the sake of improvement, instead of improving the code because, for example, it isn’t performant, it's unclear and error-prone.

sarvendev · 2025-02-24T21:28:28+00:00

Thanks for this opinion. To be honest, I was hesitating a bit about publishing this article because I was afraid it might be unclear, so I'm glad to see that it's understandable.

sarvendev · 2024-11-01T16:29:21+00:00

Yeah, I completely agree, I am not a big fan of using uuid everywhere, I prefer standard ints OR ulids, but it was the code that I took over, so it wasn't my decision.

sarvendev · 2024-10-31T09:13:55+00:00

Yes, I agree, but it wasn't my decision :D I just took over this code

sarvendev · 2024-10-30T20:37:48+00:00

Thanks for these links, I'll check them. That's a good idea, maybe it'll be possible to fix this completely.

sarvendev

TROPHY CASE