fix(url): handle arbitrary number of levels for relative paths

[DavidVogel]

This pull request enhances the sanitizeUrl utility function to handle URLs with multiple levels of relative paths (such as ../../file.json), ensuring correct path reconstruction. Unit tests have also been added to verify this new behavior.

Description

Improvements to URL sanitization:

• Updated sanitizeUrl in src/core/utils/url.js to correctly process and reconstruct URLs with multiple ../ segments, supporting cases like ../../file.json and deeper relative paths.

Motivation and Context

Current method only handles up to 1 parent level. This allows an arbitrary number of levels.

Fixes #4107

How Has This Been Tested?

• Added new test cases in test/unit/core/utils.js to verify that sanitizeUrl correctly handles URLs with two or more ../ segments.

Screenshots (if appropriate):

Checklist

My PR contains...

• No code changes (src/ is unmodified: changes to documentation, CI, metadata, etc.)
• Dependency changes (any modification to dependencies in package.json)
• Bug fixes (non-breaking change which fixes an issue)
• Improvements (misc. changes to existing features)
• Features (non-breaking change which adds functionality)

My changes...

• are breaking changes to a public API (config options, System API, major UI change, etc).
• are breaking changes to a private API (Redux, component props, utility functions, etc.).
• are breaking changes to a developer API (npm script behavior changes, new dev system dependencies, etc).
• are not breaking changes.

Documentation

• My changes do not require a change to the project documentation.
• My changes require a change to the project documentation.
• If yes to above: I have updated the documentation accordingly.

Automated tests

• My changes can not or do not need to be tested.
• My changes can and should be tested by unit and/or integration tests.
• If yes to above: I have added tests to cover my changes.
• If yes to above: I have taken care to cover edge cases in my tests.
• All new and existing tests passed.

[DavidVogel]

Can someone please take a look at this?

[sn0wcat]

we need this too.

[mhussein]

We stumbled upon this issue as well in a very big project, it is a very annoying problem, and the original code looks so naive with hardcoded handling of just one level. Any reason this is not being picked up?

[MichakrawSB]

Hi @DavidVogel - thanks for contribution, @sn0wcat, @mhussein,

thanks for raising this and sharing the context. We’ve added this PR to our review list with high priority, given the impact and feedback from multiple projects.

We’re currently reorganizing processes and working on major updates (including the new Swagger Editor), so reviews are taking a bit longer than usual - but this one is now at the top of the queue.

Appreciate your patience and input!
Cheers,
Swagger Team

[glowcloud]

Hi @DavidVogel,

Thanks again for addressing this issue! I think the logic could be simplified a bit - we can use a regular expression to get the relative path directly from the trimmed URL. Let me know if you see any issues with this solution.

[glowcloud]

Suggested change

	if (urlTrimmed.startsWith("./") || urlTrimmed.startsWith("../")) {
	if (urlTrimmed.startsWith("./") || urlTrimmed.startsWith("../")) {
	const relativePath = urlTrimmed.match(/^(\.\.?\/)+/)[0]
	const remainingPath = urlObject.pathname.substring(1)
	return `${relativePath}${remainingPath}${urlObject.search}${urlObject.hash}`
	}

[DavidVogel]

@glowcloud Yes, that approach works for me.

[glowcloud]

@DavidVogel Thanks for the confirmation for the improvement! I created a superseding PR, which includes your changes as well: #10640.