Uploaded image for project: 'Okapi'
  1. Okapi
  2. OKAPI-876

CORS delegation doesn't work with preflight/OPTIONS requests

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • P2
    • Resolution: Done
    • 3.1.2
    • 4.7.3, 4.8.0
    • Standard Bug Write-Up Format
    • CP: sprint 92, CP: sprint 110, CP: sprint 111, CP: sprint 112
    • 5
    • Core: Platform
    • R2 2021

    Description

      Overview:
      The way that CORS delegation was implemented, the CorsHandler is sometimes called multiple times. For most requests this is fine (albeit inefficient). However, the vertx CorsHandlerImpl sends a response if handling an OPTIONS request instead of calling routingContext.next(). The result is that the first time the default handler is called, the request only has CHECK_DELEGATE_CORS set, and since the check has not yet happened, CORS is handled by OKAPI and the response is set, even in cases when delegateCORS=true.

      Steps to Reproduce:

      1. Set a handler so that delegateCORS=true
      2. Register/Enable the module descriptor
      3. make a preflight request to that endpoint via the /_/invoke/tenant/<tid>/path API
      4. Observe via X-Okapi-Trace that the request was never proxied to the module, but rather CORS was handled by OKAPI.

      Expected Results:
      The OPTIONS request is proxied to the module

      Actual Results:
      OKAPI handles CORS

      Additional Information:
      Interested parties:
      hji

      TestRail: Results

        Attachments

          Issue Links

            Activity

              People

                hji Hongwei Ji
                cmcnally Craig McNally
                Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved:

                  TestRail: Runs

                    TestRail: Cases