I am porting my chrome extension to Safari. The extension requires the user to sign-in and I use the OAuth code flow, which requires a redirect url.
In Chrome, I can use chrome.runtime.getURL('/mypage.html') as a redirect url because in chrome the extension id is never changed.
In Safari, however, the extension id keeps changing in every (xcode) build. This is similar to the behaviour of Firefox but in Firefox, I can use browser.identity.getRedirectURL(). Although not reachable, it guarantees to stay the same.
As in Safari, there is NO browser.identity and safari-web-extension://<extension-id> is blocked by Safari, what url can I use as a redirect URL?
Please see my reply at the apple forum: https://developer.apple.com/forums/thread/670165?answerId=661186022#661186022
Excerpted from my reply on the Apple Forum:
As a workaround, you may use whatever reachable URL as an OAuth
redirect URL and use webRequest.onBeforeRedirect to capture the
redirect attempt and 'force redirect' e.g. by tabs.update.
Although this will work, it is far from being elegant. It could even
be error-prone. While Firefox offers a decent solution for this, why
safari can't / doesn't. This could be a Safari bug or needs a change
request on Safari.
I haven't heard anything from Apple (as usual).
Related
I have a checkout page written in PHP that uses affiliate tracking.
Many affiliates like to advertise via Instagram.
When using the Instagram In App Browser on mobile phones anything within the code that relies on the $_GET variable is failing as it never seems to have any available data.
Thoroughly tested and issue is specifically with the Instagram browser, Facebook browser works as expected.
I can detect the Instagram browser ok via User Agent to do a bit of damage control but don't have a full working solution.
I attempted to force my page open in native browsers on the phone but couldn't get it to work, it was just refreshing the page In-App.
I've attempted loading scripts in iFrames to get needed data but those seem to be blocked as well when going through the In App Browser.
Open to any suggestions.
This resolved the issue for me.
WP Engine host Redirecting Bots
WooCommerce Checkout Issue specific to Instagram In-App Browser
As of about a week ago, my website was working fine. Since Chrome version 54, I can't get it to load. The HTTPS request doesn't get any response and shows a status of "(canceled)". It loads just fine in Chromium, Firefox, Safari, and even Chrome 53. Chrome's developer tools don't give any helpful information - see the image.
Here is what it looks like in Chromium:
(You'll note that the second image shows the subdomain www. That's because, when the naked domain loads properly, it redirects to the subdomain.)
I tried modifying my server code (Node, Express) to print a message upon receipt of each request, and it doesn't even print when I visit the site in Chrome (54.0.2840.71 (64-bit)). It does print when I visit in Chromium (53.0.2785.143 (64-bit)).
I even tried using a different computer. Same thing - fails in Chrome, succeeds in Safari.
What could make it behave like this? I don't know where to begin troubleshooting this.
I don't really understand the behaviour, but I found a way to fix it in my app. I was using the NPM module spdy in place of Node's built-in https module to serve my app over https. Switching back to the built-in module solved the problem. (It's a simple change - the APIs are compatible.) I don't know whether spdy consistently has this issue in Chrome 54, but I've wasted too much time on this issue, so I will leave further investigation as an exercise for the archaeologist who next digs up this answer.
I'm looking at buying an airline ticket, and I'm having to enter my credit card details in a http:// page, that looks like this:
If I look at the source code, this is actually an iframe with an HTTPS source, so this actually secure, but a non-tech-savvy user has no way of knowing that. Obviously, this is horrible (even for tech-savvy users).
Now, my question is, if I was the site offering this iframe (Verified by Visa in this case), is there a way that I could force modern browsers to not allow my page to be used as an iframe on http:// pages, but still allow it to be used as an iframe on https:// pages? Is there a technique that Verified by Visa really should be using here?
I'm looking at buying an airline ticket, and I'm having to enter my credit card details in a http:// page
Ouch! Someone's breaking the PCI-DSS terms of their merchant agreement huh.
If I look at the source code, this is actually an iframe with an HTTPS source, so this actually secure, but a non-tech-savvy user has no way of knowing that.
Indeed. You'd have to look at all the source code, including every piece of script on the parent page, to ensure that there is nothing interfering with the iframe (eg via clickjacking) and that the image you see in the browser page actually is the secure iframe. And ensure there were no other tabs open from the same domain with a reference to the window to cross-document-script into it... a non-starter.
if I was the site offering this iframe (Verified by Visa in this case), is there a way that I could force modern browsers to not allow my page to be used as an iframe on http:// pages, but still allow it to be used as an iframe on https:// pages?
I believe you could do it using Content Security Policy Level 2, eg with the header:
Content-Security-Policy: frame-ancestors https:
However support is patchy: at the time of writing, even the latest IE and Safari don't support it, and obviously it didn't exist at the time 3-D Secure implementations were being written. Still, if it just complains some of the time that would be enough to let an unwitting merchant know they'd messed up their payment integration.
One other thing they might have been able to do back then would be to check the Referer header for an http: address. Still not reliable (and maybe tricky to make work for all possible flows including redirect and pop-up, and in-between redirections) but could have helped.
On my site served over https a user may enter a URL and preview their entered URL in an embedded iframe.
This iframe is getting blocked by Firefox 23's mixed content blocker by default. I'm wondering if anyone knows of a workaround.
You could try using Snapito! (http://snapito.com).
They have an API that works over https, so if you used their preview you would cease getting mixed content.
HTH
What does the following mean? I assume chrome refers to Google's webbrowser Chrome, but does it have its own special protocol (like http:// and ftp://)?
<iframe src="chrome://extension/content/web/web.htm" />"
It has several meanings - Documentation
This is probably what you're looking for:
A chrome:// URL
An URL using the chrome:// protocol. Code loaded from a chrome URL has extended, or chrome,privileges. XUL-based applications load the code for their interface from chrome:// URLs.
Chrome privileges
The code running with chrome privileges is allowed to do everything, unlike the web content, which is restricted in several ways.
It doesn't; chrome:// is a cue to what's known as a protocol handler. Basically, protocol handlers register a protocol scheme, and the browser will then pass off URLs matching that scheme to the handler.
One example of this functionality that you're probably familiar with is mailto:, which is not a protocol, but merely informs the browser to hand off the subsequent URI to a mail program.
It's a special scheme used to refer to something inside the browser itself, or an add-on. There's probably no protocol per se, it just causes Chrome to access an internal resource in some way.
Also, "chrome" probably refers to "the stuff around the page" (i.e. the browser UI) rather than Google Chrome, although it is also what Google Chrome is named after. Firefox uses the same scheme for its internal things.