[General generator] [CORS] Use Swagger-UI client to test server stubs

Description

This is almost an improvement request that deals with the use of Swagger-UI.

I started to use Swagger-UI to check my server part (generated with openapi-generator) and I must say that it is really convenient to get the client part from the same OpenApi file without any code to write. It shows immediately the REST interface (from the client point of view) and allow the tester to send any of the REST requests really easily.

I started to use the docker version that appears a nice solution from my point of view. Due to a single YAML file restriction, I was not able to use the pre-build docker image but I had to clone the swagger-ui and rebuild the docker image after one small fix. See this issue in case you got the same needs. Anyway, this is not the aim of this current report.

Because the swagger-ui is reachable on one IP:PORT by your browser and this one will request another IP:PORT, your server stub, we will faced to CORS policy that will make your browser failed to send the REST request.

The server stub will need to answer with dedicated headers and also will need to handle the OPTIONS request for the first request. Of course, by default none of these two constraints are generated by the generator (and that's fine), so the user have to implement by its own :

• The OPTIONS capture and answer OK (HTTP 200) with at least two headers allowing CORS
• Add these two dedicated HTTP headers in each response

For example in C++ each HTTP end point Implementation would need to add these two lines :

void CheckApiImpl::do_it(const Pistache::Rest::Request &request, Pistache::Http::ResponseWriter response)
{
    response.headers().add<Pistache::Http::Header::AccessControlAllowOrigin>("*") ;
    response.headers().add<Pistache::Http::Header::AccessControlAllowHeaders>("DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,api_type,Authorization") ;

    response.send(Pistache::Http::Code::Ok, "I did some magic\n");
}

And, as described above, also handle the OPTIONS request to answer with the same HTTP headers.

This is a little boring and here is my improvement proposal :

I suggest to add an option onto the openapi-generator command line that will generate automatically the add of these two headers inside the API endpoint (not the Impl endpoint) so that the user will not have to care about that when this option is activated.

For example :

openapi-generator-cli.sh generate --allow-cors -i ./openapi.yaml -g cpp-pistache-server -c ./config.json  -o .

This would generate this kind of code inside the API and not inside the IMPL

void CheckApi::do_it_handler(const Pistache::Rest::Request &request, Pistache::Http::ResponseWriter response) {
    // Getting the body param

    Requestblabla requestBlabla;

    //--------------------------------------------------------
    // Add the headers before calling the interface method
    //--------------------------------------------------------
    response.headers().add<Pistache::Http::Header::AccessControlAllowOrigin>("*") ;
    response.headers().add<Pistache::Http::Header::AccessControlAllowHeaders>("DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,api_type,Authorization") ;

    try {
      nlohmann::json request_body = nlohmann::json::parse(request.body());

      requestBlabla.fromJson(request_body);

      this->do_it(requestBlabla, response);

    } catch (std::runtime_error & e) {
      //send a 400 error
      response.send(Pistache::Http::Code::Bad_Request, e.what());
      return;
    }
}

The aim is to simplify the validation and all the tests the developers may want to run before the deployment. The deployment process may not activate these generation option and the application will still work without any source modifications and without any security issues.

Start at the openapi-generator-cli.sh generate entry point and the cpp-pistache-server generator named in the example. Review how generator options and endpoint handlers are represented; done means an opt-in --allow-cors option produces the requested CORS headers and OPTIONS handling while leaving default generation unchanged.