🇩🇪Germany @C-Logemann

@avpaderno OK you wrote "single request" but I think it's not so obvious on this doc page → . Now I will follow the process but I think it's a little bit unflexible in cases like this. First I came along and just wanted to offer my help. Yesterday I chatted with a maintainer and he gave me the idea for taking over ownership.

Changes without discussion with existing maintainers is currently even too easy in my opinion. In the past I had a situation where I was only a Co-Maintainer and was suddenly removed by a new owner who dropped any support for the old code. On another project I had a discussion with an owner (without any co-maintainers) and he just decided to give me ownership. What if the current maintainers of this project also want to do this in this case?

Since I dropped ✨ Provide a config to control which entity type to check Closed: outdated I can maybe also drop this. I will think about if I still see a need for this. In any case it's much easier to implement and maintain a hook than a config based solution.

@avpaderno I didn't know that yet. But it makes sense if this issue should be part of the official process. I will add a second issue and connect them.

@pwolanin: Can the test just be created as an addition to current test like a second base field in TestEntityTwo with target user oder do you want a complete separate test?

Already contacted two of the current maintainers. But the one I reached at slack cannot add additional maintainers. Will now contact rest of them.

@eiriksm You are right, when checks only run if there are fields configured to extract links this code is not needed any more. So I close as outdated.

c-logemann → created an issue.

There are now the two views access plugins for role and for permission check which are cloned from core user module and connected to grant context strategy. To get this running I did some refactoring to get the access check through the same main class function from route access which is also used by views and the second check of views. The route access check can now be configured as multiple role check also from other contrib/custom modules. If using in contrib please do it like views is doing it a dynamical route change based on config because roles itself are config based.

This is not a feature request because grant only provide UI fragments and Views is the current recommended way to create a custom UI.

c-logemann → created an issue.

c-logemann → created an issue.

c-logemann → created an issue.

c-logemann → created an issue.

Finished Invite with new feature "assign_auto".

Vllt. können wir das Thema mal beim kommenden Drupalcamp in Berlin besprechen.

c-logemann → created an issue.

c-logemann → created an issue.

c-logemann → created an issue.

Soweit ich das verstehe ist gendern "Inklusion auf Sprachebene". Vllt. kennt jemand dazu auch konkrete Informationen oder wir holen die einfach mal ein bei den entsprechenden Stellen der Drupal Community. Der DCOC gilt für alles hier auf drupal.org, auch für Übersetzungen denke ich.
Es steht zwar nicht explizit so im offiziellen " code of conduct → ", aber ich denke man kann da eher raus lesen, daß wir eigentlich gendern sollten, als daß sich ein paar Übersetzer*innen hier fröhlich nach Lust und Laune dagegen entscheiden. Siehe den Punkt: "We think about the impact of our decisions on others and make choices that are as inclusive as possible."
Ähnlich wie bei Coding Standards, die auch nur für neuen Code gelten glaube ich nicht, daß wir verpflichtet sind alle alten Übersetzungen nachzubessern.

P.s.: Den DCOC gibt es auch auf Deutsch und bräuchte auch evtl. mal ein Update und vllt. auch einen offizielleren "Platz" (falls nicht schon vorhanden). Denn wir müssen glaube ich auch auf Drupalcamps darauf verweisen in deutschsprachigem Content.

I created additional routes for /user/{uuid} and /user/{uuid}/edit in the u3id module and published already:
https://git.drupalcode.org/project/u3id

1. This is working fine.
2. The pathprocessing from actual patch makes it impossible for such clean route solution. So I strongly recommend to not commit for core. I currently even not recommend to not move to contrib or with add a warning for risks of breaking other code.

There are lot's of concerns against a pure uuid strategy as I read here: [1726734]

For getting forward I suggest to focus on a a minimal improvement:
1. First of all we should provide an entity_uuid ParamConverter. For u3id I copied of the core jsonapi: 🐛 Use UUID as entity ID Needs review
2. Following the initial feature request we can just provide a possibility to access entities based on additional uuid route configurations.
3. Per default we can just do redirections and introduce settings.php options to change behavior to an entity view.

Everything else should be postponed for core until there is a larger support for more uuid in core routes. I'm currently fine with my contrib project u3id and already solved the problem of rendering the serial uid in the canonical html link with replacing the entity view controller and use now the uuid path.

I did some research of the current code and the actual patch. I still like to have an uuid everywhere strategy including revision routes. But currently the serial id strategy is deep integrated in a dynamical way. So a complete new strategy especially as dual solution ha a high complexity. So I think this should be postponed until there is more interest and some discussion and decision by core maintainers.

Meanwhile I will solve the user uuid situation in contrib and just created a new project for this: U3ID → . With the U3ID module I can present a prove of concept and maybe something which can move partially to core in future.

