Uploaded image for project: 'COmanage'
  1. COmanage
  2. CO-2052

REST API Errors

    XMLWordPrintable

Details

    Description

      On behalf of Weaver, Christopher <weave132@msu.edu>

      1. Failure when querying all groups (across COs) via the REST API

      The API documentation (https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fspaces.at.internet2.edu%2Fdisplay%2FCOmanage%2FCoGroup%2BAPI&amp;data=04%7C01%7Canders15%40uwm.edu%7C4425cb09ee8e488ac37008d88d9b5727%7C0bca7ac3fcb64efd89eb6de97603cf21%7C0%7C0%7C637415045613370049%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=rHy%2FAP4Zv5UHBrkPlUuY%2FVjXVErRkgt8h8cQmqjaVCc%3D&amp;reserved=0) states that this is permitted, but CoGroupsController assumes without checking that a CO is set.

      From the client side the failure looks like:

      $ curl -v "https://${CO_API_USER}:${CO_API_PASSWORD}@localhost/registry/co_groups.json"
      % Total % Received % Xferd Average Speed Time Time Time Current
      Dload Upload Total Spent Left Speed
      0 0 0 0 0 0 0 0 -::- -::- -::- 0* Trying ::1...

      • TCP_NODELAY set
      • Connected to localhost (::1) port 443 (#0)
      • TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
      • Server certificate: e69ecdc3f418
      • Server auth using Basic with user 'co_1.api_admin'
        > GET /registry/co_groups.json HTTP/1.1
        > Host: localhost
        > Authorization: Basic [encoded auth data]
        > User-Agent: curl/7.54.0
        > Accept: /
        >
        < HTTP/1.1 500 Internal Server Error
        < Date: Tue, 10 Nov 2020 20:14:27 GMT
        < Server: Apache/2.4.38 (Debian)
        < Strict-Transport-Security: max-age=63072000; includeSubDomains
        < X-Powered-By: PHP/7.3.22
        < Set-Cookie: CAKEPHP=0c172bcbf9a35ecde8ccf5535f40d433; expires=Wed, 11-Nov-2020 00:14:27 GMT; Max-Age=14400; path=/; secure; HttpOnly
        < Set-Cookie: CAKEPHP=0c172bcbf9a35ecde8ccf5535f40d433; expires=Wed, 11-Nov-2020 00:14:27 GMT; Max-Age=14400; path=/; secure; HttpOnly
        < Set-Cookie: CAKEPHP=13f83e4ec984a96875886e643d02e377; expires=Wed, 11-Nov-2020 00:14:27 GMT; Max-Age=14400; path=/; secure; HttpOnly
        < Content-Length: 121
        < Connection: close
        < Content-Type: application/json; charset=UTF-8
        <
        { [121 bytes data]
        100 121 100 121 0 0 1731 0 -::- -::- -::- 1753
      • Closing connection 0 {"name": "An Internal Error Has Occurred.","message": "An Internal Error Has Occurred.","url": "/registry/co_groups.json"}

      Error reports on the server:

      2020-11-10 19:49:28 Notice: Notice (8): Trying to get property 'CoIdentifierAssignment' of non-object in [/srv/comanage-registry/app/Controller/ CoGroupsController.php, line 107]
      Trace:
      ErrorHandler::handleError() - CORE/Cake/Error/ErrorHandler.php, line 230
      CoGroupsController::beforeRender() - APP/Controller/CoGroupsController.php, line 107
      CakeEventManager::dispatch() - CORE/Cake/Event/CakeEventManager.php, line 244
      Controller::render() - CORE/Cake/Controller/Controller.php, line 941
      Dispatcher::_invoke() - CORE/Cake/Routing/Dispatcher.php, line 200
      Dispatcher::dispatch() - CORE/Cake/Routing/Dispatcher.php, line 167
      [main] - APP/webroot/index.php, line 962020-11-10 19:49:28 Error: [Error] Call to a member function find() on null
      Request URL: /registry/co_groups.json
      Stack Trace:
      #0 /srv/comanage-registry/lib/Cake/Event/CakeEventManager.php(244): CoGroupsController->beforeRender(Object(CakeEvent))
      #1 /srv/comanage-registry/lib/Cake/Controller/Controller.php(941): CakeEventManager->dispatch(Object(CakeEvent))
      #2 /srv/comanage-registry/lib/Cake/Routing/Dispatcher.php(200): Controller->render()
      #3 /srv/comanage-registry/lib/Cake/Routing/Dispatcher.php(167): Dispatcher->_invoke(Object(CoGroupsController), Object(CakeRequest))
      #4 /srv/comanage-registry/app/webroot/index.php(96): Dispatcher->dispatch(Object(CakeRequest), Object(CakeResponse))
      #5 {main}
      172.20.0.1 - co_1.api_admin [10/Nov/2020:19:49:28 +0000] "GET /registry/co_groups.json HTTP/1.1" 500 2089 "-" "curl/7.54.0"

      It appears that co_identifier_assignments does not need to be set, so inserting

      if(!is_null($this->Co))

      before the current app/Controller/CoGroupsController.php:107 seems to fix the problem

      1. Error reported when a CoService is deleted

      When deleting a service via the API, an error result is reutnred, even though subsequent checking shows that the service has actually been deleted. The errors produced on the server side look like:

      2020-11-10 23:01:11 Notice: Notice (8): Undefined variable: e in [/srv/comanage-registry/app/Model/Behavior/ProvisionerBehavior.php, line 1328]
      Trace:
      ErrorHandler::handleError() - CORE/Cake/Error/ErrorHandler.php, line 230
      ProvisionerBehavior::provisionServices() - APP/Model/Behavior/ProvisionerBehavior.php, line 1328
      ProvisionerBehavior::determineProvisioning() - APP/Model/Behavior/ProvisionerBehavior.php, line 292
      ProvisionerBehavior::afterDelete() - APP/Model/Behavior/ProvisionerBehavior.php, line 90
      ObjectCollection::trigger() - CORE/Cake/Utility/ObjectCollection.php, line 129
      CakeEventManager::dispatch() - CORE/Cake/Event/CakeEventManager.php, line 244
      AppModel::delete() - APP/Model/AppModel.php, line 760
      StandardController::delete() - APP/Controller/StandardController.php, line 365
      ReflectionMethod::invokeArgs() - [internal], line ??
      Controller::invokeAction() - CORE/Cake/Controller/Controller.php, line 499
      Dispatcher::_invoke() - CORE/Cake/Routing/Dispatcher.php, line 193
      Dispatcher::dispatch() - CORE/Cake/Routing/Dispatcher.php, line 167
      [main] - APP/webroot/index.php, line 96

      2020-11-10 23:01:11 Error: [Error] Call to a member function getMessage() on null
      Request URL: /registry/co_services/16.json
      Stack Trace:
      #0 /srv/comanage-registry/app/Model/Behavior/ProvisionerBehavior.php(292): ProvisionerBehavior->provisionServices(Object(CoService), Array, false, 'SD')
      #1 /srv/comanage-registry/app/Model/Behavior/ProvisionerBehavior.php(90): ProvisionerBehavior->determineProvisioning(Object(CoService), false, 'SD')
      #2 /srv/comanage-registry/lib/Cake/Utility/ObjectCollection.php(129): ProvisionerBehavior->afterDelete(Object(CoService))
      #3 /srv/comanage-registry/lib/Cake/Event/CakeEventManager.php(244): ObjectCollection->trigger('afterDelete')
      #4 /srv/comanage-registry/app/Model/AppModel.php(760): CakeEventManager->dispatch(Object(CakeEvent))
      #5 /srv/comanage-registry/app/Controller/StandardController.php(365): AppModel->delete('16')
      #6 [internal function]: StandardController->delete('16')
      #7 /srv/comanage-registry/lib/Cake/Controller/Controller.php(499): ReflectionMethod->invokeArgs(Object(CoServicesController), Array)
      #8 /srv/comanage-registry/lib/Cake/Routing/Dispatcher.php(193): Controller->invokeAction(Object(CakeRequest))
      #9 /srv/comanage-registry/lib/Cake/Routing/Dispatcher.php(167): Dispatcher->_invoke(Object(CoServicesController), Object(CakeRequest))
      #10 /srv/comanage-registry/app/webroot/index.php(96): Dispatcher->dispatch(Object(CakeRequest), Object(CakeResponse))
      #11

      {main}

      172.20.0.1 - co_1.api_admin [10/Nov/2020:23:01:11 +0000] "DELETE /registry/co_services/16.json HTTP/1.1" 500 2241 "-" "python-requests/2.24.0"

      app/Model/Behavior/ProvisionerBehavior.php:1328 seems to just be incomplete, as it refers to a variable `$e` which is not defined. The failure happens inside the conditional which tests whether the result of `marshallCoServiceData` is empty, which seems to occur when `$coServiceId` is the ID of the just deleted service. So, it appears that there may be a more general logic error that this function is being called to (re)provision the service after its record has already been deleted. Perhaps it needs to be invoked sooner, before the rest of the delete has gone through?

      It should also be noted that the dangerous `throw new InvalidArgumentException($e->getMessage());` where `$e` has not been defined seems to also appear in `provisionEmailLists`.

      Attachments

        Activity

          People

            benn.oshrin@at.internet2.edu Benn Oshrin (internet2.edu)
            warren.anderson@at.internet2.edu Warren Anderson (ligo.org)
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: