Support adding example values to the Spring Security login endpoint.

[zhujianxintian]

I want the login endpoint to automatically apply the properties from spring.security.user (the built-in properties of Spring Security), so that the login endpoint can have default values, and I don't have to manually enter the username and password every time.

spring:
  security:
    user:
      name: admin
      password: password

However, it is recommended to add a property to control whether to automatically apply this, because in production environments the API documentation might be exposed to third parties, and you may want to have a specific switch to avoid exposing the default username and password. This property is recommended to have a default value of false, requiring manual enabling.

[Shubh2-0]

i'm happy to take this on. i can add a custom @ConfigurationProperties flag defaulting to false and use an OperationCustomizer to inject the spring.security.user credentials as request body examples when enabled.

[Mattias-Sehlstedt]

I would argue that this logic is generally something that should definitely be avoided since the benefits are no where close to the risks that they might impose.

Why would one not simply decorate the OpenAPI object in for the test environment if it is deemed cumbersome to enter auth information? E.g. with the OpenAPI bean.

[zhujianxintian]

I would argue that this logic is generally something that should definitely be avoided since the benefits are no where close to the risks that they might impose.

Why would one not simply decorate the OpenAPI object in for the test environment if it is deemed cumbersome to enter auth information? E.g. with the OpenAPI bean.

There might indeed be such an issue, but we've already been using OpenApiCustomizer for customization. However, it doesn't support the @Order annotation, so I can't modify it after Spring Security registers the login endpoint.

If that were supported, perhaps we could indeed implement it with OpenApiCustomizer. Compared to directly overriding the OpenAPI bean, I prefer using a customizer to write a small amount of code for customization, rather than writing a lot of repetitive code.

However, even if customization were possible, the required code would still be quite extensive and tedious. You can check the recent issues – I've reported some of these problems.

[Mattias-Sehlstedt]

To my knowledge the first approach suggested in the linked resources that does it with OpenAPI should not suffer from the @Order that affects the OpenApiCustomizer? I.e., you inject it as a hardcoded value instead of attempting to read it from a dynamic source.

[zhujianxintian]

My thought is to prioritize using a customizer to customize a bean, rather than completely overriding the bean, because the framework has already done a lot of complex work. Overriding would require more code, whereas using a customizer involves less code and you only need to focus on the part you want to customize, with the rest of the adaptation handled by the framework.

The above is my reason for preferring the customizer approach. However, the framework internally simply executes customizers in a plain loop and does not support using the @Order annotation to determine execution order. Why is order needed? Because I must ensure that my customizer runs after the Spring Security login endpoint is registered, so that I can modify the example values. If my customizer runs first (when the login endpoint hasn't been registered yet), it will have no effect.

@Mattias-Sehlstedt You can check the details. #3320