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] Invalid next URL when session expired #2135

Open
Hailong-am opened this issue Oct 11, 2024 · 5 comments
Open

[BUG] Invalid next URL when session expired #2135

Hailong-am opened this issue Oct 11, 2024 · 5 comments
Labels
bug Something isn't working

Comments

@Hailong-am
Copy link
Contributor

What is the bug?

Here is the url with error

http://localhost:5601/app/login?nextUrl=%2Fapp%2Fopensearch_index_management_dashboards_%252Frollups#/rollups?from=0&search=&size=20&sortDirection=desc&sortField=_id

{
    "statusCode": 400,
    "error": "Bad Request",
    "message": "[request query.nextUrl]: Invalid nextUrl parameter."
}

The nextUrl is /app/opensearch_index_management_dashboards_%2Frollups
Based on the validation rule, it has %2F which is not allowed.

if (
(pathMinusBase && !pathMinusBase.startsWith('/')) ||
(pathMinusBase.length >= 2 && !/^\/[a-zA-Z_][\/a-zA-Z0-9-_]+$/.test(pathMinusBase))
) {
return INVALID_NEXT_URL_PARAMETER_MESSAGE;
}

How can one reproduce the bug?
Steps to reproduce the behavior:

  1. Enable workspace and goes into a workspace
  2. Go to http://localhost:5601/app/opensearch_index_management_dashboards_%2Frollups#/rollups?dataSourceId=&from=0&search=&size=20&sortDirection=desc&sortField=_id
  3. Wait for session expired
  4. See error

What is the expected behavior?
A clear and concise description of what you expected to happen.

What is your host/environment?

  • OS: [e.g. iOS]
  • Version [e.g. 22]
  • Plugins

Do you have any screenshots?
If applicable, add screenshots to help explain your problem.

Do you have any additional context?

@Hailong-am Hailong-am added bug Something isn't working untriaged labels Oct 11, 2024
@cwperks
Copy link
Member

cwperks commented Oct 14, 2024

@Hailong-am Why is the URL

localhost:5601/app/login?nextUrl=%2Fapp%2Fopensearch_index_management_dashboards_%252Frollups#/rollups?from=0&search=&size=20&sortDirection=desc&sortField=_id

instead of

localhost:5601/app/login?nextUrl=%2Fapp%2Fopensearch_index_management_dashboards_%2Frollups#/rollups?from=0&search=&size=20&sortDirection=desc&sortField=_id

i.e. Why the %25? (%25 is URL-encoded percent symbol) IMO the logic for nextUrl validation is sound, but the url you have pasted is doubly-encoded.

@cwperks cwperks removed the untriaged label Oct 14, 2024
@cwperks
Copy link
Member

cwperks commented Oct 14, 2024

@Hailong-am Is encodeUriComponent required when declaring the paths in the index-management-dashboards-plugin here?

@Hailong-am
Copy link
Contributor Author

@Hailong-am Is encodeUriComponent required when declaring the paths in the index-management-dashboards-plugin here?

I think so, the application id opensearch_index_management_dashboards_${encodeURIComponent('/routes')}, if remove the encodeURIComponent the application id will be opensearch_index_management_dashboards_/routes, so url will be /app/opensearch_index_management_dashboards_/routes/... that will render application with id opensearch_index_management_dashboards_ which is not exists

@cwperks
Copy link
Member

cwperks commented Oct 14, 2024

We would need to confirm if the route id is the cause of the double encoding. In the security-dashboards-plugin, route ids are explicitly defined and not based on the route configured. Examples: https://github.com/opensearch-project/security-dashboards-plugin/blob/main/public/plugin.ts#L189-L275

The ids are defined with underscores like this: https://github.com/opensearch-project/security-dashboards-plugin/blob/main/common/index.ts#L18-L24

@Hailong-am
Copy link
Contributor Author

route ids are explicitly defined and not based on the route configured. Examples: https://github.com/opensearch-project/security-dashboards-plugin/blob/main/public/plugin.ts#L189-L275

yes, that's the cause. application id could not contains any special character like / +, otherwise it will have same problem.

either we have a place to document this limitation, or we figure out a way to check the application id is a valid and exist one no matter what kind of format does it have.

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

No branches or pull requests

2 participants