Hungary, Budapest
Account created on 24 May 2006, almost 19 years ago
  • developer at Gizra 
#

Merge Requests

More

Recent comments

🇭🇺Hungary aron novak Hungary, Budapest

The patch was applied to latest dev as a MR, also I added test coverage.

🇭🇺Hungary aron novak Hungary, Budapest

Let's see if tests do pass.

🇭🇺Hungary aron novak Hungary, Budapest

aron novak made their first commit to this issue’s fork.

🇭🇺Hungary aron novak Hungary, Budapest

We could reproduce it while creating media entities via a bulk upload form, also during migrations.

🇭🇺Hungary aron novak Hungary, Budapest

I had the chance to think about it more.
For the sake of as realistic integration test as possible, we'd still prefer to have all parts of Crowdsec enabled, like on LIVE.

(Any non-trivial software can and will cause surprises. An example: https://github.com/sirbrillig/phpcs-variable-analysis/issues/340 - a widely used and trusted package suddenly broke our CI.)

What if we introduce a "dry mode"? It's like doing really everything, except that it does not use Ban module to block the IPs, but for instance the logger to say it would ban that IP for X amount of time in non-dry mode. How does this sound?

🇭🇺Hungary aron novak Hungary, Budapest

During installation, we faced with this edge case. let's not assume that the IP is always present.

This is extracted from https://git.drupalcode.org/project/crowdsec/-/merge_requests/5 , that was abandoned in the end.

🇭🇺Hungary aron novak Hungary, Budapest

aron novak created an issue.

🇭🇺Hungary aron novak Hungary, Budapest

I agree that `$config['crowdsec.settings']['whisper']['enable'] = 0;` should be fine in these cases.
There was one robustness improvement in the MR that's still valuable, I'll propose that separately.
Going to set back the status where it was originally.

🇭🇺Hungary aron novak Hungary, Budapest

I just added support for username too, good point.

One of the large Drupal-specific PaaS providers does expose Redis to the public internet, so you can debug it easily, then, they of course protect it with authentication.

🇭🇺Hungary aron novak Hungary, Budapest

Of course we can make it configurable.

🇭🇺Hungary aron novak Hungary, Budapest

If the MR is in good direction, we can extend it to handle IPv6, loopback and so on.

🇭🇺Hungary aron novak Hungary, Budapest

I think this is generally valid that non-public addresses should not be included in the business logic of this module.
We needed to solve it for the sake of our automated tests.
And I am sure crowdsec must be enabled during the tests. If ever it would cause a crash somewhere, the test suite of the site must be aware of that.
Will provide a MR soon.

🇭🇺Hungary aron novak Hungary, Budapest

aron novak created an issue.

🇭🇺Hungary aron novak Hungary, Budapest

For the record, this happens on the same site: https://www.drupal.org/project/drupal/issues/3116503#comment-15853664 🐛 Drupal\Component\Plugin\Exception\InvalidPluginDefinitionException: The "menu" entity type did not specify a storage handler. in Drupal\Core\Entity\EntityTypeManager->getHandler() (line 27 Active
The entity definition for "menu" is impartial after cache clears sometimes.

🇭🇺Hungary aron novak Hungary, Budapest

We experience this on 10.3.6.
/admin/structure/menu throws this strange fatal error.

$a = \Drupal::entityTypeManager()->getDefinition('menu');
print_r($a);

As you can see, the menu definition gets impartial, but it's not behaving the same way at every cache rebuild.
If there would be a faulty alter hook, I'd expect that it would kick in every time.

A cache clear may or may not fix it. The subsequent cache clear may break it again.

On this site, which is domain-enabled, high traffic site, it seems like a race condition. However I could reproduce it on a low-traffic non-live environment too, while trying to access admin pages during a cache clear.

We do not use Redis, APCU, only pure database backend for the bins.

🇭🇺Hungary aron novak Hungary, Budapest

I added local_vars_dump too, this is also essential to avoid OOM errors on more complex sites.

🇭🇺Hungary aron novak Hungary, Budapest

https://www.drupal.org/project/protect_form_flood_control is a very good candidate for solving this, having IP-based protection, we applied it successfully at a client project.

🇭🇺Hungary aron novak Hungary, Budapest

We tested it on a client project, worked well.

🇭🇺Hungary aron novak Hungary, Budapest

It seems it is already fixed. The current DEV contains:

$url = "https://management.azure.com/subscriptions/" . $subscription_id . "/resourceGroups/" . $resource_group_name . "/providers/Microsoft.Cdn/profiles/" . $profile_name . "/$endpoint_type/" . $endpoint_name . "/purge?api-version=" . $api_version;

And endpoint_type can be "afdEndpoints", based on the settings.

🇭🇺Hungary aron novak Hungary, Budapest

Aron Novak created an issue.

🇭🇺Hungary aron novak Hungary, Budapest

Aron Novak created an issue.

🇭🇺Hungary aron novak Hungary, Budapest

I am happy to merge a MR, there are some conflicts actually.

🇭🇺Hungary aron novak Hungary, Budapest

Partially addressed, thanks!

🇭🇺Hungary aron novak Hungary, Budapest

I will try to come up with a test, what I concluded that the problematic Feeds have URLs that returns 404 error, not HTTP 200.

🇭🇺Hungary aron novak Hungary, Budapest

We need to note that not all feeds were affected, 4 of ~20 only. However those generated ~50 GB disk usage.

🇭🇺Hungary aron novak Hungary, Budapest

This patch causes a fatal error actually, see:
https://www.drupal.org/project/physical/issues/3365817 🐛 Fatal error when the unit is not a dropdown Closed: won't fix

🇭🇺Hungary aron novak Hungary, Budapest

it is caused by a patch, it is not broken in the module itself.

🇭🇺Hungary aron novak Hungary, Budapest

Aron Novak created an issue.

🇭🇺Hungary aron novak Hungary, Budapest

Problem/Motivation

The current code in the Symfony YAML Unescaper class is not compatible with PHP 7.4 due to the use of curly braces for string offset access. This has been deprecated in PHP 7.4 and will result in errors when running the code on newer PHP versions.

Steps to reproduce

  1. Install PHP 7.4 or higher.
  2. Use the Symfony YAML Unescaper class to unescape characters in a YAML string.
  3. Observe the deprecated error caused by the use of curly braces for string offset access.

Proposed resolution

Update the code in the Symfony YAML Unescaper class to replace the deprecated curly braces with square brackets for string offset access, as shown in the provided patch.

Remaining tasks

  • Review and apply the provided patch.
  • Run tests to ensure compatibility with PHP 7.4 and higher.

User interface changes

None

API changes

None

Data model changes

None

Production build 0.71.5 2024