I will try to test the current patch against the the dual route concept ASAP on patch /user/{user|u3id_user} if there is a conflict which think it will be. Maybe there are other custom solutions out there based on additional routes which can be affected by the PathProcessor solution of the current patch.

@murz Thanks for the input.

Before I start with coding want to add some additional comments after thinking about two routes which allows several thinks like the described identical scheme which is now possible with symfony.
Using two route definitions for each involved entity makes it possible to realize many thinks like different access and also different routes. We can also introduce switches to enable uuid Routes of core only if somebody wants. And if somebody want the additional uuid route just as a redirect or with a path pattern like /uuid/user/{uuid}" this can be solved separately in additional code/contrib/custom code etc. So it's possible to solve seo concerns with robots.txt is possible.
In my personal opinion, it's currently a big disadvantage of Drupal that it's not possible to avoid serial IDs especially for users. At any other place I can avoid this easier e.g with not using node and other core entities. The reason why I want to avoid this that I think this is very important for situations when you run a web application where others should not see how many content entities are generated e.g. users, shop carts, issue tickets, mails etc. This gives competitor organizations and persons too much information not everyone likes to share. This is maybe a reason why companies and other organizations didn't choose Drupal.
On the the other side brings a uuid only strategy lots of possibilities to export, archive, re-import or import elsewhere of content without dealing with complex redirection data.
Both areas are my current motivation. Beside users I have already solved everything with custom entities and the wonderful module entity_reference_uuid. But it would be fine to have something more in core like an official uuid param converter. I know Drupal\jsonapi\ParamConverter and maybe start to use this at first.

I try to improve in direction of second route as described above.

I'm currently working on a small symfony only project and discovered that it's possible to define multiple routes on an identical path and tested that Drupal 10.3 is compatible with this. For example this documetation:
https://symfony.com/doc/current/routing.html#parameters-validation

I tested the last patch and was wondering why it's working so I found this in the patch code:

/**
+   * {@inheritdoc}
+   */
+  public function processInbound($path, Request $request) {
+    $matches = [];
+    if (preg_match('/^\/([a-z_]+)\/(' . Uuid::VALID_PATTERN . ')$/i', $path, $matches)) {
+      $entity_type_id = $matches[1];
+      $uuid = $matches[2];
+      if ($this->entityTypeManager->hasDefinition($entity_type_id)) {
+        $storage = $this->entityTypeManager->getStorage($entity_type_id);
+        $entity_type = $this->entityTypeManager->getDefinition($entity_type_id);
+        if ($entity_type->hasLinkTemplate('canonical') && $entities = $storage->loadByProperties(['uuid' => $uuid])) {
+          /** @var \Drupal\Core\Entity\EntityInterface $entity */
+          $entity = reset($entities);
+          $path = '/' . ltrim($entity->toUrl()->getInternalPath(), '/');
+        }
+      }
+    }
+    return $path;
+  }

It's interesting that it's working but with this solution we loose the benefit of routing information and debugging etc. I like the idea to just disable integer routes in custom code to only use. If just use an entity_uuid param converter it is possible to use the same controllers for all entity paths e.g. "/user/{user}/edit" with a route 'user.uuid_edit'

I also want to make it possible to avoid user (int) ids in password reset paths where currently {uid} is used. But this maybe something for contrib.

Thanks @vsujeetkumar for pushing this forward/keeping patch compatible.

I removed Tasks from issue which are not on focus of this issue:

• [ ]
• [ ]

Ich habe schon ein paar Strings bestätigt und ein paar korrigiert. Diesbezüglich Wichtiger Punkt: die Konsistenz bezüglich des Namens "Usercentrics" sollte, wenn nicht als macheine name z.B. bei den Permission Erklärungen groß geschribene und vor allem nicht übersetzt werden. Ich nehme an, das stammt wieder aus einem Übersetzungstool. Vllt. macht es Sinn das gleich zu erwähnen. Ich hätte nämlich beinah zwei übersetzte Modu-Namen übersehen, weil es tatsächlich Sinn ergab, aber trotzdem falscher Sinn war :-)

I didn't found the time to test and code but I want to thank everyone involved to solve this.

@quadrexdev I added you as a Maintainer. Welcome to the team.

@quadrexdev Thanks for contacting me directly. I already started to review your request. I already found you on slack. Maybe let's chat the next days. And feel free to use my contact form again when this issue moves out of my focus.

Because the impact is a complete corrupted solr cloud setup it can only help to work with two cloud setup not only different collections.

I finally found the configuration which caused the problem which was based on copying drupal config from one project to another but there was no error on import. SO maybe there is a bug in core or this module.

