feat: adding cors and swagger#2
Conversation
|
Thank you for following naming conventions! 😻 |
There was a problem hiding this comment.
Pull Request Overview
This PR adds Swagger/Swashbuckle API documentation and CORS support to the EV Rental API. The application already had OpenAPI support via Scalar, and this change introduces redundant Swagger tooling alongside it.
Key changes:
- Added Swashbuckle packages for Swagger UI generation
- Configured CORS with a permissive policy allowing all origins, headers, and methods
- Added Swagger/OpenAPI documentation generation with JWT Bearer authentication support
- Reformatted SQL initialization script indentation
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| WebAPI/WebAPI.csproj | Added Swashbuckle.AspNetCore and Swashbuckle.AspNetCore.Annotations package references |
| WebAPI/Program.cs | Added CORS configuration with AllowAnyOrigin policy, Swagger middleware setup with JWT Bearer support, and reformatted SQL role initialization script |
| .AllowAnyOrigin() | ||
| .AllowAnyHeader() | ||
| .AllowAnyMethod(); |
There was a problem hiding this comment.
The CORS policy uses .AllowAnyOrigin() which is overly permissive and cannot be used with credentials (JWT tokens in cookies). For a JWT-based API handling authentication, you should either: (1) specify explicit allowed origins using .WithOrigins(\"https://yourapp.com\") for production, or (2) if you need to allow credentials, use .SetIsOriginAllowed(origin => true) with .AllowCredentials() instead of .AllowAnyOrigin(). The current configuration poses a security risk in production environments.
| .AllowAnyOrigin() | |
| .AllowAnyHeader() | |
| .AllowAnyMethod(); | |
| .WithOrigins( | |
| "https://yourapp.com", // Production frontend | |
| "http://localhost:3000" // Local development | |
| ) | |
| .AllowAnyHeader() | |
| .AllowAnyMethod() | |
| .AllowCredentials(); |
| // Swagger / OpenAPI (Swashbuckle) | ||
| builder.Services.AddEndpointsApiExplorer(); | ||
|
|
||
| builder.Services.AddSwaggerGen(options => | ||
| { | ||
| options.SwaggerDoc("v1", new OpenApiInfo | ||
| { | ||
| Title = "EV Rental API", | ||
| Version = "v1" | ||
| }); | ||
|
|
||
| // JWT Bearer token support in Swagger UI | ||
| options.AddSecurityDefinition("Bearer", new OpenApiSecurityScheme | ||
| { | ||
| Description = "JWT Authorization header using the Bearer scheme. Example: \"Bearer {token}\"", | ||
| Name = "Authorization", | ||
| In = ParameterLocation.Header, | ||
| Type = SecuritySchemeType.Http, | ||
| Scheme = "bearer", | ||
| BearerFormat = "JWT" | ||
| }); | ||
|
|
||
| options.AddSecurityRequirement(new OpenApiSecurityRequirement | ||
| { | ||
| { | ||
| new OpenApiSecurityScheme | ||
| { | ||
| Reference = new OpenApiReference | ||
| { | ||
| Type = ReferenceType.SecurityScheme, | ||
| Id = "Bearer" | ||
| } | ||
| }, | ||
| new string[] { } | ||
| } | ||
| }); | ||
| options.EnableAnnotations(); | ||
| }); |
There was a problem hiding this comment.
This code introduces redundant API documentation tooling. The application already has OpenAPI support configured with Scalar (lines 86-99, 113-130) including JWT Bearer security via AddOpenApiWithJwtBearer() (line 90) and custom transformers (BearerSecuritySchemeTransformer, AuthorizeOperationTransformer in ServiceExtensions.cs). Running both Swashbuckle and the existing OpenAPI/Scalar stack simultaneously adds maintenance overhead, potential version conflicts, and confusion for API consumers. Consider removing either the Swashbuckle setup or the existing Scalar-based OpenAPI configuration to maintain a single source of truth for API documentation.
| // Enable Swashbuckle middleware (swagger.json + swagger UI) | ||
| app.UseSwagger(); | ||
| app.UseSwaggerUI(c => | ||
| { | ||
| c.SwaggerEndpoint("/swagger/v1/swagger.json", "EV Rental API v1"); | ||
| c.RoutePrefix = "swagger"; // serves UI at /swagger; set to string.Empty to serve at root | ||
| }); |
There was a problem hiding this comment.
Swagger middleware is unconditionally enabled for all environments, including production. The commented-out if (app.Environment.IsDevelopment()) check on line 103 suggests this was intended to be development-only. Exposing Swagger UI in production can leak API structure, endpoint details, and potentially sensitive information to attackers. Either move this block inside a proper environment check if (app.Environment.IsDevelopment()) { ... } or use a configuration-based feature flag to control Swagger availability per environment.
No description provided.