swagger-ui icon indicating copy to clipboard operation
swagger-ui copied to clipboard

Authorize button: logout is not clearing credentials

Open bartlomiej-kedziora opened this issue 5 years ago • 5 comments

Q&A (please complete the following information)

  • OS: [Mint]
  • Browser: [chrome]
  • Version: [80]
  • Method of installation: [e.g. npm, dist assets]
  • Swagger-UI version: [3.25.1]
  • Swagger/OpenAPI version: [Springdoc-openapi: 1.3.9]

Content & configuration

@Bean
    public OpenAPI customOpenAPI() {
        return new OpenApi()
                .components(new Components().addSecuritySchemes("basicScheme",
                        new SecurityScheme().type(SecurityScheme.Type.HTTP).scheme("basic")))
                .addSecurityItem(new SecurityRequirement().addList("basicScheme",
                        Collections.singletonList("basic")));
    }

Example Swagger/OpenAPI definition:

springdoc:
  endpoint: "/swagger"
  pathsToMatch: /v1/**
  api-docs:
    enabled: true
    path: ${springdoc.endpoint}/v3/api-docs
  swagger-ui:
    path: ${springdoc.endpoint}/swagger-ui.html
  cache:
    disabled: true

Describe the bug you're encountering

During the logout from Authorize button, I see that "curl" doesn't contain the header with Authorize, but it seems credentials still exist in session.

To reproduce...

Steps to reproduce the behavior: The scenario for basic auth:

  1. Call secured endpoint from swagger-ui list and got proper unauthorized information.
  2. Click Authorize button
  3. Set login and password
  4. Call secured endpoint and got the proper result from swagger-ui list
  5. Click Authorize button
  6. Click Logout button
  7. Call the same endpoint from points 1 and 4, but there should be information like unauthorized, but still got the proper result expected only for logged user.

Note:

  • I have tried to set at point 7 the same username but wrong password - still didn't get unauthorized information.
  • When set another wrong username at point 7 finally got proper unauthorized information.

bartlomiej-kedziora avatar Jun 02 '20 09:06 bartlomiej-kedziora

I'm seeing something perhaps similar, but I'm not certain if it is caused by the same underlying issue. If it isn't, I can open up a separate issue for it. Here is what I'm seeing:

I recently upgraded from v3.23.0 to v3.36.2. I use a config.json file to reference a v2 API spec and a v3 API spec document from 2 different locations, with the v3 being the default.

When I load up the site everything renders fine and the oauth endpoint and scopes are correct for the v3 spec. When I select the drop down menu to switch to the v2 spec everything on the page renders correctly for the v2 spec, but if you look at the Authorize button, the oauth token endpoint and the oauth scopes are those still for the v3 spec, they did not get updated. If I refresh the whole page the Authorize button will then load the correct information. If I switch back to the v3 spec the same thing happens in reverse and I have to refresh the page again to get the correct oauth info displayed.

Is this caching issue referenced above caused by the same thing causing my issue?

CameronGo avatar Nov 14 '20 03:11 CameronGo

same for me, logout button doesn't clear cookies, i need to do it manually

alikrc avatar Feb 03 '21 00:02 alikrc

With SpringBoot and Keycloak I just fixed it in keycloakSecurityAdapter

XANDERM avatar Mar 18 '21 17:03 XANDERM

For cookie clearing, I raised a PR a while ago, but no one's merging it: #9186

sudiptosarkar avatar Nov 04 '23 10:11 sudiptosarkar

I second @sudiptosarkar, please can this be fixed and merged. When persistAuthorization is set to false there still is the ability for a session window that has not been closed to have the logout button clicked and the previous users credentials are populated and then by clicking "Authorize" again you will be logged in with the previous users credentials.

This is a security issue and the correct behavior her would be to only not clear those credential fields if persistAuthorization was enabled for a given dev\test site.

The current behavior is not sufficient for in production scenarios and these credential fields should be always cleared by default

joeltoth avatar Jun 03 '24 19:06 joeltoth