I only disabled it as workaround and will analyze it when I find some time to. And I will try to create some anonymized config and try to get something which can be used to reproduce this error in a vanilla setup.

Yes, it's true. With the "data-" prefix we get a little bit of more functional data to manage and serve. But it's so minimal that if you want to safe some data there are so many possibilities without getting invalid: Maybe w shorter IDs and classes. e.g. "m-item" instead of "menu-item" etc. Or we could move default public files folder from "/sites/default/files" to "/files" so all links to css etc. would be shorter. And as far as I understand it's not needed to add <meta name="Generator" content="Drupal 10 (https://www.drupal.org)"> to any page.

I started with a a serach prelace of " hx-" with " data-hx-" but didn't touched the two JS files. One reason is that I'm not so familiar with JS which is the reason why really like HTMX.

C-Logemann → created an issue.

C-Logemann → created an issue.

I work on a contrib module "signal" which will also provide a "bridge" between Browser UI and CLI to solve several similar problems/ CLI tasks. There will be a Drush command to "ask" Drupal for tasks, work on the ask an return a report which can be viewed in Browser UI. To keep things light every signal type will be an entity bundle. But I think the automatic update possibility is so important that I will help to configure this as easy as possible e.g. with additional config recipe and/or code if needed.

C-Logemann → created an issue.

Adding something to "oauth2_server.api.php" and a test was already planned. And I will think about the response situation.

setServerData() is currently triggered via cron. This could be an interface to run cron via http request. But in CI situations cron isn't always wanted depending on the system needs.

