A Desktop-Agnostic Way to Change DNS Server

Editing ‘/etc/parse.conf’ is not recommended any more because the content will be reset after restart.

Open a terminal window and go to the Network Manager connections profile directory.

cd /etc/NetworkManager/system-connections/

Then list connection names available on your system.


As you can see, I have several connections on my system, one of which is wired connection. Some are wireless connections and one is VPN connection. Because my desktop computer is connected to my router via an Ethernet cable, so I need to edit the wired connection profile with the nano command line text editor.

sudo nano 'Wired connection 1'

If your computer is connected via Wi-fi, then you need to edit the wireless connection profile. In this file, find the [ipv4] configurations. By default, it should look like this:


To make your system use, change the configurations to the following.


To save the file in Nano text editor, press Ctrl+O, then press Enter to confirm. Press Ctrl+X to exit. Then restart Network Manager for the changes to take effect.

sudo systemctl restart NetworkManager
You can now check your current DNS server by running the following command:

systemd-resolve --status

Sample output:

Link 2 (enp5s0)
Current Scopes: DNS
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers:

via: https://www.linuxbabe.com/ubuntu/ubuntu-stubby-dns-over-tls

Stop trying to use JWT unnecessarily

JWT is a very common authentication method. Some people say you should never use it, while others say it’s amazing. Today, I just want to talk about the disadvantages and why using JWT in web applications is not always a good idea.

via: Why JWTs Suck as Session Tokens

How are People Using JWTs Today?

How People Use JWTs

When that user visits another page on the website, for instance, their browser will automatically send that JWT to the server, which will validate the JWT to make sure that it’s the same token it created originally, then let the user do stuff.

In theory, this sounds nice because:

  • When the server receives a JWT, it can validate that it is legitimate and trust that the user is whoever the token says they are
  • The server can validate this token locally without making any network requests, talking to a database, etc. This can potentially make session management faster because instead of needing to load the user from a database (or cache) on every request, you just need to run a small bit of local code. This is probably the single biggest reason people like using JWTs: they are stateless.

These two perks sound great because they will speed up webapp performance, reduce load on cache servers and database servers, and generally provide faster experiences.

As a bonus benefit, as the webapp creator you can embed other information about the user into your JWT:

  • User permissions
  • User personal information
  • Etc.

This means that you can reduce your database load even further by simply embedding extra user information in your tokens as well!

Why Do JWTs Suck?

Rage Face Sketch

Now that we’ve seen how JWTs are used for authentication purposes, let’s get into my favorite subject of all: why JWTs are not good session tokens.

I often argue with coworkers, colleagues, and friends about this, so it’s nice to finally get all my thoughts on the subject down in bytes.

In particular, I plan to explain to you why normal old sessions are superior to JWTs in almost every way.


Before I start making web developers all over the world angry, I want to provide some context into my reasoning.

Most websites that developers build are relatively simple:

  • A user registers for the website
  • A user signs into the website
  • A user clicks around and does stuff
  • The website uses the user’s information to create, update, and delete information

99.9% of all websites match the criteria above.

For these types of websites, what’s important to know is that almost every page a user interacts with contains some sort of dynamic data. Odds are, if you’re running a website that requires a user to sign in to use it, you’re going to be doing things with that user in your database often:

  • Recording the actions a user is taking
  • Adding some data for the user to the database
  • Checking a user’s permissions to see if they can do something
  • Etc.

The important thing to remember is that most sites require user information for nearly every operation.

With that out of the way, let’s get into the reasons why JWTs suck. First up? Size.

You’re Going to Hit the Database Anyway

As I mentioned above, most websites that require user login are primarily generating dynamic user content for CRUD operations (create, update, delete).

CRUD Websites

The issue with using JWTs on these websites is that for almost every single page the user loads, the user object needs to be loaded from a cache / database because one of the following situations are occurring:

  • A mission critical user check needs to run (eg: does this user have enough money in their account to complete the transaction?)
  • A database write needs to occur to persist information (if this information is related to the user, it’s likely that the full user object must also be retrieved from the database)
  • The full user object must be pulled out of the cache / database so that the website can properly generate its dynamic page content

Think about the websites you build. Do they often manipulate user data? Do they frequently use various fields on the user account to work? If so, your site falls into this category, and you’ll likely be talking to the cache server / database regardless of whether or not you’ve got a JWT.

This means that on most websites, the stateless benefits of a JWT are not being taken advantage of.

To compound this issue, since JWTs are larger (in bytes) and also require CPU to compute cryptographic signatures, they’re actually significantly slower than traditional sessions when used in this manner.

Almost every web framework loads the user on every incoming request. This includes frameworks like Django, Rails, Express.js (if you’re using an authentication library), etc. This means that even for sites that are primarily stateless, the web framework you’re using is still loading the user object regardless.

Finally: if you’re storing your user information in a modern cache like memcached/redis, it’s not uncommon over a VPC to achieve cache GET times of 5ms or below, which is extremely fast. I’ve personally used DynamoDB on Amazon in the past as a session store, and consistently achieved 1ms cache retrieval times. Because caching systems are so fast, there’s very little performance overhead when retrieving users in this manner.

Redundant Signing

One of the main selling points of JWTs are cryptographic signatures. Because JWTs are cryptographically signed, a receiving party can verify that the JWT is valid, and trusted.

But… what would you say if I told you that in pretty much every single web framework created over the last 20 years, you could also get the benefits of cryptographic signatures when using plain old session cookies?

Well, you can =)

Most web frameworks cryptographically sign (and many encrypt!) your cookies for you automatically. This means that you get the exact same benefits as using JWT signatures without using JWTs themselves.

In fact, in most web authentication cases, the JWT data is stored in a session cookie anyways, meaning that there are now two levels of signing. One on the cookie itself, and one on the JWT.

While having two levels of signing may sound like a good idea, it is not. You get no security benefits, and you’ve now got to spend twice as long on CPU cycles to validate both signatures. Not really ideal for web environments where milliseconds are important. This is especially true in single threaded environments (cough cough nodejs) where number crunching can block your main event loop.

What’s a Better Solution?

If JWTs suck, then what’s a better solution? Plain old sessions!

Session ID vs JWT

If you’re building a simple website like the ones described above, then your best bet is to stick with boring, simple, and secure server side sessions. Instead of storing a user ID inside of a JWT, then storing a JWT inside of a cookie: just store the user ID directly inside of the cookie and be done with it.

If your website is popular and has many users, cache your sessions in a backend like memcached or redis, and you can easily scale your service with very little hassle.

Excellent quality web frameworks like Django know this, which is why they operate this way.

How Should I Use JWTs?

It’s important to note that I don’t hate JWTs. I just think they’re useless for a majority of websites. With that said, however, there are several cases in which JWTs can be useful.

If you’re building API services that need to support server-to-server or client-to-server (like a mobile app or single page app (SPA)) communication, using JWTs as your API tokens is a very smart idea. In this scenario:

  • You will have an authentication API which clients authenticate against, and get back a JWT
  • Clients then use this JWT to send authenticated requests to other API services
  • These other API services use the client’s JWT to validate the client is trusted and can perform some action without needing to perform a network validation

JWTs in Microservices

For these types of API services, JWTs make perfect sense because clients will be making requests frequently, with limited scope, and usually authentication data can be persisted in a stateless way without too much dependence on user data.

If you’re building any type of service where you need three or more parties involved in a request, JWTs can also be useful. In this case the requesting party will have a token to prove their identity, and can forward it to the third (or 4th … nth) service without needing to incur a real-time validation each and every time.

Finally: if you’re using user federation (things like single sign-on and OpenID Connect), JWTs become important because you need a way to validate a user’s identity via a third party. Thanks to cryptographic signing, JWTs make a valuable addition to federated user protocols.

Wrap Up

When you start building your next website, just rely on your web framework’s default authentication libraries and tools, and stop trying to shove JWTs into the mix unnecessarily.

Cordova: get 404 error for the all ajax request on Android device

