This would require an 'allowed query parameters' API. But that API would have to validate both the parameter names and the values. And it couldn't just do that, because ?pager is a valid value and would have an integer range of 0-PHP_MAX_INT (or some arbitrary configured value).
Could the value be validated by the module that say they need this parameters? The validation may require a couple of DB queries, but it could be much lighter than building a full page.
Where are the query strings included in the HTML returned by the page?
The full URL is added in form action and in the pages's JS.
If this was not the case, we could use a checksum to avoid duplication in cache. But adding a parameter will still allow to bypass the cache.
This issue has been publicly known for years and still poses a serious risk.
In my opinion, the core problem is that adding irrelevant query parameters still returns a valid page. Instead, Drupal should return a 404 response and avoid caching the page when “fake” query parameters are injected.
As it stands, adding arbitrary query strings (e.g., ?test, ?foo=bar) bypasses the page cache and triggers full page generation. An attacker can exploit this to cause a denial-of-service (DoS) by flooding the site with requests using unique query parameters, quickly overwhelming the backend.
What’s worse is that Drupal treats these URLs as legitimate and includes them—with the fake query strings—in the HTML it returns. The content is therefor not identical of the page requested on the normal URL.
This should absolutely be treated as a critical security issue.
Just for information, this specific issue is also a problem with PHP 8.1
it work but https://www.drupal.org/project/domain_registration → is supported. So let's forget about this module?
Ok I understand. But it was quiet easy to not use the module at the end and copy/past the needed configuration.
Then what is the use of the credential config in admin/config/search/search-api/opensolr when using basic auth?
This issue is 7 years old now, someone with authority has to take a decision.
"this is a bug of the mail provider"
Seriously, Drupal community bring less and less value. Time for me to delete my D.O. account.
It's a critical issue that can lead to the impossibility for user to log-in. In the real world, nobody care if Microsft server "should" act differently.
But if we want to be theoretical: Drupal use a HTTP GET to change data witch is not how HTTP protocol is supposed to be work. A HTTP POST request should be used to change an account from blocked to active. It's a bug and a ugly one.
"Let's overengineering" is the tagline of Drupal.
Looking where to put it I found this https://www.drupal.org/docs/develop/development-tools/disable-caching →
As a side note, the "official documentation" structure is not good and their is no proper place for this. The page should not be "disable caching" but "caching" with a section how-to disable caching. But Drupal doc is beyond repair to be honest.
Changing to need work to fix the button label has mentioned in #33.
I want to stress this is not open to discussion: not respecting the HTTP protocol is a bad idea.
I'm not even sure not having an extra step is a better UX that having one. My impression is that the user would prefer to click on a button "Login" with an explanation on the page "This link allow you to connect once and is valid 1 hour".
But let's assume "auto login" is a much better UX. How do you implement this UX in a proper way?
What you do first is creating a connection system that follows the HTTP protocol (protocol = law, do not break the law!). That mean having an HTTP GET request that directs the user to a page with a form with a "connect" button. That form initiate the HTTP POST request to connect the user.
But but but... I wanted to "auto connect" the user! This is where https://en.wikipedia.org/wiki/Progressive_enhancement come into the picture. Write a small JS script that submit the form automatically. Add a text, "you are being connected automatically, if not please click on the button below". Done.
They may be other good ways, but the current way is definitely not good.