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

Cookies #13126

Merged
merged 20 commits into from
Jun 17, 2022
Merged

Cookies #13126

merged 20 commits into from
Jun 17, 2022

Conversation

boocmp
Copy link
Contributor

@boocmp boocmp commented Apr 22, 2022

Resolves brave/brave-browser#8604,

  1. The combo-box in the Shield pop-up window now shows the actual block status.
  2. Allow all & block all states now produces only one rule in the content settings.
  3. Shields rules (from the combobox) can now be removed by clicking on trash icon in settings.
  4. The Shield down rule is now contained in a separate container and cannot be deleted in settings page.
  5. The "http://firstpaty" placeholder has been removed and the order of the primary/secondary patterns is now correct (not reversed)
  6. Removed default rules from BRAVE_COOKIES, values from settings are used instead.

Submitter Checklist:

  • I confirm that no security/privacy review is needed, or that I have requested one
  • There is a ticket for my issue
  • Used Github auto-closing keywords in the PR description above
  • Wrote a good PR/commit description
  • Squashed any review feedback or "fixup" commits before merge, so that history is a record of what happened in the repo, not your PR
  • Added appropriate labels (QA/Yes or QA/No; release-notes/include or release-notes/exclude; OS/...) to the associated issue
  • Checked the PR locally: npm run test -- brave_browser_tests, npm run test -- brave_unit_tests, npm run lint, npm run gn_check, npm run tslint
  • Ran git rebase master (if needed)

Reviewer Checklist:

  • A security review is not needed, or a link to one is included in the PR description
  • New files have MPL-2.0 license header
  • Adequate test coverage exists to prevent regressions
  • Major classes, functions and non-trivial code blocks are well-commented
  • Changes in component dependencies are properly reflected in gn
  • Code follows the style guide
  • Test plan is specified in PR before merging

After-merge Checklist:

Test Plan:

https://drive.google.com/file/d/1nZhhHR0rOsfZzHa-C7TnIdpggOtkHwKO/view?usp=sharing
https://drive.google.com/file/d/1ZguyenegGPPJ7bXm4aR-o9sKSebnfe-b/view?usp=sharing
check_list_1-17.txt

ContentSetting general_setting = CONTENT_SETTING_DEFAULT;
ContentSetting first_party_setting = CONTENT_SETTING_DEFAULT;
};

// TODO(bridiver) - convert cookie settings to ContentSettingsType::COOKIES
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't think this comment is relevant anymore since we can't use the upstream 3p setting to eliminate having two rules for block 3p

@iefremov
Copy link
Contributor

@goodov ptal?

};
const auto cookie_is_found_in =
[&rule_matcher](const std::vector<Rule>& rules) {
return rules.cend() != base::ranges::find_if(rules, rule_matcher);
Copy link
Member

Choose a reason for hiding this comment

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

any_of?

for (auto&& r : rules) {
cookie_rules_[incognito].SetValue(
r.primary_pattern, r.secondary_pattern, ContentSettingsType::COOKIES,
base::Time(), std::move(r.value), {r.expiration, r.session_model});
Copy link
Member

Choose a reason for hiding this comment

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

is base::Time() alright? won't it break some "delete all data for 1 hour" logic?

brave_shields::ControlType::ALLOW, url);
}

void BlockThirdPartyCookies(const GURL url) {
brave_shields::SetCookieControlType(
content_settings(), brave_shields::ControlType::BLOCK_THIRD_PARTY, url);
content_settings(), browser()->profile()->GetPrefs(),
brave_shields::ControlType::BLOCK_THIRD_PARTY, url);
}

