Drupal.urlIsLocal returns incorrect result if site URL contains authentication part

Here's #9 updated for 9.5.x, with the "useless-escape" removed.

Redoing patch for 10.1.x.

I've tested the patch #16 and it seems to work well in the following cases:

Test it more and actually the patch of #16 failed on the following cases:

- username starts with `@`, i.e. https://@blah:blahblahblah@drupal.org
- multiple `@`, i.e. https://asds:blahblah@@blah@drupal.org

The following patch handles these cases:

- https://asds:blahblah@@blah@drupal.org
- https://asds:blahblahblah!@drupal.org
- https://@asds:blahblahblah@drupal.org
- https://@@ds:Ben3v@@@@@a@@@drupal.org
- https://@@ds:Ben3v@@@@@!!!@a@@@drupal.org
- https://@@ds:Ben3v@*&^@@!!!@a@@@drupal.org

Thank you for working on it.

Can we get a test case show the issue.

Also tagging for issue summary to be updated based on the issue template

In our case, we get this issue when trying to run automate testing (go to a page to execute a few actions) on a password protected environment.
I'll work on mocking the issue and write a test case about it.

We discovered a bug with the regex.
Only on Safari on iOS 15.x, the regex is not recognized correctly, causing all JS to failed.

The similar problem is discussed at https://github.com/twopluszero/next-images/issues/55#issuecomment-956545681
The solution is to use RegExp constructor, instead of using regular expression literal.

The following patch fixes this problem, tested on Safari iOS 15.x

We, the mentoring team, are triaging issues for first time contributors at DrupalCon Lille and I think this is a good issue for the contribution day.
We are reserving this issue so please don't work on this issue if you are not at DrupalCon Lille. You can continue the work when the event is over.

It would be great if someone can update the issue summary, then gather the patches from #16 and #22 into a MR and also add the tests needed to validate the latest cases from the comments.

Additionally we need to test this manually on safari.

I'm looking into this as part of Drupalcon Lille 2023

Written a test for this use case. I think we need more tests to cover all the use cases in #18 but this is a start.

Thank you for working on this. This was tagged for issue summary update, I got it started but gaps will need to be filled in, the important parts I usually steps to reproduce and proposed solution.

Also cc failure in #25

fixed the prettier failures, added some test cases for no authentication / symbol-heavy authentication / false positives

THanks, can you please fill in the issue summary also please.

Fyi removing sections isn't encouraged. Even if they don't apply.

Rerunning the tests for #27 to see if random but there were failures. "Build successful" usually means nightwatch failed.

sorry, will remember for next time.

this should fix the tests.

No worries! Will wait to see what drupalCi says.

I'm not the greatest at nightwatch debug

14:28:07   error: JavascriptError: javascript error: Drupal is not defined
14:28:07     (Session info: headless chrome=106.0.5249.103)
14:28:07     (Driver info: chromedriver=106.0.5249.61 (511755355844955cd3e264779baf0dd38212a4d0-refs/branch-heads/5249@{#569}),platform=Linux 4.9.0-0.bpo.6-amd64 x86_64)
14:28:07       at Object.checkLegacyResponse (/var/www/html/core/node_modules/selenium-webdriver/lib/error.js:558:15)
14:28:07       at parseHttpResponse (/var/www/html/core/node_modules/selenium-webdriver/lib/http.js:581:13)
14:28:07       at Executor.exe... == true) - expected "true" but got: "[object Object]" (0ms)

Posted in #testing channel on slack to see if anyone knows what's up.

Seems like the problem is that the page opened to test the function does not include the drupal.js script.

The test needs to visit a page that has the core/drupal library dependency added

Just spotted the edge case: the proposed RegExp solution will likely fail if there's a matching pattern inside the path (which is weird and I can't imagine anyone doing this, but technically it's still a valid URL).

const regex = new RegExp('(?<=//).*@(?=(?:.*.)+[^.]+)');

"https://valid:url@drupal.org/somewhere/".replace(regex, '');
// returns 'https://drupal.org/somewhere/' which is fine

"https://drupal.org/some//really:weird@url/".replace(regex, '');
// returns 'https://url/' which is not correct

Maybe an extra negative lookahead could handle this?

With the patch applied, we're no longer seeing the original error on page load, but we are seeing this error in an alert after AJAX sorting:

An error occurred while attempting to process /views/ajax?search=&sort_by=changed&_wrapper_format=drupal_ajax: Failed to execute 'pushState' on 'History': A history state object with URL 'https://domain/search-content?sort_by=search_api_relevance' cannot be created in a document with origin 'https://domain' and URL 'https://username:password@domain/search-content?search=&sort_by=changed'.

The patch on #34 fixed the issue on Drupal 10.4.5.

I think we can use the and URL Object and compare the absolute URL origin with the window.location origin in this way:

let absoluteUrl = Drupal.url.toAbsolute(url);
const { origin: absoluteOrigin } = new URL(absoluteUrl);
let { protocol } = window.location;
const { origin: windowOrigin } = window.location;
const isSafeOrigin = absoluteOrigin === windowOrigin;

// Later

return absoluteUrl === baseUrl || absoluteUrl.startsWith(`${baseUrl}/`) || isSafeOrigin;

Here is the patch

@diarcastro Please could you create a merge request with the changes?

See https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... → for more details

@malcomio I just created the MR here:
https://git.drupalcode.org/project/drupal/-/merge_requests/12007/diffs