as you might already know, you should put your service workers inside the base directory so that it has the scope of the whole project, otherwise some features (e.g. navigator.serviceWorker.ready()) won't be available.
My problem is that I've initially put my service worker inside a directory and now I feel kinda trapped.
I use the service worker to register and handle web push notifications and I'm wondering if I would lose all my current subscriptions if I move it to the base directory
N.B. It's mandatory that the service worker registered will remain the same, no new service worker should be registered
If you don't want to move your service worker in base directory. You can use "Service-Worker-Allowed" header in your response. If this header is present then your service worker will be registered even if your sw.js file is in nested directory.
Service-Worker-Allowed header '/'
here the the official documentation regarding this header.
https://w3c.github.io/ServiceWorker/#service-worker-allowed
Related
I have two separate applications under the same origin but on different pages (say origin/a/ and origin/b/). Each page registers a service worker, which operates under its own scope. Whilst service workers are restricted to the pages they are registered on, they share the same caches from the origin. And if I want each service worker to clean up its old caches, it turns out it wipes out also the caches created by another service worker.
I ended up defining a scope const in service workers and manually checking if the cache name starts with it. However, this seems a bit fragile since one could rename this scope, and the cache will get lost. Another approach of using self.registration.scope as a cache name part looks better but also cannot guarantee consistent behaviour for nested pages that could contain yet another service worker.
Is there any consistent way to bind a cache to a service worker that I am missing?
I have a fairly simple question. I have a manifest.json file for my new service worker that lists "start_url" as "https://example.com" and the scope is "/". That works great unless the URL has a subdomain. In that case I get several errors saying that the manifest start url is not valid, it has been ignored, and that the manifest has no matching service worker.
The service worker still works but I would like to eliminate these errors. I use wildcard subdomains for all listings categorized by geographic location (ex: https://city-state.example.com). That lets me feather out the categories on the other side of the domain name (ex: https://city-state.example.com/category/subcategory). Is there a way to use something like https://(*).example.com for the start url or scope to avoid this error?
A service worker is scoped to a single origin and no higher in a file page than the level it is served from.
The rules are to provide security and prevent 3rd party scripts from attaching service workers to invade your site.
You will have to replicate your service worker on each origin. But honestly, unless the application is exactly the same you will want to customize the service worker logic to the specific application.
Does a service worker cache work site-wide, regardless whether the user is actually on an HTML page that has sw.js loaded?
For example:
Assuming...
A registered service worker on the users’ browser
With a local cache controlled by the sw
The local cache has a few files cached including html, js, css and some jpg’s
If the user were to directly visit any of those JPG or CSS files in their browser, does the browser run the request through the service worker and/or on it’s own recognize those local files, and thus render the locally cached file?
One a service worker is activated, its fetch handler will be triggered whenever there is:
A navigation to a URL under the service worker's scope.
A request for a URL made by a client page that's under the service worker's scope. (Such as a request for an image, or stylesheet, etc.)
If you were to navigate directly to a URL that exists under the service worker's scope, even if that URL didn't correspond to an HTML document, the service worker's fetch handler would have a chance to respond.
If your service worker has a fetch handler that always responded with a cached version of a given URL, then yes, that response would be used to fulfill the navigation, even if the asset was an image or stylesheet or something else.
You can test this out for yourself:
Visit a site like https://images.guide/ that installs a service worker, caches a number of resources, and uses a fetch handler that responds to requests for precached resources via the cache.
Go offline.
Navigate to a URL that's precached, like https://images.guide/images/hamburger.svg
You'll see that the precached resource is used to respond to the navigation request.
I have domain like https://example.com and hosting service worker js and main js on it. I am trying to register service worker on other website like https://example2.com.Till now what I have tried:I had created sub-domain like https://example2.example.com and put both main js and service worker js in that folder and registering service worker on 'example2.com' using this sub-domain like https://example2.example.com/serviceworker.js and https://example2.example.com/main.js but it is giving me error like:
SecurityError: The operation is insecure.
I have two questions from this conditions:
Is it possible to register service worker hosted on different domain ?
If possible then why is it giving me this error and how to do it ?
I am using only javascript to avoid any dependency.
Thank you in advance!
Their is one tricky way to register service worker cross-domain and almost every website doing so is by this way. You can register it by using pop-up window.Steps:
1.Create a new html page in your sub-domain directory and like https://example2.example.com/index.html2.Add your main.js in this index.html page.3.Now instead of loading main.js in https://example2.com open pop window with link https://example2.example.com/index.html
Once your service worker registered, their will be no domain dependency and you can do whatever you want to with this. In this way you can register service worker without redirecting.
If a service worker is associated to a web page, does it inherit its permissions (for example to show notifications)? Could I use a service worker to create notification?
In general it seems that service worker inherits page permissions, and you can use a service worker to create notifications, if your page has received permissions for that. On the other hand not everything is available to the service worker API. For example, Geolocation access has been proposed, but is apparently not yet available. So you'll have to look at things case-by-case.
Notifications are indeed one of the best use cases for service worker, since your service worker, once registered, can actually create notifications even if your page is not open in the user's browser. Here is an tutorial for push notifications with service workers in Chrome. You could also create notifications normally without the whole push part though. Just keep in mind that your service worker needs to be woken up by some event or other in order to do anything.