Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
The parent issue #2856713: Authentication plugins and HTTP authentication has improved a lot the authentication mecanism.
We need to cover it in our tests:
- For each authentication plugins, add a test on a private file on authentication test to be sure to cover also the case of a HTTP client and not only a JSONAPI HTTP client
- Add a test on Oauth plugin
- For each authentication plugins with optional Key module integration, need to test it. So add the Key module in require-dev section in composer.json
- Also add the Key module in the suggest section.
Comments
Comment #2
GrimreaperComment #3
GrimreaperComment #4
ivan.vujovicComment #5
ivan.vujovicHello,
I am posting an incomplete (but functional) patch which does the following:
Still to do:
Comment #6
ivan.vujovicHello, again I am uploading an incomplete patch, but this time the only remaining thing is testing of private file downloads.
So, the interdiff contains the testing of OAuth plugin.
There seems to be a problem with library
League\OAuth2
and its methodClient\Provider\AbstractProvider::getResponse()
because it is calling GuzzleHTTP client's methodsend()
without possibility to add$options
parameter. Without altering default$options['allow_redirects']
of GuzzleHTTP request from within the test, Guzzle redirects again to the same URL (in our case it is /oauth/token) as GET, which causes a Route exception. However, this doesn't happen when the HTTP request to /oauth/token is issued from the back-office (submitting the form).I couldn't determine why this happens, but apparently in case of test, response headers from /oauth/token are different from the response from the back-office call: we have 'Location', content type is 'text/html' and not 'application/json'. I saw that core REST and JSON:API tests always alter
$options['allow_redirects']
so I did the same in my override.One more thing is that I am not very satisfied with the way I overrode this library class, perhaps someone can give me some advice on it. But again, ideally the library class shouldn't be overridden at all and the root cause of the different behaviour in test vs. back-office context should be understood and fixed.
Comment #7
GrimreaperHello @ivan.vujovic,
Thanks a lot for your work!
I will begin to give a look, to see if I can give you hint on your blocking points.
Comment #8
Grimreaper@ivan.vujovic, Really great work so far!!!
Nice usage of traits. Nice slicing of methods. etc.
Here is my review:
simple_oauth also needs to be added in require-dev.
Add a dot at the end.
Nice to have a comment, but I think it needs a little completion. Because I am thinking why the channel user could not have been used.
Ok, I guess this is for that that you had to introduce the TestableGenericProvider.
As we can control Guzzle settings with the settings.php and the client factory service.
I had given a look at core tests implicating a $settings in settings.php. And it seems that you only have to create a new Settings object.
Here are some examples that I found:
- app/core/tests/Drupal/Tests/Core/Http/ClientFactoryTest.php
- app/core/tests/Drupal/Tests/Core/Database/UrlConversionTest.php
- app/modules/contrib/redis/tests/src/Functional/WebTest.php
I think that way you can avoid the testableGeneric provider and simplify the code.
Also as Authentication tests are in separated classes let's take that as an advantage :)
Small typo: authorization.
Comment #9
ivan.vujovicHello @grimreaper,
Many thanks for your advice on using Settings to override GuzzleHTTP client options!
I fixed the issues from your previous comment.
Comment #10
ivan.vujovicHello again,
I added the private file test and refactored the test classes so that they all inherit an abstract base class.
Comment #11
GrimreaperHello,
Thanks @ivan.vujovic for your very good work!
PHP Doc to update.
Small typo: administrative
2 small fix that I will handle. So it will be the occasion to post a new patch to retest against recent merge.
Comment #12
Grimreaper~1.14 to be similar to the other require-dev Drupal modules.
Comment #14
Grimreaper