I programmed a service for the teachers of a school a tool which they can use to automate their classroom.
For easier access, i want to implement authentication via URL. The teacher WLAN is on a seperate subnet than the others.
The URL is a subdomain of a domain I own and added a SSL certificate. Now I am ready to deploy some beacons for test purposes and I noticed that Google Chrome won't show the beacons with my internal URL. URLs like google.com and facebook.com work just fine.
The physical Web browser app recognizes the internal URL.
What should I do?
Unfortunately, you cannot use Chrome to display physical web URLs pointing to a private subnet. Part of the Chrome system is a server-side component hosted at Google that checks the URL, validates that it resolves, and pulls metadata about the page it points to. If the page is not accessible on the open Internet, this check will fail and Chrome will silently ignore the physical web URL transmitted by the beacon.
While you cannot use Chrome to display such URLs, you can display them in your own custom app using detection SDKs like the Android Beacon Library.
Related
I tried to lookup many answers from stackoverflow but couldnt find anything specific to this, I am implementing payment app and I want to display custom-tab in my app to record user visit by storing user-id, either by setting a cookie or using localstorage or by installing a service worker for the domain that custom tabs opens.
Can a https page loaded in custom-tab write cookies that are also
available when visiting the same page from Chrome?
Is localstorage API available for my domain in custom-tab? if yes,
is stored value available from Chrome?
Is installing service worker allowed from Custom-tab? So I have
access to S/W from Chrome browser?
If none of this possible, how could I record the visit from custom-tab and have it available in Chrome when user opens the domain from chrome browser?
Thanks in advance
Chrome Custom Tabs uses the same Cookie jar as Chrome. So, if a Cookie is created when a user accesses the page from a Custom Tab and Chrome is the Custom Tabs provider, it is also available when the user goes to the same domain from Chrome (outside Custom Tabs).
Same as above.
Yes, it is possible to install a service-worker from a Chrome Custom Tab.
You can check all the above by opening the URL that adds the cookie, install the service-worker or writes to the local store inside a Custom Tab, setup the device for debugging, connecting it to your computer and navigating to chrome://inspect/#devices in Chrome. Then choose the device and inspect the cookies, local storage, service-workers, etc.
Looks like Push notifications are finally usable for web-apps! Unfortunately, this requires https for ServiceWorker, which not all sites may have.
One thing I noticed in the spec it mentions:
if r's url's scheme is not one of "http" and "https", then:
Throw a TypeError."
So I'm confused - can the site be http, as long as it includes a serviceworker that is from https? For example, mydomain.com could include an https serviceworker from https://anotherdomain.com?
Another standard, web-api simple-push, doesn't mention requiring https (likely an omission in the documentation?), and "The user experience on Firefox Desktop has not been drawn out yet". Is the documentation on this outdated, or is push really only supported in FirefoxOS??
Simple-push, that is the current push solution in Firefox OS doesn't have anything to do with ServiceWorkers.
The next generation of push, implemented by both Google and Mozilla will be done through ServiceWorkers:
Push API spec
In that case yes, your content will need to be served over HTTPS.
Probably you will be interested in the LetsEncrypt initiative:
letsencrypt.org
A new certification authority that will help developers to transition their content over HTTPS.
Also just for development purposes, both Google and Mozilla implementations of ServiceWorkers allow you to bypass the check of the secure content, if you develop against localhost.
In the case of Mozilla you will need to enable the flag:
devtools.serviceWorkers.testing.enabled: true
But again this will be just for development, and AFAIK, Mozilla push landed or is about to land, and will be available in the nightly builds, you can follow the work here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1038811
No, the new generation of push notifications (i.e. Push API) requires HTTPS.
If you need to add push notifications to a website without HTTPS you can use a third-party service like Pushpad (I am the founder) that delivers notifications on your behalf.
The text you cited from the spec is from the Cache.addAll() section (5.4).
Here's the summary of addAll() on MDN:
The addAll() method of the Cache interface takes an array of URLS, retrieves them, and adds the resulting response objects to the given cache. The request objects created during retrieval become keys to the stored response operations.
Service workers can request & cache URLs that are either HTTP or HTTPS, but a Service Worker itself can only work in its registered Scope (which must be HTTPS).
simple-push is not related to Service Workers; it seems comparable to the approaches other platforms have taken:
Apple Push Notifications
Google Cloud Messaging
I found a nice bypass workaround to allow notifications from websites and domains without SSL, hence http:// and not https:// for Firefox.
Firefox holds a file inside the Mozilla directory called permissions.sqlite which is a sqlite database file that holds the permissions for domains. You can add your domain there http://yourdomainname with permissions for notifications and it will work.
I have created a demonstration for Windows here https://gist.github.com/caviv/8df5fa11a98e0e33557f75215f691d54 in golang
I'm new to creating chrome extensions. I want to test sending messages from a web page to an extension as described here: https://developer.chrome.com/extensions/messaging#external-webpage.
I'd like to just use an html file in my file system, like "file:///C:/Users/johng/Documents/TestExtensionCall.html", to do the initial testing but the developer documentation indicates that you need to include "externally_connectable" in your extension manifest to expose the messaging api and the url pattern must include a second-level domain.
Can an html file from the file system be used to test sending messages from a web page to a chrome extension? Do I actually need to use a web page from a web site to do the testing?
Thanks,
John
For testing externally_connectable, you have1 to use a web server.
Though, you can still use a local development web server. Normally, it would have a localhost hostname, but you can specify an alias for it in your DNS hosts file, say, my.localhost, and it would satisfy Chrome's requirements.
See here for more information about the hosts file.
1 To the best of my knowledge
I got a couple of domains whitelisted. Let's say they are a.mydomain.com and b.mydomain.com
I went to developer options in the chromecast extension and whitelisted mydomain.com and added data-cast-api-enabled=”true” to the html tag
At this point, I was expecting the extension to inject api_script.js (like the one that I am seeing on youtube and netflix)
What am I missing here?
There are two whitelisting procedures listed in the developer documentation.
The first is device whitelisting (under "Whitelisting your receiver device"). During this process you provide 1 or 2 target URLs to the Google Cast team, and they generate an application ID for you. Then when launching a session with the Cast API from a device (Android, iOS, or Chrome browser with extension installed) you provide the string "<applicationId>_<urlNumber>" and the receiver you select will then open the receiver page located at the URL associated with that string.
The second whitelisting (under "Whitelisting Chrome apps" at the link above) is specific to developing a sender app with the Chrome extension, and is configured within the browser. The Chrome extension will only inject the Cast API into specific sender pages currently, but allows developers to whitelist the domain their sender pages are on.
Be sure you are running Chrome version 28 or later.
If you haven't restarted Chrome in a while you may be running an older version; restarting will update Chrome automatically.
In the Chrome address field, enter chrome://extensions, and check the Developer mode checkbox to enable developer mode.
Install the Chrome extension for Google Cast.
On the Cast extension icon in the browser's upper right corner (next to the address field), right-click and select Options.
The Google Cast extension options page opens in a new tab.
On the blue Cast icon, in the page's upper left corner, click four (4) times.
The Developer Settings appear.
In the Cast SDK additional domains field, enter your application's domain, for example, "www.mydomain.com" and click Add.
Code your application's HTML tag as follows:
<html data-cast-api-enabled=”true”>
Reload the application's page.
I observed that the issue was a Javascript error on that page which prevented the injection of cast api by the extension. (Was missing jquery)
I have able to get the injected JS on all other pages
I am trying to create a web page, which embeds several Google Docs in it. My problem is that when this page is viewed on an android device, then the user is presented with the terrible web based Google Docs editor. Therefore, I would like to have a link on my page, which opens the native Google Drive app on the users phone, so he/she can edit the document there. After searching for two hours, I am unable to figure out how to make a link, which automatically opens the document in the native app.
I succeeded with viewing the Google Drive app in google market using the following link:
market://details?id=com.google.android.apps.docs
I also experimented with
googledrive://no-idea-what-to-write-here
But that did not succeed either.
Is this possible at all, or does this only work on iOS?
There does not seem to be a good way to do what you want (at least according to my testing with Android 4.0.4; maybe the situation is different with other versions).
Using http: or https: links intercepted by an app
In theory, just using the https://docs.google.com/... link for the document should work for you. According to this answer on StackOverflow, intercepting http: or https: URLs is the proper way to start an app when opening a link from the Android browser. The Google Drive app does exactly this — it registers intent filters for https://drive.google.com, https://docs.google.com, https://spreadsheets.google.com and a bunch of similar URLs (including http: with the same host names). And this actually works — when using the stock Android browser, attempting to open a link pointing to https://drive.google.com results in the chooser popup with the Google Drive app included in the list (together with all installed browsers); selecting Google Drive results in opening the document in the Google Drive editor, as you want.
But the problem is that such intercepted HTTP[S] URLs work only in the stock Android browser — I have not been able to find any third-party browser which could show the app chooser when following such links. I tested Chrome, Dolphin, Firefox, Light Browser, Opera (including Classic and Mini), UC Browser, and all of them just opened the link internally instead of offering to pass it to the Google Drive app.
Using the intent: URI scheme
There is another way to make a link which starts an Android app — use the intent: URI scheme. I have not been able to find proper documentation for the intent: URI format; of course, the source code for the function which generates such URIs is available.
For your test document:
https://docs.google.com/document/d/1zSzDnV-90Ke3dzCCJ2CZ6iQ3JQ3F1hL1udGDqbNwwbY/edit?usp=sharing
the corresponding intent: link which opens it in the Google Drive app will be:
intent://docs.google.com/document/d/1zSzDnV-90Ke3dzCCJ2CZ6iQ3JQ3F1hL1udGDqbNwwbY/edit?usp=sharing#Intent;scheme=https;action=android.intent.action.VIEW;category=android.intent.category.DEFAULT;category=android.intent.category.BROWSABLE;package=com.google.android.apps.docs;end
A test link with this URI is on a separate page (it is not possible to make an actual link pointing to such URI here).
The process of conversion is as follows:
Replace starting https: with intent:.
Append intent parameters:
#Intent;scheme=https;action=android.intent.action.VIEW;category=android.intent.category.DEFAULT;category=android.intent.category.BROWSABLE;package=com.google.android.apps.docs;end
Here scheme=https correspond to https: in the original URL, so if you want to convert a plainhttp: URL, this field should be scheme=http. And package=com.google.android.apps.docs is the package name of the app which should handle the link.
Now, when such link is followed, the browser should open the Google Drive app directly (without showing the app chooser). However, if the app is not installed, Android will open the Market app instead, and perform a search for the specified package name, so that the user could install the required app.
It is also possible to make the intent: link without the package parameter:
intent://docs.google.com/document/d/1zSzDnV-90Ke3dzCCJ2CZ6iQ3JQ3F1hL1udGDqbNwwbY/edit?usp=sharing#Intent;scheme=https;action=android.intent.action.VIEW;category=android.intent.category.DEFAULT;category=android.intent.category.BROWSABLE;end
In this case the behavior should be the same as when the intercepted https: link is followed in the stock Android browser — the app chooser with the Google Drive app and all browser apps will be displayed, and if the Google Drive app is not installed, the user will not be redirected to install it from Market.
Unlike intercepted http: and https: links, intent: links work in a wider range of Android browser apps; unfortunately, some browsers do not support them. Results of my testing:
Works: stock Android 4.0.4 browser, Chrome, Light Browser, Opera, Opera Classic.
Does not work: Dolphin, Firefox (feature request is pending), UC Browser.
And, obviously, non-Android browsers would not support such links at all, so you will need to use some kind of browser sniffing if your pages also must be usable for other clients.
Using a custom URI scheme
Some apps use completely nonstandard URI schemes, which might also work from third-party browsers. However, the Google Drive app does not do that, therefore this solution is not suitable for it (unless someone creates a “bridge” app which just passes requests to the Google Drive app).
Some browsers could also disallow nonstandard URI schemes except some whitelisted ones (such as market:) due to security concerns; I did not try to test this.