void BlockCookies(const GURL url) {
Copy link
Member

Choose a reason for hiding this comment

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

const GURL url -> const GURL& url everywhere in this file

{"*://[*.]",
net::registry_controlled_domains::GetDomainAndRegistry(
host_pattern.GetHost(),
net::registry_controlled_domains::INCLUDE_PRIVATE_REGISTRIES),
Copy link
Member

Choose a reason for hiding this comment

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

this will return an empty string if the host is an IP address or if a registry is not found (ipfs cases?).

// first-party rule:
map->SetContentSettingCustomScope(primary_pattern, host_pattern,
ContentSettingsType::BRAVE_COOKIES,
GetDefaultAllowFromControlType(type));
Copy link
Member

Choose a reason for hiding this comment

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

a good comment for all cases here would be nice. currently it's unclear why we come up with primary_pattern and not stick with host_pattern only. why we use GetDefaultBlockFromControlType, GetDefaultAllowFromControlType, CONTENT_SETTING_DEFAULT in different Sets?


RecordShieldsSettingChanged(local_state);
}

struct CookieRules {
Copy link
Member

Choose a reason for hiding this comment

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

is this an internal helper only? anonymous namespace then.
also should be a class with private members modifiable only with Merge.

namespace content_settings {
class CookieSettings;
}

namespace brave_shields {

// sync brave plugin cookie settings with chromium cookie prefs
Copy link
Member

Choose a reason for hiding this comment

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

it doesn't do anything like that anymore.

pref_change_registrar_.Add(
CookiePrefService::CookiePrefService(PrefService* prefs) {
DCHECK(prefs);
prefs->SetDefaultPrefValue(
Copy link
Member

Choose a reason for hiding this comment

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

I think maybe we just should drop this class and do this with a patch or in some other place (maybe even create such place to be able to override any default chromium prefs in future).

for (const auto& shield_rule : shield_rules) {
auto primary_compare =
shield_rule.primary_pattern.Compare(cookie_rule.primary_pattern);
shield_rule.primary_pattern.Compare(cookie_rule.secondary_pattern);
// TODO(bridiver) - verify that SUCCESSOR is correct and not PREDECESSOR
Copy link
Member

Choose a reason for hiding this comment

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

what about this and next TODO? do they still make sense or we can drop them?

.primary_pattern = ContentSettingsPattern::FromString(base::StrCat(
{"*://[*.]",
net::registry_controlled_domains::GetDomainAndRegistry(
new_rule.secondary_pattern.GetHost(),
Copy link
Member

Choose a reason for hiding this comment

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

same thing with ip address?

@boocmp boocmp force-pushed the cookies branch 2 times, most recently from 3cf6935 to d90d07f Compare May 16, 2022 09:01
if (old_rule.primary_pattern == wildcard &&
(old_rule.secondary_pattern == wildcard ||
old_rule.secondary_pattern == first_party)) {
// Remove default rules from BRAVE_COKIES because it's already mapped to
Copy link
Contributor

Choose a reason for hiding this comment

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

BRAVE_COOKIES


if (content_type == ContentSettingsType::COOKIES) {
if (cookie_is_found_in(brave_shield_down_rules_[off_the_record_])) {
// Don't do anything with the generated Shiels-down rules. Unremovable
Copy link
Contributor

Choose a reason for hiding this comment

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

shields down

@iefremov
Copy link
Contributor

@boocmp pls wait for the channel migration, then merge to 1.42

… consistent state.

2. The Brave shields settings now have a higher priority than Chromium settings.
3. If Brave shield is down, the cookie settings fallback to Chromium settings.
4. The Brave shields cookie settings can be edited on the cookie settings page.
5. Fixed the reverse order of patterns in BRAVE_COOKIES.
6. Default rules [*,*] was removed from BRAVE_COOKIES.

ContentSetting fp_setting = map->GetContentSetting(
url, GURL("https://firstParty/"), ContentSettingsType::BRAVE_COOKIES);
auto result = CookieRules::Get(map, url, ContentSettingsType::COOKIES);
Copy link
Collaborator

Choose a reason for hiding this comment

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

This should be BRAVE_COOKIES because otherwise the control will show the combined value of shield and setting cookies (incorrectly in many cases) and not be an accurate reflection of the actual setting. See brave/brave-browser#24321

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Delete icon in cookie settings does not delete some entries set from Shields or other settings
4 participants