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

Fix some webui that doesn't allowed in private window is loaded in private window #1295

Merged
merged 1 commit into from
Feb 5, 2019

Conversation

simonhong
Copy link
Member

@simonhong simonhong commented Jan 11, 2019

Some webui should not be loaded in private window.
Instead, they should be redirected to normal window.
This also fixes crash when user tries to load sync page in private window.
Sync page will be also redirected to normal window.

Fix brave/brave-browser#2853
Fix brave/brave-browser#2852

Submitter Checklist:

  • Submitted a ticket for my issue if one did not already exist.
  • Used Github auto-closing keywords in the commit message.
  • Added/updated tests for this change (for new code or code which already has tests).
  • Verified that these changes build without errors on
    • Windows
    • macOS
    • Linux
  • Verified that these changes pass automated tests (npm test brave_unit_tests && npm test brave_browser_tests) on
    • Windows
    • macOS
    • Linux
  • Ran git rebase master (if needed).
  • Ran git rebase -i to squash commits (if needed).
  • Tagged reviewers and labelled the pull request as needed.
  • Request a security/privacy review as needed.
  • Add appropriate QA labels (QA/Yes or QA/No) to include the closed issue in milestone

Test Plan:

BraveSchemeLoadBrowserTest.*PageIsNotAllowedInPrivateWindow

Reviewer Checklist:

  • New files have MPL-2.0 license header.
  • Request a security/privacy review as needed.
  • Adequate test coverage exists to prevent regressions
  • Verify test plan is specified in PR before merging to source

@simonhong simonhong self-assigned this Jan 11, 2019
@simonhong simonhong force-pushed the adjust_url_mapping_timing branch 3 times, most recently from c56a0bc to 3db9f6a Compare January 11, 2019 11:35
#undef Navigate
#undef IsURLAllowedInIncognito

void Navigate(NavigateParams* params) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is exactly what we don't want to do: try to find every place we need to hook in to map the url. We need to map it once and only once in a place that takes effect before any security checks

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried to test this place as a replacement of current mapping not for another hooking with current one. So I inserted NOTREACHED() there.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Of course, I'll still studying navigation flow to find better place :)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep, just need to remember that there are many, many different paths and most of the are initiated by the renderer

Copy link
Collaborator

@bridiver bridiver left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see comments below

@simonhong simonhong force-pushed the adjust_url_mapping_timing branch 3 times, most recently from 2e2d7fa to 83b19b3 Compare January 18, 2019 09:12
@simonhong simonhong changed the title WIP: Adjust url mapping from brave to chrome scheme timing Adjust url mapping from brave to chrome scheme timing Jan 18, 2019
@simonhong simonhong changed the title Adjust url mapping from brave to chrome scheme timing Adjust mapping from brave to chrome scheme timing Jan 18, 2019
@simonhong simonhong added this to the 0.61.x - Nightly milestone Jan 18, 2019
@simonhong simonhong requested a review from bbondy January 18, 2019 09:30
@simonhong
Copy link
Member Author

simonhong commented Jan 18, 2019

@bridiver With this new mapping timing, previously skipped url check/verification that did for chrome ui are also applied to brave ui for browser-initiated navigation.
After #1196, renderer-initiated navigation doesn't use brave url. I spend a lot of time to investigate about navigation path and cannot find better place than this.
PTAL again.

@simonhong simonhong removed this from the 0.61.x - Dev milestone Jan 24, 2019
@@ -63,6 +63,12 @@ namespace {

bool HandleURLRewrite(GURL* url,
content::BrowserContext* browser_context) {
if (url->SchemeIs(kBraveUIScheme)) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems like this should be a DCHECK

}

+#if defined(BRAVE_CHROMIUM_BUILD)
+ DCHECK(!url.SchemeIs(content::kBraveUIScheme))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we definitely do not want to patch in a DCHECK here

@@ -13,6 +13,10 @@
bool FixupBrowserAboutURLBraveImpl(GURL* url,
content::BrowserContext* browser_context) {
if (url->SchemeIs(kBraveUIScheme)) {
NOTREACHED() << "brave url should not be reached here. scheme mapping "
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why would we put a NOTREACHED() before a bunch of code? This does not seem correct to me

@simonhong simonhong force-pushed the adjust_url_mapping_timing branch from 83b19b3 to e9f0ccc Compare February 1, 2019 09:27
@simonhong
Copy link
Member Author

@bridiver Rebased onto the master and I think all your comments were resolved with this rebase.
PTAL again.

host != chrome::kChromeUISuggestionsHost;
}

+#if defined(BRAVE_CHROMIUM_BUILD)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this needed?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is needed for our sync page.
Our sync page is not allowed to load private window.
That causes crash for now.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so this is a good example of what I brought up in slack today. If we create this one-off patch then someone else will have to come in and create another one if there is some other host we don't want in private tabs. We should have a chromium_src override that defines a method to call here

@simonhong simonhong force-pushed the adjust_url_mapping_timing branch from e9f0ccc to d2a5854 Compare February 1, 2019 23:21
@simonhong simonhong changed the title Adjust mapping from brave to chrome scheme timing Fix some webui that doesn't allowed in private window is loaded in private window Feb 2, 2019
@simonhong simonhong force-pushed the adjust_url_mapping_timing branch 2 times, most recently from 857a3e0 to 3c89b51 Compare February 5, 2019 06:47
@simonhong
Copy link
Member Author

@bridiver This PR will work well after merging #1573.

Some brave pages should not be loaded in private window such as
brave://settings.
Instead, they should be redirected to normal window.
Also sync/rewards host are added to not allowed list.
@simonhong simonhong force-pushed the adjust_url_mapping_timing branch from 3c89b51 to 205f727 Compare February 5, 2019 06:54
@simonhong simonhong added this to the 0.62.x - Nightly milestone Feb 5, 2019
@simonhong simonhong merged commit efbce7a into master Feb 5, 2019
@simonhong simonhong deleted the adjust_url_mapping_timing branch February 5, 2019 20:53
fmarier pushed a commit that referenced this pull request Oct 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants