New issue
Advanced search Search tips

Issue 900893 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug



Sign in to add a comment

".google.com" not getting accessed when blacklist and whitelist policy configured

Reported by rahgu...@qualys.com, Nov 1

Issue description

Steps to reproduce the problem:
1.set below policy in google chrome.
"URLWhitelist": "[\".google.com\"]"
"URLBlacklist": "[\"*\"]"
2.Now try to access google by entering "https://google.com" it will not allow 
3. here chrome convert "https://google.com" to "https://www.google.com" so it will block access to google.

What is the expected behavior?
it should allow access, if user enter in omnibox "https://google.com" otherwise it should block.

What went wrong?
 here chrome convert "https://google.com" to "https://www.google.com" so it will block access to google.

Did this work before? N/A 

Chrome version: 70.0.3538.80  Channel: stable
OS Version: 7.0
Flash Version:
 
Labels: Needs-triage-Mobile
Labels: -Needs-triage-Mobile
Removing Needs-triage-Mobile label as this is Enterprise related.

Thanks!
chrome itself converts to www.google.com - this is a server-side redirect.
I.e. when accessing google.com, the server sends a message indicating (HTTP 301) indicating that the browser should instead access www.google.com.
So I'm afraid chrome really can't do much here.
What's the reason for not allowing all of google.com or at least www.google.com + .google.com ?
Labels: Needs-Feedback
Status: Untriaged (was: Unconfirmed)
Adding Needs-Feedback for the original reporter to reply to the workaround posed in comment #3.
Hey 
thanks for update 
but i believe chromium should check from where it access google.com. 
prior redirect received to www.google.com

 
The whitelist is evaluated on the effective URLs loaded, not only on what the user entered into the omnibar. Redirects (which is happening here) / hyperlinks are very common on the Web and not applying the whitelist to those would be weird.
Labels: Enterprise-Triaged
Owner: privard@chromium.org
Assigning to privard@ for prioritization.
Status: Assigned (was: Untriaged)
This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.

Sign in to add a comment