Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] - 2.12 auth redirect resets query #1823

Open
dhumphries-sainsburys opened this issue Mar 12, 2024 · 7 comments
Open

[BUG] - 2.12 auth redirect resets query #1823

dhumphries-sainsburys opened this issue Mar 12, 2024 · 7 comments
Labels
bug Something isn't working triaged

Comments

@dhumphries-sainsburys
Copy link

Describe the bug

When a user is forced through auth redirects either for initial login or reauth after timeout the query they were navigating to or previously loaded is lost and they are directed back to the homepage of dashboards

To Reproduce
Steps to reproduce the behavior:

  1. Setup an openid provider
  2. Hook up to dashboards
  3. Navigate to a known query URL assuming you do not have active auth
  4. Get directed to home

Expected behavior
It load whatever you were on before the redirect took effect

OpenSearch Version
2.12

Dashboards Version
2.12

Plugins

Inbuilt Security One
https://github.com/Aiven-Open/prometheus-exporter-plugin-for-opensearch

@dhumphries-sainsburys dhumphries-sainsburys added bug Something isn't working untriaged labels Mar 12, 2024
@manasvinibs
Copy link
Member

Can you provide more details on the configuration? Routing to security Dashboards to look.
@opensearch-project/admin Can you route this to Dashboards security plugin?

@bbarani bbarani transferred this issue from opensearch-project/OpenSearch-Dashboards Mar 12, 2024
@dhumphries-sainsburys
Copy link
Author

I believe this is likely to be the relevant part of the config. We install via the helm chart approach in case that matters

opensearch_dashboards.yml: |
    opensearch.hosts: [https://opensearch-cluster-client:9200]
    opensearch.ssl.verificationMode: none
    opensearch.requestHeadersWhitelist: [authorization, securitytenant]

    opensearch_security.multitenancy.enabled: false
    opensearch_security.multitenancy.tenants.preferred: [Private, Global]
    opensearch_security.readonly_mode.roles: [kibana_dashboards]
    opensearch_security.cookie.secure: true
    opensearch_security.auth.type: "openid"
    opensearch_security.openid.connect_url: "https://dex.${env}.${infra_domain}/.well-known/openid-configuration"
    opensearch_security.openid.client_id: "opensearch"
    opensearch_security.openid.client_secret: "${opensearch_client_secret}"
    opensearch_security.openid.base_redirect_url: "https://logs.${env}.${infra_domain}"
    opensearch_security.openid.scope: "openid email profile groups offline_access"
    server.host: '0.0.0.0'

@cwperks
Copy link
Member

cwperks commented Mar 18, 2024

[Triage] @dhumphries-sainsburys Thank you for filing this issue and providing your configuration.

There was a PR that went into 2.12 that is related to nextUrl for openid that should resolve the issue, but I see that you are using 2.12.

Could you post the network calls on login during the issue? You can contact maintainers on the OpenSearch Slack with details.

@cwperks cwperks added triaged and removed untriaged labels Mar 18, 2024
@ubcharron
Copy link

I have the same problem on 2.12. I think "redirectHash" is getting dropped during the redirect to the IDP.

In the call to /auth/openid/login?nextUrl=%2Fosd%2Fapp%2Fdata-explorer%2Fdiscover&redirectHash=true, I noticed that the returned cookie has redirectHash set to false

{ oidc:
   { state: '...',
     nextUrl: '...',
     redirectHash: false },
  authType: 'openid' }

Then once the IDP redirects the browser to /login?code=whatever, I don't see /auth/openid/redirectUrlFragment ever getting called after.

Doesn't schema.boolean() at routes.ts#L102 convert the string to an actual boolean, so the strict equality test at routes.ts#L138 always fails ?

@fbegyn
Copy link

fbegyn commented Apr 9, 2024

I can confirm that this bug occurs in 2.12.0 and 2.13.0, it essentially breaks login flow for deploying the dashboard on a subpath since after logging the user end up on / (which in my case has nothing running).

@dhumphries-sainsburys
Copy link
Author

I can confirm this bug continues to still be present in 2.15.0 .

@ahmadabulaban
Copy link

This bug still exists on 2.15.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working triaged
Projects
None yet
Development

No branches or pull requests

6 participants