Fix Swagger and API auth

[Pierstoval]

Fixes #18005

(this is still a WIP) for now

[cconard96]

The new API should also allow sessions from cookies. Several routes use the CookieAuthMiddleware to allow this.

[cconard96]

Fix scope handling for authorization grant:

diff --git a/src/Glpi/Api/HL/Controller/CoreController.php b/src/Glpi/Api/HL/Controller/CoreController.php
index c431416b7a..582d52cbe4 100644
--- a/src/Glpi/Api/HL/Controller/CoreController.php
+++ b/src/Glpi/Api/HL/Controller/CoreController.php
@@ -426,9 +426,9 @@ HTML;
             $user_id = Session::getLoginUserID();
             if ($user_id === false) {
                 // Redirect to login page
-                $scope = implode(',', $auth_request->getScopes());
+                $scope = implode(',', array_map(static fn ($s) => $s->getIdentifier(),$auth_request->getScopes()));
                 $client_id = $auth_request->getClient()->getIdentifier();
-                $redirect_uri = $this->getAPIPathForRouteFunction(self::class, 'authorize');
+                $redirect_uri = self::getAPIPathForRouteFunction(self::class, 'authorize');
                 $redirect_uri .= '?scope=' . $scope . '&client_id=' . $client_id . '&response_type=code&redirect_uri=' . urlencode($auth_request->getRedirectUri());
                 $redirect_uri = $CFG_GLPI['url_base'] . '/api.php/v2' . $redirect_uri;
                 return new Response(302, ['Location' => $CFG_GLPI['url_base'] . '/?redirect=' . rawurlencode($redirect_uri)]);
@@ -455,7 +455,7 @@ HTML;
             return $response;
         } catch (OAuthServerException $exception) {
             return $exception->generateHttpResponse(new Response());
-        } catch (\Throwable) {
+        } catch (\Throwable $exception) {
             return new JSONResponse(null, 500);
         }
     }

Fix IP restriction middleware when using a cookie session/non-OAuth client:

diff --git a/src/Glpi/Api/HL/Middleware/IPRestrictionRequestMiddleware.php b/src/Glpi/Api/HL/Middleware/IPRestrictionRequestMiddleware.php
index f7ce761214..5b165a6c51 100644
--- a/src/Glpi/Api/HL/Middleware/IPRestrictionRequestMiddleware.php
+++ b/src/Glpi/Api/HL/Middleware/IPRestrictionRequestMiddleware.php
@@ -53,13 +53,17 @@ class IPRestrictionRequestMiddleware extends AbstractMiddleware implements Reque
 
         $request_ip = $_SERVER['REMOTE_ADDR'];
 
-        $allowed_ips = $DB->request([
+        $it = $DB->request([
             'SELECT' => ['allowed_ips'],
             'FROM'   => 'glpi_oauthclients',
             'WHERE'  => [
                 'identifier' => $client['client_id']
             ]
-        ])->current()['allowed_ips'];
+        ]);
+        $allowed_ips = [];
+        if (count($it)) {
+            $allowed_ips = $it->current()['allowed_ips'];
+        }
 
         if (empty($allowed_ips)) {
             // No IP restriction

[Pierstoval]

@cconard96 This fixes a few things, however the infinite loop issue remains.

curl-ing this URL:
http://localhost/api.php/v2/authorize?scope=email,user,api,inventory,status&client_id=XXXXXXX&response_type=code&redirect_uri=/api.php/swagger-oauth-redirect
returns a 302 HTTP response with this:
Location: http://localhost/?redirect=http%3A%2F%2Flocalhost%2Fapi.php%2Fv2%2Fauthorize%3Fscope%3Demail%2Cuser%2Capi%2Cinventory%2Cstatus%26client_id%3DXXXXXXXXXX%26response_type%3Dcode%26redirect_uri%3D%252Fapi.php%252Fswagger-oauth-redirect
(which is basically a redirection to the same previous URL)

[cconard96]

@cconard96 This fixes a few things, however the infinite loop issue remains.

It it supposed to redirect to the login page (index) if not authenticated with the the authorize URL in the query params to tell GLPI to go back there after authentication occurs. If it redirects infinitely, cookies probably aren't being used anymore.

[Pierstoval]

@cconard96 I saw that in the Glpi\Api\HL\Controller\CoreController::authorize() method, however it seems that at this point, the Session::getLoginUserID() always returns null whenever reproducing the scenario in #18005.

Do you think you could checkout this PR locally and try to reproduce it? Because to me, even with a fresh setup, this creates the reported infinite redirection

[cconard96]

@cconard96 I saw that in the Glpi\Api\HL\Controller\CoreController::authorize() method, however it seems that at this point, the Session::getLoginUserID() always returns null whenever reproducing the scenario in #18005.

Makes sense. Like I said, it is like it isn't using cookies/sessions for this part anymore. Maybe because the new API URLs match both the NO_COOKIE_PATHS and NO_SESSION_PATHS patterns in SessionStart,php? Just changing these patterns didn't resolve the issue for me so there is probably more wrong here.

Also, not sure even the legacy API should block sessions (if that is indeed what that property means) since that API doesn't function session-less.

[cedric-anne]

@Pierstoval Could you try to rebase on the current state of the main branch and see if the infinite loop issue persists ?

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[Pierstoval]

On my ungoogled chromium I have no redirection, but I still have the infinite loop on Firefox due to no cookie stored.

The strangest part is that on other applications also using 127.0.0.1 and localhost, the cookie is persisted.