Currently setServerData() is just returning null on cli usage (see also 🐛 Get server uid function return unexpected type null Active . This is avoids corrects tests but even if we just open it would get wrong values of the file owner and they would be store in state api.
Even if the current code will not mess up with the state API storage and cli can get correct serverdata.- This only would be available after a successful check via GUI. Beside the basic auth problematic (see related issue) this cann not work on a fresh test system e.g. in CI-Workflow.

C-Logemann → created an issue.

C-Logemann → created an issue.

@smustgrave The null comes from a a cli check with empty return on setServerData().

As pointed out on duplicate issue I suggest to return a posix compatible "-1" so we don't need to extend the type. See MR on 🐛 [error] TypeError: Drupal\security_review\SecurityReview::getServerUid(): Return value must be of type int, null returned Closed: duplicate .

@smustgrave, just saw the other issue 🐛 Get server uid function return unexpected type null Active . Let's discuss there.

C-Logemann → created an issue.

Because "SecurityReviewData->findWritableFiles" is already checking the fileowner I think it would be a good idea to move this code to another function which could return two the values writable and possibly writeable because of ownership. For backward compatiblity we can keep the old function as wrapper.

The related issue is more important because it directly tests the possibilty to change the ability to change permissions. The file owner check should maybe be separate because there could be server strategies to avoid changes of permissions like chattr and the ownership of a file cannot be used for changing permissions. And if this is the case it would be helpful to deactivate this check.

@smustgrave OK, we need a test which creates an unsave situation to check if the file permission tests is still working correctly? Or is it only to make sure the test will not cause problems?

On my old concept I was only thinking about checking if webserver is the owner of the code. This can also be a good test additionally to the already working search on writeable folder. But this should be handle in different issues.

3.x work is now addressed in this issue: 🐛 file check is problematic "green" when not test with chmod Needs work

Just found my old issue about this: ✨ "Safe file system permissions" should test the ownership of files and directories Closed: outdated

On my test system (D 10.2, nginx, fpm) I changed the file ownership to secured user and the chmod part was just ignored.

I added a file perm read and chmod reset to the code.

I commit a first code which makes the test "real" with

chmod($directory, 0755);

.
But depending on the webserver this can cause problems related to group and others permissions. Maybe we can read the permissions first and just change the user permission. And like good hackers we could clean up by ourself with resetting the permissions as before.

C-Logemann → created an issue.

At first I thought this changed IGNOREME.txt caused my red test. But in my case it's still there after removing an Now I see that the check is on writing process itself not the result. So my problem is currently maybe a problem of my test system or another issue. In any case it looks better when the file is clear at the control line as described in the beginning of the file.

C-Logemann → created an issue.

Firs of all I like to thank @bradjones1 for all the work you've already done on this issue. As soon as I can I like to help with testing in our MariaDB setup.

I have a similar plan like @gapple for the "signal" module with unknown mixed structured data which also like to preserve at it comes from external data sources. With unknown I want to say that this should not be limited to a specific external system as long as it can "report" with json. I will check Reporting API module and maybe integrate.

Additionally I think about some modules where I like to enable some kind of config options content which can be managed by group members. Beside to avoid giving normal users access to Field API it would be a nightmare of multiple field groups with a complete overhead of field schemas to manage this flexibility. Just using a json base field type could just store this user-config as json and it would be searchable when this feature is rolled out.

This mapping helps to determine if a drupal 8+ cookie is available:

map $http_cookie $drupal_cookie {
  default 0;
  ~SSESS 1; # PHP session
}

See this post for example (with "~SESS" for older drupal versions: https://www.webfoobar.com/node/28

The official wiki repo is still available:
https://github.com/nginxinc/nginx-wiki/blob/master/source/start/topics/r...

Because there so many links to the nginx.com wiki I think it's a bad move to just shut it down.
Maybe they need a little bit help to configure a proper redirect.

@solideogloria I don't know if unit fit's all the things I do with nginx config for now.

@andypost Especially angie seems to be very interesting. I planned to try it ASAP.

In our company we already use a cookie check to switch auth request on our daily used test systems. I will work on solution / example with a kind of "@"-section switch I think.

C-Logemann → created an issue.

Because I currently use apache2 not often it's better when somebody else will d. I created this Issue first to relate on it on the next one for nginx and its forks.

C-Logemann → created an issue.

The old nginx.com recipe is gone. Here is a copy in wayback machine:
https://web.archive.org/web/20240511055421/https://www.nginx.com/resourc...

It seems that it's now more important that we have a kind of official nginx example on d.o maybe not only in code.

The related issue is solved because there was just an overseen "minimum-stability" value in project composer.json. After changing to "dev" the grant module was installing. But the tome module still has the same confusing report. Comparing to grant module there is a big difference which probably the cause. Grant has a working module in main namespace which has a dependency on grant:grant_base defined in grant.info.yml. Because there is nothing defined in composer.json I wonder how composer "knows" about the sub modules in modules folder. I think in this composer interpretation of the situation there is an answer an maybe a composer based solution to fix this behavior in tome without changing the current sub module strategy.

Because there was a change in the following file about catch command I looked int this file:
modules/tome_static/src/EventSubscriber/RoutePathSubscriber.php
and found this:
catch (\Throwable $e) {

So it seems this correct dev version code but composer shows installing current stable version "1.12.0". So it' still confusing.

I had over seen "minimum-stability" setting and was than confused about related issue on tome module which is still confusing.

C-Logemann → created an issue.

The tome module does also use submodules. The difference is that tome.info .yml is empty. But the composer result is a little bit strange where only the main project is marked as dev and composer seems to install version 1.12.0 (the current stable) :

 composer require 'drupal/tome:1.x-dev@dev'
./composer.json has been updated
Running composer update drupal/tome
Gathering patches for root package.
> DrupalProject\composer\ScriptHandler::checkComposerVersion
Loading composer repositories with package information
Updating dependencies
Lock file operations: 4 installs, 0 updates, 0 removals
  - Locking drupal/tome (dev-1.x ec6aae3)
  - Locking drupal/tome_base (1.12.0)
  - Locking drupal/tome_static (1.12.0)
  - Locking drupal/tome_sync (1.12.0)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 4 installs, 0 updates, 0 removals
  - Syncing drupal/tome (dev-1.x ec6aae3) into cache
Gathering patches for root package.
Gathering patches for dependencies. This might take a minute.
  - Installing drupal/tome_base (1.12.0)
  - Installing drupal/tome (dev-1.x ec6aae3): Cloning ec6aae332f from cache
  - Installing drupal/tome_sync (1.12.0)
  - Installing drupal/tome_static (1.12.0)

C-Logemann → created an issue.

C-Logemann → created an issue.

@Joachim: Es war nur noch ein String unstranslated, den ich approved habe. Issue kann geschlossen werden.

I'm also not a native speaker. But I now have an idea what you mean.
Yes, the most problems cam from forms and there we should operate to make Drupal safer.
I believe also captcha modules are doing some logging. And especially when using syslog core module you can handle this with fail2ban: https://en.wikipedia.org/wiki/Fail2ban
If fail2ban is not usable there is the core module "ban" which can block IP addresses:
https://www.drupal.org/docs/8/core/modules/ban/overview →

If not yes available you need a connection between ban and your preferred captcha solution. But this is not in ficus of this module.

I won't suggest to organize clients with roles. In our own project we will organize clients with the upcoming module grant → . And on our client projects I try to reduce roles.

> The verification code is triggered

Which code you mean? Do you think about an additional setting of firewall or something else? And generally on which way this code is or should be provided to the request?

Generally about IP blocking and the firewall module. On a first step we only operate on a layer where we won't communicate with the database. There are already core and contrib modules doings such things like "flood".

In any case there will be a way to log IPs when blocked by this module. So the linux tool fail2ban can recognize and can manage blocking on linux firewall which is way more effective than blocking IPs at Drupal.