Unable to Access Swagger UI Assets via Nginx

[sandipanUipl]

When using Nginx to serve a Laravel application, the Swagger UI assets (like swagger-ui.css, swagger-ui-bundle.js, etc.) are not automatically placed in the public directory after running the php artisan vendor:publish --provider "L5Swagger\L5SwaggerServiceProvider" command.

For proper integration with Nginx, these assets need to be publicly accessible. However, the vendor:publish command doesn't place them in the public/vendor directory by default, which results in 404 errors when trying to access Swagger UI.

Steps to Reproduce:

Install the L5 Swagger package via Composer in a Laravel project.

Run the following command to publish the resources:

php artisan vendor:publish --provider "L5Swagger\L5SwaggerServiceProvider"

Verify that the assets (e.g., swagger-ui.css, swagger-ui-bundle.js) are not published to the public/vendor directory.

Attempt to access Swagger UI in the browser.

Nginx returns 404 errors because the assets aren't found.

Expected Behavior:

The Swagger UI assets should be publicly accessible in the public/vendor directory, so they can be served correctly by Nginx. However, they are not automatically published with the vendor:publish command.

Actual Behavior:

The assets are not automatically published to the public/vendor directory, causing Nginx to return 404 errors when trying to load the Swagger UI assets.

Possible Solution:

Manual Asset Publishing: Since the assets aren't published by default, it would be helpful if the documentation or package provided clear instructions for publishing them manually to the public/vendor directory. This can be done by copying the relevant files from the vendor directory (e.g., vendor/swagger-api/swagger-ui/dist/) to public/vendor/swagger-api/swagger-ui/.

Automation Option: Ideally, the php artisan vendor:publish command should include an option (or tag) that automatically publishes the Swagger UI assets to the public/vendor directory, making them accessible via Nginx.

[chippisc]

Having the same problem since wagger-ui 5.29.0.

If I understand the suggested solution correctly that would not solve all the problems that came with swagger-ui 5.29.0:

• The requested url seems to be '<config(l5-swagger.documentations.apiName.paths.base)>/oauth2-redirect.js', so the path depends on the swagger configuration
• This leaves a problem if multiple APIs are defined as the file will use differing urls per API:
  • /api1/oauth-redirect.js /api2/oauth2-redirect.js
  • Defining or symlinking the file multiple times does not seem practical

For now I resolved the problem by defining a route serving the file under the needed url instead of copying it.

Would it maybe be a solution to extend the SwaggerController with a function as so:

    public function loadRedirectJsAsset(Request $request): Response
    {
        $filePath = base_path('vendor/swagger-api/swagger-ui/dist/oauth2-redirect.js');

        if (! file_exists($filePath)) {
            abort(404, 'The oauth2-redirect.js file does not exist');
        }

        $content = file_get_contents($filePath);

        return response($content)
            ->header('Content-Type', 'application/javascript');
    }

This would leave some routes to be defined like so:

    Route::get('<api_path>/oauth2-redirect.js', [SwaggerController::class . 'loadRedirectJsAsset']);

So the route definition needs to be duplicated (or some wildcard magic is needed) but not the actual logic. Ideally even the routes would not have to be duplicated but seems to be hard because the path is hardcoded in oauth2-redirect.html.
Just some fast idea, no final code proposition. Maybe someone has an idea on how to cleanly solve the problem with multiple APIs?

Would really appreciate a guideline on handling this from the package itself ❤️

[LarsLuz]

I have atleast the same problem as the one described by @chippisc

When looking in the code i realized that the asset controller has no routes for the newly created assets from swagger-ui