Research
Security News
Malicious npm Packages Inject SSH Backdoors via Typosquatted Libraries
Socket’s threat research team has detected six malicious npm packages typosquatting popular libraries to insert SSH backdoors.
DSW allows you to enable and use Service Workers in a much easier way, also helping you to create and maintain your Progressive Web Apps working offline.
You will simply have to create setup in a JSON file how your service worker is supposed to deal with requests. Read the commented JSON example or the documentation and examples below.
It's node program which you may install globally:
npm install -g dsw
Or locally:
npm install dsw --save-dev
Want simply to see it working as fast as possible?
Clone the project, go to its directory, install it and run npm run try
DSW will look for a file called dswfile.json
. So:
cd path-to-your-project
touch dswfile.json
You will use your prefered editor to make changes to this file later.
And now, you will add this to your index.html
file, like so, in the head
element:
<link rel="manifest" href="/webapp-manifest.json" />
<meta name="theme-color" content="#color">
<script src="dsw.js"></script>
<script>
DSW.setup()
.then(function(){
// inform the user your page works offline, now!
})
.catch(function(){
// do something if the page will not work offline
// or if the current browser does not support it
});
</script>
Done! Now, for any change in your Dynamic Service Worker configuration, just run again the dsw
command line on your project.
This will create the manifest
(if not there, already) and the dsw.js
file.
To do so, if you installed it globally:
dsw path-to-your-project
If you installed locally, though:
node node_modules/dsw/ path-to-your-project
This second example is specially useful if you intend to run it in a stand alone project or want to trigger it using a script in your package.json
file.
From now on, let's work as if you had installed it globally in our examples.
You will notice a dsw.js
file that has been created in your project's root path.
Now, let's set up your project's offline configuration.
When you change something in your dswfile.json
, you shall re-execute the command above.
Open the dswfile.json
in the root of your project and let's add some content like this:
{
"dswVersion": 2.2,
"applyImmediately": true,
"dswRules": {
"yourRuleName": {
"match": { },
"apply": { }
}
}
}
That's it! You may have many rules.
Reminding that applyImmediately
is optional. It will replace the previously registered service worker as soon as the new one loads.
The match
property accepts:
The apply
property for each rule is used when a request matches the match
requirements.
It may be:
DSW will treat the cache layer for you.
Pass to the cache object in your apply definition, an object containing:
You can also define cache: false
. This will force the request not to be cached.
Seens silly, but is useful when you want an exception for your cached data.
Using both match
and apply
, we can for do a lot of things.
Don't forget to re-run dsw path-to-project
whenever you made a change to your dswfile.js
file.
Add this to your dswfile.js
:
{
"dswVersion": 2.2,
"dswRules": {
"notFoundPages": {
"match": {
"status": [404],
"extension": ["html"]
},
"apply": {
"fetch": "/my-404-page.html"
}
}
}
}
Create a my-404-page.html
with any content.
Now, access in your browser, first, the index.html
file(so the service worker will be installed), then any url replacing the index.html
string, and you will see your my-404-page.html
instead.
Let's see an example of requests being cached:
{
"dswVersion": 2.2,
"dswRules": {
"myCachedImages": {
"match": {
"extension": ["png", "jpg", "gif"]
},
"apply": {
"cache": {
"name": "my-cached-images",
"version": 1
}
}
}
}
}
Let's see an example of requests being cached for all images except one specific image:
{
"dswVersion": 2.2,
"dswRules": {
"myNotCachedImage": {
"match": {
"path": "\/images\/some-specific-image"
},
"apply": {
"cache": false
}
},
"myCachedImages": {
"match": {
"extension": ["png", "jpg", "gif"]
},
"apply": {
"cache": {
"name": "my-cached-images",
"version": 1
}
}
}
}
}
You may want to redirect requests some times, like so:
{
"dswVersion": 2.2,
"dswRules": {
"secretPath": {
"match": {
"path": "\/private\/"
},
"apply": {
"redirect": "/not-allowed.html"
}
}
}
}
Maybe you want to cache everything. Every single request (that is successful) will be cached as soon as it is loaded the first time:
{
"dswVersion": 2.2,
"dswRules": {
"secretPath": {
"match": {
"path": "\/.*"
},
"apply": {
"cache": {
"name": "cached-files"
"version": 1
}
}
}
}
}
Most of times you will want to cache all your static files, like javascript files or css:
{
"dswVersion": 2.2,
"dswRules": {
"secretPath": {
"match": {
"extension": ["js", "css"]
},
"apply": {
"cache": {
"name": "page-static-files"
"version": 1
}
}
}
}
}
So, you want to contribute? Cool! We need it! :)
Here is how...and yep, as Service workers are still a little too new, it is a little bit weird! Here is how I've been doing this, and if you have any better suggestion, please let me know :)
1 - Clone the project
git clone https://github.com/NascHQ/dsw
2 - Enter the project directory
cd dsw
3 - Start watching it
npm run watch
4 - Use the sandbox to test it (run this command in another terminal window or tab, so the watch command can continue running)
npm run try
5 - Access in the browser, the address in the right port, as provided by the previous command, something like:
http://localhost:8888/
Please notice we use eslint
to validate the code styles. You can see the rules in the .eslintrc.js
file.
Whenever you change any files inside the src
directory, the watch will re-build it for you (wait until you see the "DONE" output).
This is automatic, but you stillneed to reload the try command in the other tab:
^C # ctrl+C to stop the previous try, and then...
npm run try
In the browser, though, you may face some boring situations, so, to make sure you will not fall into a trap debugging unchanged things, here goes some tips:
Go to the settings of your browser console and enable the "disable cache(when console is open)". This way, you will not be tricked by some unwanted caches.
Go to the "Application" tab in your console (in chrome, it is in canary by now) and:
1 - Click in "Service workers"
2 - Mark the box "Show All" (and when there is more than one, you may click in "Unregister")
3 - You can also check the box "Update on reload" to keep the latest service worker in command.
4 - When you want to test how things are working offline, simply check the "Offline" box.
5 - You can use the "Cache Storage" in the left panel to verify everything that has been cached.
6 - You can use the Lighthouse to validate the service worker situation: Lighthouse
If you have an idea or suggestion, please let us know by creating an issue at DSW Github Project page.
FAQs
Dynamic Service Worker, offline Progressive Web Apps much easier
The npm package dsw receives a total of 21 weekly downloads. As such, dsw popularity was classified as not popular.
We found that dsw demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Research
Security News
Socket’s threat research team has detected six malicious npm packages typosquatting popular libraries to insert SSH backdoors.
Security News
MITRE's 2024 CWE Top 25 highlights critical software vulnerabilities like XSS, SQL Injection, and CSRF, reflecting shifts due to a refined ranking methodology.
Security News
In this segment of the Risky Business podcast, Feross Aboukhadijeh and Patrick Gray discuss the challenges of tracking malware discovered in open source softare.