I'm building a Chrome plugin that tracks users' browsing history, but I'd like to ignore any mobile browsing, keeping only the logs that occurred on a signed-in desktop browser.
I'm also confused about whether the extension code itself runs on signed-in mobile browsers – my event script (using chrome.alarms) occasionally sends browsing logs to a server, and I can see logs being sent even when my laptop is closed, but they usually correspond to when I'm using Chrome on my iPhone.
I can't find any information on either of these issues Chrome's developer portal.
I'm also confused about whether the extension code itself runs on signed-in mobile browsers
Well, for one, mobile Chrome does not support extensions; as such, there is no such risks.
However, an extension published on Chrome Web Store will, by default, replicate itself upon installation to other Chrome profiles that are signed into the same account as part of Chrome Sync. The only way to prevent it is to disable extension sync for the profile, which also makes chrome.storage.sync to stop replicating.
So your "unexpected" logs may come from another desktop Chrome that's signed into the same account - assuming the extension is actually published in CWS.
Related
This questions is related to this other one I posted a few days ago:
Instagram oAuth Authentication postMessage issue only with Mobile Browsers
Pretty much the issue I have is that when logging in my app with Instagram Chrome will behave inconsistently (on Android) and cause me some problems.
As I say in that other thread, IG authentication will reply with the required token and data to authenticate the user in my app.
It will do this by replying with a script that sends that data back to the original window, using window.opener.postMessage().
When I run my app on Chrome in Incognito mode, window.opener.postMessage will work without any issue since only one tab is opened and the reference to the opener isn't lost.
However, when I run this on the same browser but in regular mode (like probably 90% of people will) the behaviour is different.
Chrome will open a tab, close it and open a new one to input auth data. However, window.opener here won't work because the opener reference has been lost (is now null).
How come the same browser, on the same device will have such a different behaviour between two modes?
Does anybody know why this happens and how to prevent this from happening?
It is written here that the push notifications will work even if the browser is closed, but I tested it and it is not the case. I receive push-notifications only if the browser is open (doesnt matter if the particular webpage is open or not).
I tested this on chrome for Desktop & chrome for Android (after updating to latest version).
my question is :- For push notifications to work should the browser be open?
Note:- I used this for testing.
According to Can I Use, Chrome and Firefox desktop browsers require the browser to be running for receiving push notifications; mobile browsers typically don't.
Open Settings (in chrome)
Do the following:
> advanced
> system >
"continue running background apps when chrome is closed"
>enable
On desktop, browsers need a process running. For example on Mac OS X the browser can have no window open but if you look at the dock, the light underneath icon can be glowing (meaning it has a process running). In the scenario you should receive push messages.
If the browser was completely quit, then push messages won't get through.
The same applies to windows and Linux.
On android you should be receiving the messages regardless of whether the browser is open or not. This is in part (as far as I know) to the fact that android manages it's connection to the push service rather than the browser, so it'll receive messages whenever possible.
The messages should (eventually) get through even if they are sent while the browser is closed, or the device is offline, etc. (And this works for me using https://gauntface.github.io/simple-push-demo/ and other tests.)
I've worked on demo to provide push notifications on Google Chrome and Firefox. Demo -> https://twitter.com/d_danailov/status/1163824171480166400
If someone has a question could ping me on twitter.
The public URL: https://push-notifications-ddanailov.firebaseapp.com/
Repo: https://github.com/dimitardanailov/push-notifications
On desktop the browser needs to be running since that is the process that receives the push messages. Some extensions, like hangouts force the browser to keep running even when the last tab is closed so for users with one such extension installed push will work all the time.
On Android, the browser does not need to be running since the entity in charge of receiving the messages is baked into Google Play Services.
The Chrome team is working on the desktop issue in https://bugs.chromium.org/p/chromium/issues/detail?id=402456
It is possible to write Chrome extension where background script can run if Chrome is allowed to run in the background (configurable in settings). It can also use GCM.
EDIT:
For service worker to run in the background even if no tab or window is opened there must be at least one Chrome extension with background permissions installed and Chrome must be allowed to run apps in background. Tested on Linux.
Yes, the other users are right and there is no way to receive them on Windows if the browser is closed unless the browser is running in the background, which some Chrome Apps and Extensions can force. I ran into this recently and found this extension, which I believe may help. It keeps the browser running in the background even if the windows are closed but does not do anything besides that (it is open source and presumably the version uploaded to the Chrome Store matches that version)
https://chrome.google.com/webstore/detail/lightning-reopen/ahphokgmcecbjeipkfkamcdmemghkaph
I had to develop a Chrome Extension for a website i'm working for. I finished developing it just fine. But Chrome automatically turns it off after browser restarts, with following reason:
This extension is not listed in the Chrome Web Store and may have been added without your knowledge.
My question: Is it possible to have a "Trusted" extension without publishing it to the Chrome Web Store. I don't want to publish it because it wouldn't make much sense, because it is for a very restricted number of "corporative" users.
The chrome web store allows you to hide your extension from public listings. It also allows you do inline installation. This would allows users to install the chrome extension in their browser without ever having to leave your website. So it would be hosted in the chrome web store, trusted, but only installable from your own website.
My goal is to send Gmail-style desktop notifications in Chrome or Firefox from a web app (let's call it X) that is NOT currently open in the browser, without requiring the user to install an app or extension. It's okay if the user needs to grant permission to receive notifications from X, and it's okay if the browser needs to be open for the notification to appear, as long as X doesn't need to be open in the browser. A solution that doesn't require any browser window to be open would also work.
I just spent the day digging into this, and so far I think I've learned:
Since OSX Mavericks, it has been possible to do this in Safari 7+ via Safari Push Notifications.
The Web Notifications API works in Chrome/Firefox, but requires the user's browser to be open to X.
Twitter sends similar web notifications without asking the user for permission first, but requires the user's browser to be open to Twitter.
There are lots of references to possible Growl implementations, but as far as I can tell, all of them require the user to install Growl and/or a Growl-enabled app to work.
I could be wrong about any of my statements above - I'd love to hear it! - and I'm open to any other solution too. Any ideas?
Thanks for reading.
You can send push notifications even when your web page is not active using Service Workers, the Notification API for service workers and the push API for server-initiated notifications (or scheduled notifications).
As of June 2016, Service Workers are supported in Chrome, Firefox and Opera. See the status at https://jakearchibald.github.io/isserviceworkerready/
See the following links for related discussions, status of implementation and specifications.
Service workers are enabled by default since Chrome 40, Firefox 33, and Opera 24. See the HTML5Rocks tutorial and MDN.
Push notifications: Chrome 42+, Firefox 44+
You can do exactly what you are looking for using the W3C Push API.
If you want to build everything from scratch I suggest to start reading this tutorial by Google. It is for Chrome, but Firefox works in a very similar way.
However it's a lot of work and the "standard" is still evolving: I suggest that you use a service like Pushpad (I am the founder).
So, I'm building a Guest Internet portal for a public hotspot in a hotel. This means the portal is served through a Network Access Gateway (a Nomadix) that redirects all outgoing traffic to the portal page. The portal needs to be able to set cookies on the browser so that Guests can be automatically logged back in after they idle timeout.
The Problem:
iOS4+ and OS X (10.7+) Devices have a feature called Captive Network Support. This feature continuously scans for Wifi SSIDs, connects to them, and curls http://www.apple.com/library/test/success.html to see if the device is connected to the internet. If it doesn't get the Success response, these devices pop open whats called a Captive Network Portal. This portal is not a true version of Safari Mobile and you cannot save cookies on this browser.
I would like an authoritative answer to the following question:
With client-side javascript/markup can I?
A) Save cookies within the Captive Network (popup) browser
B) Prevent the Captive Network browser from popping up in the first place without whitelisting apple.com
This is kinda the wrong site in the StackExchange network for sysadmin stuff; you may wish to try ServerFault. In my experience as a user, there are WiFi portals out there that manage reauthentication without cookies; perhaps ServerFault can help you find such.
That said, there's one possible solution in terms of iOS client-side development: There are CaptiveNetwork APIs which allow a third-party app to inform the system that it's assumed responsibility for authenticating to particular SSIDs, suppressing the web sheet. It's likely not a desirable solution, since it requires your users to install an app, but it's there.
You could try serving "http://www.apple.com/library/test/success.html" locally when ever an iOS device is detected. This will make the CNA not pop up and then the user could login through mobile safari, in which you can save cookies.
iOS 14 has a new API for work with a captive portal. Btw, Android supports it too