Forem: Achraf Affes

JavaScript and the event queue!

Achraf Affes — Wed, 13 Oct 2021 18:23:45 +0000

So we all know the definition of JavaScript, it is a single threaded synchronous language.
This means it has one call stack and one memory heap, it executes code in order and must finish executing a piece of code before moving onto the next and hence the language is blocking in nature.

Again JavaScript is synchronous and single-threaded so if we execute a JavaScript block of code on a page then no other JavaScript code on that same page will parallelly be executed!

The definitions seems absurd, since we all use asynchronous stuff using JS or is it all an illusion?

so from the various resources I've read on this topic, here's what I understand:

JavaScript itself is synchronous but the browser makes it possible to code in an asynchronous way, How is that?

Well the answer is :

by using the Browser APIs, such as Fetch API, setTimeout, Promises, Geolocation API etc ..

Whenever an asynchronous function is called, it is sent to a browser API, these are APIs built into the browser.
Based on the commands received from the call stack, the API starts its own single-threaded operation.

An example of this is the setTimeout method.
When a setTimeout operation is processed in the call stack, it is sent to the corresponding API which waits till the specified time to send this operation back in for processing.
Where does it send the operation? The event queue.

The event loop constantly checks whether or not the call stack is empty, if it is empty, new functions are added from the event queue, if it is not, then the current function call is processed.

So lets dive deeper into the event queue itself.
To make sense out of all of this, we need to talk about some terminology first:

Tasks : any block of code (literally)

Browser APIs : APIs that usually start their own threads to run code parallelly ( most of them requires a callback which will later on be pushed to the event queue )

Micro Tasks : any callback related to a promise

rendering process : anything related to rendering such as style calculation, or any requestAnimationFrame callback

call stack : a mechanism for an interpreter to keep track of its place in a script that calls multiple functions ( what function is currently being run and what function initially called it ).

Heap : an area of pre-reserved computer main storage ( memory ) that a program process can use to store data

Thread : a sequence of programmed instructions that can be managed independently by a scheduler it got its own heap and stack.

Alright time to make sense of it all!
So we said that the main thread runs JavaScript synchronously, when we use some certain BrowserAPI when that command is executed in the stack a new thread is initiated that runs its code independently

Let’s take setTimeout as an example, the new thread will keep tracking sysTick till the X ms runs out, the new thread sends a message to the main Thread telling it to enqueue (push) its attached callback to the event queue, the event loop then waits till the call stack is empty to dequeue some callback into the stack, which will then be executed.

The Scheme explains it perfectly.
What is important to note is that not all callbacks got the same priority and the same order of execution or enqueueing.
A funny representation that I saw in JSconf presentation, describes the event loop as following:




while(true){
   var Queue = getNextQueue();
   var Task = queue.pop();
   Execute(task);

   while(microtaskQueue.hasTasks){
      doMicrotask();
   }

   if(isRepaintTime()){
      animationTasks = animationQueue.copyTasks();
      for ( task in animationTasks)
         doAnimationTask(task);
      repaint();
   }
}

MicroTasks as many sources explains them, are usually promises callbacks, please notice that when pushing them to the event queue we push the entire MicroTask queue, while when pushing Tasks we only push the first-in callback in the tasks queue.

We also push the entire render queue to the event queue when it's time to render ( usually browsers repaints the screen every 16/17ms since most of them runs with a frequency of 60Hz )
So a good practice is to use requestAnimationFrame to run animations rather than running it in simple tasks or microtasks, since its pointless to repaint it in higher frequency cause the the human eye can see between 30 and 60 frames per second (30/60Hz).

Another presentation in the JSConf visualizes the event loop as following

So as a conclusion:

The event loop is the secret behind JavaScript's asynchronous programming. JavaScript executes all operations on a single thread, but using a few smart data structures, it gives us the illusion of multi-threading, so describing JavaScript as asynchronous is arguably misleading.

I hope this made sense in anyway, if not I highly recommend you to check these presentations to watch, I guaranty you will understand it much better:

https://www.youtube.com/watch?v=cCOL7MC4Pl0

https://www.youtube.com/watch?v=8aGhZQkoFbQ&t=594s

https://www.youtube.com/watch?v=u1kqx6AenYw&t=861s

Please feel free to explain it in your own way in the comments section or to provide us with more links about the subject.
Thanks for reading.

JWT how does it work and is it secure?

Achraf Affes — Mon, 11 Oct 2021 20:48:57 +0000

JWT stands for JSON web token

the common definition says that it is an open industry standard RFC 7519 method for representing claims securely between two parties

so lets break it up into a simpler logic to understand its utility and the way it works!
So JWT was built by some developers in Microsoft, they built it initially for information exchange, and later on it was repurposed for authorization.

In security processes, authentication validates a user's identity, it also grants that user permission to access a resource.
JWT is a stateless session, so it does not need to be saved in a database in the server-side like cookies, it only exists in the client side.

A JWT is composed by :

header . payload . signature

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

The Header is the metadata about the token, its the result of

const base64Url = require("base64-url") 
// used for Base64 and URL Encoding Decoding 
const header = base64Url.encode(
  JSON.stringify({
    alg :"HS256", // algorithm : none, HS256, RS256, PS256 etc ..
    type :"JWT",
    ...
  })
);

//outputs : eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCJ9

please notice that it is not encrypted it's just encoded which means you can use base64 decode and you will get the JSON object in clear.

the payload contains the message we want to send alongside with different information about the token itself

const base64Url = require("base64-url") 
// used for Base64 and URL Encoding Decoding 
const header = base64Url.encode(
  JSON.stringify({ 
    sub:"1234567890", //subject
    iss:"Darken", //issuer
    aud:"My API", //audience used for auth as well 
    exp:1633895355, //expiration datetime
    iat:1633895235, //issued at datetime
    ...
  })
);
//outputs : eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9
//lIiwiaWF0IjoxNTE2MjM5MDIyfQ

Again it is not encrypted it's just encoded which means you can use base64 decode and you will get the JSON object in clear.
So far we are not securing information, so you may be wondering, how is this secure, and where is the authentication in all of this?
And that's where the signature plays it's role!

A signature is the result of some function that uses the header, the payload a secret key and hash function.
The secret key is the most important part, a good advice is to use a 256bit key and don't hard code it ( save it in process.env )
Please note that if we are using asymmetric encryption, when calculating the signature the algorithm uses both keys ( private and public )

So the signature is usually calculated like this :

const crypto = require("crypto") // cryptography library
const base64Url = require("base64-url") 
const secret = process.env.SECRET
//Again ! please use a 256bit secret key
const content = "${header}.${payload}"
//used for Base64 and URL Encoding Decoding 
const signature = base64Url.escape(
  crypto.createHmac('sha256',secret)
  .update(content)
  .digest('base64')
);
//outputs : SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Now this creates an HMAC encryption (Hash-based message authentication code) a cryptographic technique that combines the key and a hash into a mix hackers can't unpack.

So the authentication part shows up here! Have the content of this message been manipulated?

Remember that the token is equal to :

const token = "${header}.${payload}.${signature}"
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwib
mFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fw
pMeJf36POk6yJV_adQssw5c

Since the hacker can change the signature but can't guess the right signature( he doesn't know the secret key ) then when the attacker changes the payload or the header, the signature no longer matches the data.
So lets suppose the hacker decoded the payload and changed it to :

{
  "sub": "This was changed",
  "name": "AchrafAffes",
  "iat": 1516239022
}
//The payload encoded will then be changed to :
eyJzdWIiOiJUaGlzIHdhcyBjaGFuZ2VkIiwibmFtZSI6IkFjaHJhZkFmZmVzIiwiaW
F0IjoxNTE2MjM5MDIyfQ

And again! since the hacker can't guess the right signature for the new encoded payload ( no secret key ) then when the server decodes the header and the payload, and recalculates the new signature it will be : do3cSS2wLRUM6cmqVqvFZVpCwJkeO0BieF0h0oTWaBE
which is impossible for the hacker to guess unless he knows the secret key ( remember when using single symmetrical key to use a 256 bit key) and here the server will predict that the payload or the header were changed and therefore it will ignore the request.

Now that you understand how the JWT works, how do we use it in action ?

For me I use it as following, the user logs in, the server checks for the credentials whether this user coords exists or not, if it does, the server generates a token and sends it to the user ( the server does not save a copy ) the user then saves the token in its localstorage ( the token should have a short expiration datetime since it is vulnerable for XSS attacks which I'll explain in another post in the future )
Whenever the user wants to access something, it sends the token in its header, and the server verifies it, if its verified then the server responds else the server responds with a 403 Forbidden error.

In some other solutions, we implement an authentication server(AS), the user passes by the AS first and then it is redirected to the resource server (API) which will verify the token with each request.

If you are working with nodeJs you can use the jsonwebtoken package, to easily implement the JWT

var jwt = require('jsonwebtoken');
const secret = 'secretkey'
//please make sure to use a 265bit key
const data= {username:"achraf",other:"stuffHere"}

//to generate the data we use
let token = jwt.sign(
  data,
  secret, 
  {expiresIn : '2 min'} //other options can be used
);

//and to verify it you can use
jwt.verify(token,secret, function(err, tokendata){
    if(err){
        console.log("Unauthorized request")
    }
    if(tokendata){
        console.log("verified")
    }
})

so lets talk quickly about the most recommended algorithms that can be used :

HS256 : HMAC + SHA-265
(relies on the shared symmetrical key)

RS256 / RSASSA + SHA-256
(relies on private/public RSA key pair, but it may overload the network and uses more CPU for calculation )

ES256 : ECDSA using p-265 and SHA-265
(relies on private/public RSA key pair but much shorter )

I'll try to talk about these algorithms in details in the future

finally I wanna talk about the difference between cookies and JWT:

Cookies need to be stored on the server-side while JWT are stateless

since cookies require a database, this database will be queried on each client request

cookies are vulnerable for both CSRF and XSS attacks, while JWT is only vulnerable to XSS attack.

DHCP and static IPs ??

Achraf Affes — Sat, 02 Oct 2021 23:07:16 +0000

I'm not gonna talk about how does a DHCP server work exactly,
this Post is destined for those who understands that already but still got some dark spots with their knowledge about the topic,
this is simply an explanation for the famous problem :

If one of the devices in the network is configured with a static IP address, when the DHCP server starts distributing the IP addresses to other machines, what happens exactly ? does it skip it ? or does it duplicate it and therefore there would be a conflict ?

So the answer is, NOPE the DHCP server will not distribute that IP address, you may be wondering, but how ?

Remember that the DHCP server sends an ARP Broadcast asking about the IP address about to be distributed

"Who has x.x.x.x"

At that moment the machine with that static IP address will respond with an ARP saying that it got that IP and that its MAC address is X:X:X:X:X:X so the DHCP server will continue to the next IP address asking "Who has y.y.y.y"
and therefore there will be no duplication.

But here comes another problem,

what if the local network is placed behind a router, and we all know that the routers doesn't allow broadcasting, then what happens ?

well simply instead of ARP Broadcasting, it uses ICMP Packet type 8 code 0 which is the ECHO request ( ping ) and if it gets no answer than it distributes it, else it simply continues to the next IP address.

And here comes the last question,

And what if a device that is configured with a static IP address was shutdown, and the DHCP distributed its IP address, what happens if the machine is up again?

well there are two solutions for this, some DHCP servers are advanced enough and caches the static IP address and therefore this conflict will never occurs, but if the DHCP server doesn't provide this feature, than it should be configured to exclude these IP addresses or else there will be an IP Duplication.

And this pretty much sums up the main problems of dealing with a DHCP server.