I have a problem with my Chrome extension inline installation.
It works at www.feedart.co, but it's not working when I load feedart.co.
Any idea how to solve this issue?
According to Chrome Webstore documentation:
For security reasons, inline installations can only be initiated by a page on a site that is verified (via Webmaster Tools) as being associated with that item in the Chrome Web Store. Note that if you verify ownership for a domain (for example, http://example.com) you can initiate inline installation from any subdomain or page (for example, http://app.example.com or http://example.com/page.html).
Therefore, you should verify the top domain (feedart.co) and set that as the associated website for the Webstore item. It would then work on both that domain and the www. subdomain.
Related
I am totally new with this new protocol that is already available in latest Firefox browser but I can not manage it to work on Chrome browser at least in a Windows PC. Now I totally had no idea where to put this question in SO so please understand.
Can I enable DoH feature automatically on Firefox or Chrome in Windows by just visiting a site?
If can not, then can I create a batch script or desktop app instead that will patch/enable DoH to the said browsers?
You can enable DNS over HTTPS (DoH) for Google Chrome like this:
1) Type this into address(URL) bar of Google Chrome: chrome://flags/#dns-over-https
2) You will see "Secure DNS lookups" in the opened tab: Click and change from the select box: Enabled/Disabled or Default
3) Done
I create chrome extension. When user hits special shortcut this extension will add iframe to current active page in chrome. This iframe will load js from external resource (my site) and show some data. Is this allowed (to load external js inside iframe)?
I did not find any restrictions in chrome developers about that, but I worry if my extension will not pass check at chrome webstore.
You can insert any HTML code into the DOM, but if you're inserting an IFRAME, it will be limited by same-origin restrictions which will likely prevent the embedded Javascript from running unless both websites share a common domain and protocol.
See https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy for further details.
Does anybody have the same problem? New extension with verified domain and enabled inline install after clicking on button with chrome.webstore.install();cause redirect to chromestore with get parameter ?utm_source=inline-install-disabled
I recently received the following email from Chrome Web Store Developer Support:
In addition to the existing extension-level protection, our expanded
enforcement will also use machine learning to evaluate each inline
installation request for signals of deceptive, confusing, or malicious
ads or webpages. When we find those signals, we'll selectively disable
that one inline installation request and redirect the user to the
extension's page on the Chrome Web Store. This selective enforcement
will not impact inline installation of that extension from other,
non-deceptive sources. Developers will not be notified of this
enforcement, as it happens on an as-needed basis.
Are you serving any ads on your site or doing anything else that might be perceived as a grey area by ML?
If you're being blatantly deceptive, it would appear that you've been found out. If not, and you're genuinely confused, a possible first step would be to scrape your site of any ads or injected content altogether to see if you're able to regain Google's trust.
I have a Java web application in domain A (that we control). This application displays another website located in domain B (which we do not control) in an iframe. This external website was recently updated to require users to log on before they can see content. They provided us with a URL that will automatically log our users into their site. This URL works when we navigate directly to it in Internet Explorer (we get automatically logged in etc).
However, apparently there was an update to Internet Explorer so that cross domain communication is not allowed. So now when the login URL is displayed in the iframe, it does not successfully log on (I am guessing its being blocked from creating security cookies).
Also, if we browse to the URL directly and get the security in place, then any iframe elements of the site will not work (I am guessing it is being blocked from accessing security cookies).
Does anyone know of a work around for this? Changing the security level on Internet Explorer is not an option (it is controlled by our company's system administrator). Internet Explorer is also our company standard, so we cannot change that (even though it works fine in Firefox).
When you say "elements of the site will not work" what precisely does that mean?
"Cross-domain" interactions have always been restricted in all browsers. This is called "same-origin-policy" and it's the foundation of web security. The "update" to Internet Explorer you're referring to restricts IE such that a webpage on Domain A can no longer navigate a subframe that is inside a page from Domain B. That restriction has been present in IE for 7+ years and is in all browsers. This restriction is not causing your problem.
This most likely problem here is that the subframe fails to set a P3P header that would permit its cookies to be stored. There are perhaps 30 duplicates on that issue on StackOverflow.
To determine if this is what you're encountering, try this:
In IE, click Tools > Internet Options > Privacy tab.
Set the slider to Accept all
Clear your cookies
Restart the browser and retry the scenario.
If this change solves the problem, then the fix is easy: configure the page which is being framed to specify its cookie policy using a P3P response header.
If this doesn't solve the problem, please update the question with more information that would allow others to reproduce it (e.g. traffic logs, live site URL, etc).
It turns out that this was causes by the login site not being on the trusted sites list. Having security add it as a trusted site and pushing that to all company computers solved the issue.
I am developing a Drupal site, within which is a page with an iframe, displaying an external SQL Reporting server driven site.
This iframed site is protected on by HTTP authentication. In all browsers, apart from Chrome, when the page is viewed, the browser driven login box pops up.
In Chrome (Windows & OS X), no login box appears and I get an immediate 401 error from the SQL Reporting Server. I've cleared cache's and even tried on a fresh chrome installation on a VM.
The above method works fine on the clients existing live site, which is ASP driven. Other than CMS technology, the only other obvious difference is domains.
The working live site is referencing a sub domain of itself in the iframe. The development site is referencing a completely different domain.
I've tried /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome -–allow-cross-origin-auth-prompt, which seems to make no difference.
Does Chrome have much tighter cross domain login rules? Or am I missing something else?
According to the devs at chromium, this was an intentional change to protect against phishing attacks. If you say the prod sites reference the same domain, you shouldn't have any issues.
http://code.google.com/p/chromium/issues/detail?id=91814
To switch the (in my mind stupid) security-feature off set Browser flag:
--allow-cross-origin-auth-prompt
In Linux close all Browser Instances and type in terminal:
chromium-browser --allow-cross-origin-auth-prompt
For Windows, Mac, Android... take a look here: http://www.chromium.org/developers/how-tos/run-chromium-with-flags
See http://www.chromium.org/administrators/policy-list-3#AllowCrossOriginAuthPrompt for the policy that can be set versus using flags.
On Windows this can be set via the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome. See http://www.chromium.org/administrators/policy-templates for more information.