The app build with cordova is installed on an Android device, all ajax requests are 404(NotFound). But debugging in chrome works fine. This problem can be solved by reinstalling cordova-plugin-whitelist

remove: cordova plugin remove cordova-plugin-whitelist

reinstall: cordova plugin add cordova-plugin-whitelist

DNS over Https(DOH)

DNS over HTTPS (DoH) is a protocol for performing remote Domain Name System (DNS) resolution via the HTTPS protocol. A goal of the method is to increase user privacy and security by preventing eavesdropping and manipulation of DNS data by man-in-the-middle attacks by using the HTTPS protocol to encrypt the data between the DoH client and the DoH-based DNS resolver.

Stubby is an open-source DNS stub resolver developed by the getdns team. A stub resolver is a small DNS client on the end-user’s computer that receives DNS requests from applications such as Firefox and forward requests to a recursive resolver like or Stubby is special in that it supports DNS over TLS. By default, it will only send DNS requests encrypted.

Install Stubby

Stubby is in Ubuntu 18.04 repository. Open up a terminal window and run the following command to install it.

sudo apt install stubby

Once you install it successfully, it will run in the background in the form of service. The default listening port of the software is 53.
Check whether the startup is successful:

sudo netstat -lnptu | grep stubby

The main configuration file is /etc/stubby/stubby.yml. generally, it does not need to be changed..

Switching to Stubby

Edite the /etc/resolve.conf file to change nameserver to


via: https://www.linuxbabe.com/ubuntu/ubuntu-stubby-dns-over-tls

Install pymssql for Mac OS

  1. Install Python runtime and pip package manager
    a. Go to python.org
    b. Click on the appropriate Mac installer pkg link.
    c. Once downloaded run the pkg to install Python runtime

  2. Open terminal

  3. Install Homebrew package manager

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"  
  1. Install FreeTDS module
brew install FreeTDS  
  1. Install pymssql module

I’ve been looking for this method all day, ‘sudo – H’ is a required:

sudo -H pip install pymssql

via: https://docs.microsoft.com/en-us/sql/connect/python/pymssql/step-1-configure-development-environment-for-pymssql-python-development?view=sql-server-ver15

Install .dmg Application use command line

Because I used to be a Linux user, I’m not very suitable for the way of dragging and installing the application on the MAC system. Here is a demonstration of using the command line installer to install Baidu online disk:

hdiutil attach BaiduNetdisk_mac_3.0.5.4.dmg


cp -r /Volumes/百度网盘/BaiduNetdisk_mac.app  /Applications

Then have the application in /Applications folder
Don’t forget to unmount:

hdiutil unmount /Volumes/百度网盘

Full log:

  tools hdiutil attach BaiduNetdisk_mac_3.0.5.4.dmg 
Checksumming Protective Master Boot Record (MBR : 0)…
Protective Master Boot Record (MBR :: verified   CRC32 $59FE27A2
Checksumming GPT Header (Primary GPT Header : 1)…
 GPT Header (Primary GPT Header : 1): verified   CRC32 $233AC4FB
Checksumming GPT Partition Data (Primary GPT Table : 2)…
GPT Partition Data (Primary GPT Tabl: verified   CRC32 $6B594661
Checksumming  (Apple_Free : 3)…
                    (Apple_Free : 3): verified   CRC32 $00000000
disk image (Apple_HFS : 4): verified   CRC32 $1596394B
Checksumming GPT Partition Data (Backup GPT Table : 5)…
GPT Partition Data (Backup GPT Table: verified   CRC32 $6B594661
Checksumming GPT Header (Backup GPT Header : 6)…
  GPT Header (Backup GPT Header : 6): verified   CRC32 $637DD144
verified   CRC32 $3F4FAA8A
/dev/disk2              GUID_partition_scheme          
/dev/disk2s1            Apple_HFS                       /Volumes/百度网盘
➜  tools cp -r /Volumes/百度网盘/BaiduNetdisk_mac.app  /Applications 
➜  tools hdiutil unmount /Volumes/百度网盘 
"/Volumes/百度网盘" unmounted successfully.