The authentication or login process is similar to the registration process. Using the JavaScript libraries, the authenticator passes identifying information to the relying party. The relying party returns a challenge, which should be validated by the user, processed by the authenticator, and finally validated by the relying party. User verification is checked from the options, but a majority of the options have been reduced as no credentials are generated or saved on either end.
\nSetting up WebAuthn for your Application
\nWhen setting up WebAuthn as an authentication method for your application, two considerations are to use the standard as a primary registration and authentication method or as a second-factor authentication method.
\nAs a primary authentication method, the authenticator identification and credentials are stored by the server at the same time the user account is created.
\nTo begin, use the Web Authentication API to initiate the flow:
\nLet publicKeyCredentialCreationOptions = {\n user: {\n id: “1234”,\n name: "example@example.com",\n displayName: "example",\n },\n authenticatorSelection: {\n authenticatorAttachment: "platform",\n },\n attestation: "direct"\n};\n\nconst credential = await navigator.credentials.create({\n publicKey: publicKeyCredentialCreationOptions\n});For this section, the creation options are generated by the client. In other scenarios, including this blog's example, the options are generated from the relying party by retrieving them via an API call.
\nAfter the browser triggers this code, the authenticator will be prompted for validation. Since the authenticatorAttachment is set to 'platform', it would use the device's authenticator, like Windows Hello or an Android fingerprint scan.
\nThe data returned from the creation of the credentials will have a structure like this:
\nPublicKeyCredential {\n id: 'ADSUllKQmbqdGtpu4sjseh4cg2TxSvrbcHDTBsv4NSSX9...',\n rawId: ArrayBuffer(59),\n response: AuthenticatorAttestationResponse {\n clientDataJSON: ArrayBuffer(121),\n attestationObject: ArrayBuffer(306),\n },\n type: 'public-key'\n}This object should be passed to the relying party to complete the registration. The relying party verifies that the credentials passed in are correct and stores the identifier and credentials in the data store. In addition to storing the credentials object, any other registration variables should be passed in this step to register on your data store.
\nTo use this flow as part of a second-factor authentication process, the user account should be created before initiating this process with an already existing authentication method, like a password system. After the user account is created, running this flow should update the current user in the data store with the credential data. This will allow the second-factor authentication credentials to be configured and triggered after a password login.
\nMost programming languages have a library built that supports WebAuthn for a relying party server. For example, Duo has created them for Python and Go. Using one of these libraries during the development of the relying party server will simplify the process. These resources also provide demos on how to implement their libraries to handle the credential data generated by the JavaScript Web Authentication APIs.
Conclusion
\nAlthough the usage of WebAuthn is not widespread at the moment, the potential to authenticate a user passwordless or with the extra security of an authenticator allows it to be a strong contender in the future over regular password authentication flows. Hopefully, this blog helps you get started on your authentication apps with WebAuthn.
\n","frontmatter":{"date":"December 09, 2020","updated_date":null,"description":"Web authentication, or WebAuthn in short. A go-to guide for developers to learn more about WebAuthn API, and how to set it up in their services..","title":"WebAuthn: A Guide To Authenticate Your Application","tags":["WebAuthn","FIDO","Authentication"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/07ab3c5a163821d532aedbc23c7a48be/ee604/webauthn-logo.png","srcSet":"/static/07ab3c5a163821d532aedbc23c7a48be/69585/webauthn-logo.png 200w,\n/static/07ab3c5a163821d532aedbc23c7a48be/497c6/webauthn-logo.png 400w,\n/static/07ab3c5a163821d532aedbc23c7a48be/ee604/webauthn-logo.png 800w,\n/static/07ab3c5a163821d532aedbc23c7a48be/f3583/webauthn-logo.png 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Chris Yee","github":null,"avatar":null}}}},{"node":{"excerpt":"Let's walk through how to build and push Docker images programmatically using Go. To do this, we need to talk to the Docker daemon via the…","fields":{"slug":"/engineering/build-push-docker-images-golang/"},"html":"Let's walk through how to build and push Docker images programmatically using Go. To do this, we need to talk to the Docker daemon via the Docker Engine API. This is similar to how the Docker CLI works, but instead of entering commands through a CLI, we'll be writing code with Docker's Go SDK.
\nAt the time of writing, the official Docker Go SDK docs provide great examples of running basic Docker commands with Go. However, it's missing examples on building and pushing Docker images, so we'll go over those in this blog.
\nBefore we begin, this blog assumes you have a working knowledge of Docker and Go. We'll go over the following:
\n- \n
- Building an image from local source code \n
- Pushing an image to a remote registry \n
Environment Setup
\nFirst, we need to set up the environment. Create a project and include the app we want to containerize:
\nmkdir docker-go-tutorial && cd docker-go-tutorial && mkdir node-helloWe'll add a simple Node.js app:
\n// node-hello/app.js\nconsole.log("Hello From LoginRadius");with the Dockerfile:
\n// node-hello/Dockerfile\nFROM node:12\nWORKDIR /src\nCOPY . .\nCMD [ "node", "app.js" ]Next, install the Go SDK. These are the Docker related imports we will be using:
\n"github.com/docker/docker/api/types"\n"github.com/docker/docker/client"\n"github.com/docker/docker/pkg/archive"Build Docker Image
\nOne way to build a Docker image from our local files is to compress those files into a tar archive first.
\nWe use the archive package provided by Docker:
\n"github.com/docker/docker/pkg/archive"tar, err := archive.TarWithOptions("node-hello/", &archive.TarOptions{})\nif err != nil {\n return err\n}Now, we can call the ImageBuild function using the Go SDK:
\n- \n
- \n
Note that the image tag includes our Docker registry user ID, so we can push this image to our registry later.
\n
\nopts := types.ImageBuildOptions{\nDockerfile: "Dockerfile",\nTags: []string{dockerRegistryUserID + "/node-hello"},\nRemove: true,\n}\nres, err := dockerClient.ImageBuild(ctx, tar, opts)\nif err != nil {\nreturn err\n}\n
To print the response, we use a scanner to go through line by line:
\nscanner := bufio.NewScanner(res.Body)\nfor scanner.Scan() {\n lastLine = scanner.Text()\n fmt.Println(scanner.Text())\n}This prints the following:
\n{"stream":"Step 1/4 : FROM node:12"}\n{"stream":"\\n"}\n{"stream":" ---\\u003e e4f1e16b3633\\n"}\n{"stream":"Step 2/4 : WORKDIR /src"}\n{"stream":"\\n"}\n{"stream":" ---\\u003e Using cache\\n"}\n{"stream":" ---\\u003e b298b8519669\\n"}\n{"stream":"Step 3/4 : COPY . ."}\n{"stream":"\\n"}\n{"stream":" ---\\u003e Using cache\\n"}\n{"stream":" ---\\u003e 1ff6a87e79d9\\n"}\n{"stream":"Step 4/4 : CMD [ \\"node\\", \\"app.js\\" ]"}\n{"stream":"\\n"}\n{"stream":" ---\\u003e Using cache\\n"}\n{"stream":" ---\\u003e 6ca44f72b68d\\n"}\n{"aux":{"ID":"sha256:238a923459uf28h80103eb089804a2ff2c1f68f8c"}}\n{"stream":"Successfully built 6ca44f72b68d\\n"}\n{"stream":"Successfully tagged lrblake/node-hello:latest\\n"}The last step would be checking the response for errors, so if something went wrong during the build, we could handle it.
\nerrLine := &ErrorLine{}\njson.Unmarshal([]byte(lastLine), errLine)\nif errLine.Error != "" {\n return errors.New(errLine.Error)\n}For example, the following error can occur during build:
\n{"errorDetail":{"message":"COPY failed: stat /var/lib/docker/tmp/docker-builder887191115/z: no such file or directory"},"error":"COPY failed: stat /var/lib/docker/tmp/docker-builder887191115/z: no such file or directory"}All together, the file looks like this:
\npackage main\n\nimport (\n\t"bufio"\n\t"context"\n\t"encoding/json"\n\t"errors"\n\t"fmt"\n\t"io"\n\t"time"\n\n\t"github.com/docker/docker/api/types"\n\t"github.com/docker/docker/client"\n\t"github.com/docker/docker/pkg/archive"\n)\n\nvar dockerRegistryUserID = ""\n\ntype ErrorLine struct {\n\tError string `json:"error"`\n\tErrorDetail ErrorDetail `json:"errorDetail"`\n}\n\ntype ErrorDetail struct {\n\tMessage string `json:"message"`\n}\n\nfunc main() {\n\tcli, err := client.NewClientWithOpts(client.FromEnv, client.WithAPIVersionNegotiation())\n\tif err != nil {\n\t\tfmt.Println(err.Error())\n\t\treturn\n\t}\n\n\terr = imageBuild(cli)\n\tif err != nil {\n\t\tfmt.Println(err.Error())\n\t\treturn\n\t}\n}\n\nfunc imageBuild(dockerClient *client.Client) error {\n\tctx, cancel := context.WithTimeout(context.Background(), time.Second*120)\n\tdefer cancel()\n\n\ttar, err := archive.TarWithOptions("node-hello/", &archive.TarOptions{})\n\tif err != nil {\n\t\treturn err\n\t}\n\n\topts := types.ImageBuildOptions{\n\t\tDockerfile: "Dockerfile",\n\t\tTags: []string{dockerRegistryUserID + "/node-hello"},\n\t\tRemove: true,\n\t}\n\tres, err := dockerClient.ImageBuild(ctx, tar, opts)\n\tif err != nil {\n\t\treturn err\n\t}\n\n\tdefer res.Body.Close()\n\n\terr = print(res.Body)\n\tif err != nil {\n\t\treturn err\n\t}\n\n\treturn nil\n}\n\nfunc print(rd io.Reader) error {\n\tvar lastLine string\n\n\tscanner := bufio.NewScanner(rd)\n\tfor scanner.Scan() {\n\t\tlastLine = scanner.Text()\n\t\tfmt.Println(scanner.Text())\n\t}\n\n\terrLine := &ErrorLine{}\n\tjson.Unmarshal([]byte(lastLine), errLine)\n\tif errLine.Error != "" {\n\t\treturn errors.New(errLine.Error)\n\t}\n\n\tif err := scanner.Err(); err != nil {\n\t\treturn err\n\t}\n\n\treturn nil\n}The equivalent Docker CLI command would be:
\ndocker build -t <dockerRegistryUserID>/node-hello .Push Docker Image
\nWe'll push the Docker image we created to Docker Hub. But, we need to authenticate with Docker Hub by providing credentials encoded in base64.
\n- \n
- In practice, don't hardcode your credentials in your source code. \n
- \n
If you don't want to use your Docker Hub password, you can set up an access token and provide that in the Password field instead.
\n
\nvar authConfig = types.AuthConfig{\nUsername: "Your Docker Hub Username",\nPassword: "Your Docker Hub Password or Access Token",\nServerAddress: "https://index.docker.io/v1/",\n}\nauthConfigBytes, _ := json.Marshal(authConfig)\nauthConfigEncoded := base64.URLEncoding.EncodeToString(authConfigBytes)\n
Now, call the ImagePush function in the Go SDK, along with your encoded credentials:
\nopts := types.ImagePushOptions{RegistryAuth: authConfigEncoded}\nrd, err := dockerClient.ImagePush(ctx, dockerRegistryUserID + "/node-hello", opts)Together, this looks like:
\nfunc imagePush(dockerClient *client.Client) error {\n\tctx, cancel := context.WithTimeout(context.Background(), time.Second*120)\n\tdefer cancel()\n\n\tauthConfigBytes, _ := json.Marshal(authConfig)\n\tauthConfigEncoded := base64.URLEncoding.EncodeToString(authConfigBytes)\n\n\ttag := dockerRegistryUserID + "/node-hello"\n\topts := types.ImagePushOptions{RegistryAuth: authConfigEncoded}\n\trd, err := dockerClient.ImagePush(ctx, tag, opts)\n\tif err != nil {\n\t\treturn err\n\t}\n\n\tdefer rd.Close()\n\n\terr = print(rd)\n\tif err != nil {\n\t\treturn err\n\t}\n\n\treturn nil\n}The equivalent Docker CLI command (after docker login) would be:
\ndocker push <dockerRegistryUserID>/node-helloWhat is Istio?
\nIstio is an Open Source service mesh (developed in partnership between teams from Google, IBM, and Lyft), providing a dedicated infrastructure layer for creating service-to-service communication that is safe, fast, and reliable. Having such a fanatical communication layer can provide various advantages, like providing observability into communications, providing secure connections, or automating retries and backoff for failed requests.
\nA service mesh also often has more complex operational requirements, like A/B testing, canary rollouts, rate limiting, access control, and end-to-end authentication.
\nIstio does this by adding a sidecar proxy which intercepts all network communication between microservices, then configures and manages Istio using its control plane functionality, which incorporates:
\n- \n
- Granular control over the service-to-service communication and its routing with the additional functionality of retries, fault injection, circuit breakers. \n
- Providing secure mTLS without any changes in the application code. \n
- Cluster to cluster communication using ingress and egress gateways. \n
Istio Architecture
\nAn Istio service mesh is logically split into a data plane and a control plane.
\nThe data plane is composed of Envoy proxy deployed as sidecars. Envoy itself is an L7 proxy and communication bus designed for modern microservices-based architecture. These proxies intercept and control all network communication between microservices. They also collect and report telemetry on all mesh traffic.
\nThe control plane manages and configures the proxies to route traffic.
\n![\"Istio](\"https://istio.io/latest/docs/ops/deployment/architecture/arch.svg\")
Istio Core Components
\nPilot
\nIstio Pilot manages and configures all the Envoy proxy instances deployed. It takes the rules for traffic behavior provided by the control plane and converts them into configurations applied by Envoy.
\nCitadel
\nResponsible for controlling the authentication and identity management between services. Allow developers to build a zero-trust network based on service identity.
\nMixer
\nResponsible for enforcing access control and usage policies across the service mesh and collects telemetry data from the Envoy proxy and other services.
\nIstio Features
\nTraffic Management
\nIt is the basic feature of Istio, which facilitates the routing between services. Istio simplifies the configuration of service-level properties like circuit breakers, timeouts, and retries.\nAll traffic that your mesh services send and receive (data plane traffic) is proxied through Envoy, making it easy to direct and control traffic around your mesh without making any changes to your services.
\nFor discovering all the services in the ecosystem, Istio connects to the Service discovery System and populates its service registry. The Envoy sidecar proxy then uses this registry to route traffic to the correct service.
\nHere are a few resources you can add for your deployment apart from the basic service discovery and load balancing:
\nVirtual Services
\nVirtual services play a key role in making Istio's traffic management flexible and powerful. They do this by strongly decoupling where clients send their requests from the destination workloads that actually implement them.
\nSo, instead of sending requests directly to a service data plane, you send traffic through this virtual service. Using virtual service, you can route requests to different versions of the same service or different hostnames based on particular endpoints. This helps us to do various other things like A/B testing or doing canary rollouts.
A typical example:
\napiVersion: networking.istio.io/v1alpha3\nkind: VirtualService\nmetadata:\n name: bookinfo\nspec:\n hosts:\n - bookinfo.com\n http:\n - match:\n - uri:\n prefix: /reviews\n route:\n - destination:\n host: reviews <-- Resolves to reviews.<namespace>.svc.cluster.local\n - match:\n - uri:\n prefix: /ratings\n route:\n - destination:\n host: ratingsDestination Rule
\nWe use destination rules to configure what happens to traffic for that destination. Destination rules are applied after virtual service routing rules are evaluated, so they apply to the traffic's real destination.
\nUsing destination rules, we specify the subsets of the service using labels, which are then used by the virtual service to route requests to a particular subset. In addition to that, we can also customize traffic policy, load balancing policy, connection pool settings, mTLS, etc.
apiVersion: networking.istio.io/v1alpha3\nkind: DestinationRule\nmetadata:\n name: my-destination-rule\nspec:\n host: my-svc\n trafficPolicy:\n loadBalancer:\n simple: RANDOM\n subsets:\n #### This will work only if we have defined version label in the deployment\n - name: v1\n labels:\n version: v1\n - name: v2\n labels:\n version: v2\n trafficPolicy:\n loadBalancer:\n simple: ROUND_ROBIN\n - name: v3\n labels:\n version: v3Here we have defined destination rule for service my-svc and defined subsets and traffic policy global and per subset.
\nGateway
\nIt is used to manage inbound and outbound traffic for your mesh, letting you specify which traffic you want to enter or leave the mesh. Gateway configurations are applied to standalone Envoy proxies running at the edge of the mesh, rather than sidecar Envoy proxies running alongside your service workloads. Using this, we can expose our services to the internet.
\nA typical example would be:
\napiVersion: networking.istio.io/v1alpha3\nkind: Gateway\nmetadata:\n name: my-svc-gateway\n namespace: test\nspec:\n selector:\n istio: ingressgateway\n servers:\n - port:\n number: 80\n name: http\n protocol: HTTP\n hosts:\n - my-svc.example.comistio: ingressgateway is the gateway which is enabled by default after installation. We can create our custom gateway. Here, the hosts my-svc.example.com will resolve to the load balancer provided by the Istio by default. To use this gateway, one has to add config in the virtual service like for example:
\napiVersion: networking.istio.io/v1alpha3\nkind: VirtualService\nmetadata:\n name: my-svc\nspec:\n hosts:\n - my-svc\n - my-svc.example.com <-- The host should match\n gateways: <--- gateway config\n - my-svc-gateway\n http:\n - route:\n - destination:\n host: my-svc.test.svc.cluster.local\n port:\n number: 80 Network Resilience
\nThis feature provides network configuration dynamically at runtime, which includes retries, fault injection, circuit breakers, and timeouts.
\nService Entries
\nThis object is used to add an external service as part of the service mesh, including a service running in a VM or other K8s cluster in case of multi-cluster installation.
\nA typical example would be connecting a service to a database cluster that is not part of the mesh.
\napiVersion: networking.istio.io/v1alpha3\nkind: ServiceEntry\nmetadata:\n name: elasticsearch\n namespace: test\nspec:\n hosts:\n - elasticsearch.elasticsearch.svc.cluster.local\n location: MESH_INTERNAL\n ports:\n - name: https\n number: 9200\n protocol: TCP\n resolution: DNSThe Service Entry should be in the same namespace as that of the calling service. This is helpful, especially in the case where the service is not exposed to a public endpoint and can be accessed using internal service DNS like the above example.
\nSecurity
\nIstio provides security features that will help us to establish a zero-trust network. Istio enables security by default and provides various authentication and authorization policy to regulate security.
\nFor example:
\napiVersion: security.istio.io/v1beta1\nkind: PeerAuthentication\nmetadata:\n name: dsl-es\n namespace: pdp-test\nspec:\n selector:\n matchLabels:\n app: dsl-es\n mtls:\n mode: STRICTHere we define a peer authentication object for a service labeled my-svc, which tells that any service that needs to talk to my-svc will communicate using mtls. The service will accept only TLS connection. By default, Istio enables PERMISSIVE mode, which accepts both plaintext and encrypted communication.
\nWe can define peer authentication on the mesh, namespace, and pod level.
\nThat is all for the introduction to Istio. In the next part, we will look at installing Istio and configuring services to use Istio.
\n","frontmatter":{"date":"December 07, 2020","updated_date":null,"description":"This post will give a high-level introduction to Istio and its related concepts and terminologies.","title":"Istio Service Mesh: A Beginners Guide","tags":["Istio","Service Mesh"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/452f4d9f7cb358e3d6224ed3aba3d5d6/ee604/Istio.png","srcSet":"/static/452f4d9f7cb358e3d6224ed3aba3d5d6/69585/Istio.png 200w,\n/static/452f4d9f7cb358e3d6224ed3aba3d5d6/497c6/Istio.png 400w,\n/static/452f4d9f7cb358e3d6224ed3aba3d5d6/ee604/Istio.png 800w,\n/static/452f4d9f7cb358e3d6224ed3aba3d5d6/db955/Istio.png 900w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Piyush Kumar","github":"kpiyush17","avatar":null}}}},{"node":{"excerpt":"It is fine when you and the rest of your team are working on different files. But sometimes, multiple people simultaneously work on the same…","fields":{"slug":"/engineering/git-pull-force/"},"html":"It is fine when you and the rest of your team are working on different files. But sometimes, multiple people simultaneously work on the same files, and that's where the problems arise.
\nJust a Note: git pull = git fetch + git merge
In this scenario, when you have local changes in your system and you pull the latest contribution, you got this error.
\nerror: your local changes to the following files would be overwritten by merge: readme.md\nplease commit your changes or stash them before you merge.\nAborting...
Now you have 2 major choices
\nChoice 1: you want to keep local changes
\ngit stash (stash the local changes clean the workspace)\ngit pull (pull the latest changes from remote )\ngit stash apply (apply the latest stash)
-----------(or)---------------
\ngit fetch (fetch the local machine folder)\ngit stash (stash the local changes clean the workspace)\ngit merge '@{u}' (merge the changes from local folder to workspace folder)\ngit stash pop (apply the latest stash )
By default, the stash changes will become staged. If you want to unstage them, use git restore --staged (git ver > 2.25.0).
Choice 2: you do not want the local changes
\ngit reset --hard HEAD (reset to the head means remove all local changes)\ngit pull (get the latest changes)
-----------(or)---------------
\ngit fetch (fetch the local machine folder)\ngit reset --hard HEAD (reset to the head means remove all local changes)\ngit merge '@{u}' (merge the changes from the local folder to workspace folder)
git pull --force
\nNow you must be thinking, what is git pull --force then?
it feels like it would help to overwrite local changes. instead, it fetches forcefully but does not merge forcefully (git pull --force = git fetch --force + git merge).
Like git push, git fetch allows us to specify which local and remote branch we want to work on. git fetch origin/ft-1:my-ft means the changes in the ft-1 branch from the remote repository will end up visible on the local branch my-ft. When such kind of operation modifies the existing history, it is not allowed by the Git without an explicit --force parameter.
Introduction
\nIn this blog, I will show you how to create a NodeJS server using core http module. We will create a simple server that will serve static assets and a simple API to return some JSON data.
\nIn the process, you will also learn about the request and response objects provided by NodeJS, which are used by every other framework built on top of NodeJS like ExpressJS etc.
\nPrerequisites
\n- \n
- NodeJS installed on your system. Download from Here \n
- A basic understanding of JavaScript \n
With that in mind, let's begin.
\nStep 1: Initialize the project
\n- \n
- \n
Create a folder by any name and initialize a node project in it using
\nnpm init -y- \n
- By this time, you will have a
package.jsonfile in your directory. \n
\n - By this time, you will have a
- Create a file called
server.jsin your directory. \n
Step 2: Add some static content
\n- \n
- Create a directory called
publicat the root of your project. \n - \n
Add a file named
\nindex.htmlwith the following content\nindex.html
\n<!DOCTYPE html>\n<html lang="en">\n<head>\n <meta charset="UTF-8">\n <meta name="viewport" content="width=device-width, initial-scale=1.0">\n <title>Demo</title>\n</head>\n<body>\n <h1>Coming from the Root </h1>\n</body>\n</html>Step 3: Add our server code to serve the static assets
\n \n
Now we will create a node server that will serve our index.html file when a request is sent to /.
server.js
const http = require('http');\n const path = require('path');\n const fs = require('fs');\n const PORT = 3000;\n const hostname = 'localhost';\n\n // createServer is the http method used to create a web server that takes a callback.\n const server = http.createServer(serverHandler);\n\n // callback function definition\n function serverHandler(req, res) => {\n if(req.method === 'GET' && req.url === '/') {\n let filePath = path.resolve(__dirname, 'public/index.html')\n let fileExists = fs.existsSync(filePath);\n if (!fileExists) {\n res.statusCode = 404;\n res.setHeader('Content-Type', 'text/html');\n res.end(`\n <html>\n <body>\n <h3>Page not found</h3>\n </body>\n </html>`)\n } else {\n res.statusCode = 200;\n res.setHeader('Content-Type', 'text/html');\n fs.createReadStream(filePath).pipe(res);\n }\n }\n }\n\n server.listen(PORT, hostname, () => {\n console.log(`Server running at ${hostname}:${PORT}`); \n })Let's understand what just happened in the above code snippet:
\n- \n
- First of all, we just created a server using the
createServermethod provided by nodehttpmodule.createServertakes a callback which will be called when there is an incoming request withreqandresparameters. \n - In our callback function
serverHandler, we have used anifblock to check if the incoming request is aGETrequest and the requesturlis/then code inside if statement will be executed. \n - Then, we check if the
index.htmlwhich we want to serve exists or not in our public directory usingexistsSync, which synchronously checks for the file at the given path and returns true if the file exists. \n - Then if the file does not exist, we return a 404 status with an HTML response with a Content-Type header to let the browser know that it's an HTML type response. \n
- If the file exists, we create a readable stream from it using
createReadStreammethod fromfsmodule and pipe it intoresobject which sends it to the browser. \n - Finally, we use
server.listento start our server on the PORT 3000. \n
Now it's time to test our server. Run node server.js at the root of the project, and you will see the server running on PORT 3000.\nOpen your browser and enter localhost:3000 in the address bar, and you will get the HTML response.
Step 4: Add a basic API to return some JSON data
\nNow we will expand our callback, which we passed to createServer to handle one more GET request at /notes, which will return an array of notes to the browser.
Update the serverHandler function with the following code snippet in your server.js file
server.js
...\n function serverHandler(req, res) {\n if(req.method === 'GET' && req.url === '/') {\n let filePath = path.resolve(__dirname, 'public/index.html')\n let fileExists = fs.existsSync(filePath);\n if (!fileExists) {\n res.statusCode = 404;\n res.setHeader('Content-Type', 'text/html');\n res.end(`\n <html>\n <body>\n <h3>Page not found</h3>\n </body>\n </html>`)\n } else {\n res.statusCode = 200;\n res.setHeader('Content-Type', 'text/html');\n fs.createReadStream(filePath).pipe(res);\n }\n }\n // Newly added code \n if (req.method === 'GET' && req.url === "/notes") {\n const notes = [\n {\n id: 1,\n title: "Demo Note"\n },\n {\n id: 2,\n title: "Another Note"\n }\n ]\n\n res.statusCode = 200;\n res.setHeader('Content-Type', 'application/json');\n res.end(JSON.stringify(notes));\n } else {\n res.setHeader('Content-Type', 'application/json')\n res.end(JSON.stringify({message: `${req.method} is not supported for ${req.url}`}))\n } \n }\n ...- \n
- Here, we have added one more
ifstatement to handle the request coming at/notes. \n - We return a notes array in the JSON format, and we are setting the Content-Type header to be of
application/jsonfor the browser to process it accordingly. \n - We have also added an else statement to handle all other requests where we simply return a message to the browser that the request is not supported. \n
With that, we have created a simple node server to serve static content as well a simple API to return JSON data.
\nConclusion
\nWe saw how we had to handle each request with its method and the URL. With an increasing number of routes, such things become hard to manage as we will have to add multiple if statements. And that's why frameworks like ExpressJS, HapiJS exist, which makes creating servers in NodeJS very easy. But it's important to know what happens under the hood as there is no magic happening in those frameworks.
\nThe complete code for this blog can be found at Github Repo.
\n","frontmatter":{"date":"November 27, 2020","updated_date":null,"description":"Let us understand the core http module in NodeJS, which is the basic building block of frameworks like ExpressJS etc.","title":"NodeJS Server using Core HTTP Module","tags":["NodeJs","JavaScript"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/6ee159acf6c294342ec04f86aede5d14/14b42/coverImage.jpg","srcSet":"/static/6ee159acf6c294342ec04f86aede5d14/f836f/coverImage.jpg 200w,\n/static/6ee159acf6c294342ec04f86aede5d14/2244e/coverImage.jpg 400w,\n/static/6ee159acf6c294342ec04f86aede5d14/14b42/coverImage.jpg 800w,\n/static/6ee159acf6c294342ec04f86aede5d14/47498/coverImage.jpg 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Hridayesh Sharma","github":"vyasriday","avatar":null}}}},{"node":{"excerpt":"How does bitwise ^ (XOR) work? XOR is a bitwise operator, and it stands for \"exclusive or.\" It performs logical operation. If input bits are…","fields":{"slug":"/engineering/how-does-bitwise-xor-work/"},"html":"How does bitwise ^ (XOR) work?
\nXOR is a bitwise operator, and it stands for \"exclusive or.\" It performs logical operation. If input bits are the same, then the output will be false(0) else true(1).
\nXOR table:
\n| X | \nY | \nX^Y | \n
|---|---|---|
| 0 | \n0 | \n0 | \n
| 0 | \n1 | \n1 | \n
| 1 | \n0 | \n1 | \n
| 1 | \n1 | \n0 | \n
Example: 4^3 = 7
In binary: \n\t 0100\n\t ^ 0011\n\t ------\n Result: 0111 => (7)XOR with negative numbers
\nLet's understand with an example -4^-2 = 2\nIn the above example, we can see -4^-2output will be 2\nbut the question arises how? Because if we represent both inputs in the binary form, then we do XOR of bits, then the output will be 0000 0110 and in decimal, it will be 6 but as we know output should be 2.
1000 0100 (-4)\n^ 1000 0010 (-2)\n------------------\n 0000 0110 => (6) // incorrect output\n\nNote: Here, the leftmost bit position is reserved for the sign of the\nvalue (positive or negative) and doesn't contribute towards the value of the number.
\n
Let's understand how the XOR operation works with negative numbers.
\nHow XOR operation works with negative numbers?
\nFirst, the XOR operation is to XOR each bit (the same is 0, the difference is 1), but you need to convert the number into a complement first.
\n- \n
- The complement of a positive number is itself \n
- \n
The complement of the negative number is reversed for each bit and then incremented by 1 (the highest is kept at 1)
\n
\n// Lets take -4\nIn binary: \t\t\t1000 0100\nReverse: \t\t\t1111 1011\ncomplement (Increment by 1): \t1111 1100\n
// Now -2\nIn binary: \t\t\t1000 0010\nReverse: \t\t\t1111 1101\ncomplement (Increment by 1): \t1111 1110
\nFinal result:
\ncomplement of -4 : 1111 1100\ncomplement of -2 : 1111 1110\n -----------\nResult: 0000 0010 \t=> 2Here, the MSB bit of result will denote the sign, and the rest of the bits will denote the value of the final result.\nXOR sign table could be useful to understand the sign of result:
\n| X | \nY | \nX^Y | \n
|---|---|---|
| + | \n+ | \n+ | \n
| + | \n- | \n- | \n
| - | \n+ | \n- | \n
| - | \n- | \n+ | \n
The above approach will work with negative inputs, but if we have positive and negative, then?
\nHow XOR operation works with positive and negative numbers?
\nLet's performs -5 ^ 2\nFollow the same above approach to get a complement code of -5.
complement of -5 : 1111 1011\n// Note: complement of a positive number is itself\ncomplement of 2 : 0000 0010 \ncomplement result: 1111 1001\n\nNow, complement result -1 : 1111 1000\n -----------\nFinal result(inverse code): 1000 0111 => -7Some interesting use cases of XOR operator
\n- \n
- \n
Swap two number without the third variable\nExample:
\n
\nfunction swapWithXOR (a, b) {\n a = a^b;\n b = a^b;\n a=a^b;\n console.log("result => a: " + a + ", b: " + b)\n}\n\nswapWithXOR(4, 1); // result => a: 1, b: 4\n - RAID Drive Backups (Systems) \n
- Cryptography (XOR cipher) \n
- Array operations \n
Google has prepared a roadmap to restrict third-party cookies in Chrome. Since 04 January 2024, Chrome has rolled out third-party cookie restrictions for 1% of stable clients and 20% of Canary, Dev, and Beta clients.
\nWhat does it mean for user authentication?
\nOn one hand, Google believes third-party cookies are widely used for cross-site tracking, greatly affecting user privacy. Hence, Google wants to phase out (or restrict) supporting third-party cookies in Chrome by early Q2 2025 (subject to regulatory processes).
\nOn the other hand, Google introduced Privacy Sandbox to support the use cases (other than cross-site tracking and advertising) previously implemented using third-party cookies.
\nIn this article, we’ll discuss:
\n- \n
- How is user authentication (identity) affected? \n
- What is Google offering as part of Privacy Sandbox to support various identity use cases when third-party cookies are phased out? \n
How is User Authentication Affected?
\nThird-party cookie restrictions affect user authentication in three ways, as follows.
\nExternal Identity Providers
\nIf your website or app uses an external Identity Provider (IdP) — like LoginRadius, the IdP sets a third-party cookie when the user authenticates on your app.
\nWeb SSO
\nIf you have multiple apps across domains within your organization and authentication is handled using an IdP (internal or external) with web SSO, you already use third-party cookies to facilitate seamless access for each user using a single set of credentials.
\nIf you have implemented web SSO with one primary domain and multiple sub-domains of the primary domain, third-party cookie restrictions may not apply. For now, Google doesn’t consider the cookies set by sub-domains as third-party cookies, although this stance may change in the future.
\nFor example, you have apps at example.com, travel.example.com, stay.example.com, and web SSO is handled by auth.example.com. In this case, third-party cookie restrictions don’t apply.
Federated SSO
\nFederated SSO is similar to, albeit different from, web SSO. It can handle multiple IdPs and applications—aka., Service Providers (SPs)—spanning multiple organizations. It can also implement authentication scenarios that are usually implemented through web SSO.
\nUsually, authentication is handled on a separate pop-up or page when the user wants to authenticate rather than on the application or website a user visits.
\nFor example, you already use federated SSO if you facilitate authentication for a set of apps through multiple social identity providers as well as traditional usernames and passwords.
\n\n\nNote: It is also possible to store tokens locally, not within cookies. In this case, third-party cookie restrictions won’t affect token-based authentication. However, the restrictions still affect authentication where tokens are stored within third-party cookies (a common and secure method).
\n
Chrome’s Alternatives for Third-Party Cookies
\nGoogle has been developing alternative features and capabilities for Chrome to replace third-party cookies as part of its Privacy Sandbox for Web initiative.
\nSpecific to authentication, Google recommends the following:
\n- \n
- Cookies Having Independent Partitioned State (CHIPS) \n
- Storage Access API \n
- Related Website Sets \n
- Federated Credential Management (FedCM) API \n
Cookies Having Independent Partitioned State (CHIPS)
\nCHIPS are a restricted way of setting third-party cookies on a top-level site without making them accessible on other top-level sites. Thus, they limit cross-site tracking and enable specific cross-site functionalities, such as maps, chat, and payment embeds.
\nFor example, a user visits a.com with a map embed from map-example.com, which can set a partitioned cookie that is only accessible on a.com.
If the user visits b.com with a map embed from map-example.com, it cannot access the partitioned cookie set on a.com. It has to create a separate partitioned cookie specific to b.com, thus blocking cross-site tracking yet allowing limited cross-site functionality.
You should specifically opt for partitioned cookies (CHIPS), which are set with partitioned and secure cookie attributes.
\nIf you’re using an external identity provider for your application, CHIPS is a good option to supplant third-party cookie restrictions.
\nHowever, CHIPS may not be ideal if you have a web SSO or federated SSO implementation. It creates separate partitioned cookies for each application with a separate domain, which can increase complexity and create compatibility issues.
\nStorage Access API
\nWith Storage Access API, you can access the local storage in a third-party context through iframes, similar to when users visit it as a top-level site in a first-party context. That is, it gives access to unpartitioned cookies and storage.
\nStorage Access API requires explicit user approval to grant access, similar to locations, camera, and microphone permissions. If the user denies access, unpartitioned cookies and storage won’t be accessible in a third-party context.
\nIt is most suitable when loading cross-site resources and interactions, such as:
\nVerifying user sessions when allowing interactions on an embedded social post or providing personalization for an embedded video.\nEmbedded documents requiring user verification status to be accessible.
\nAs it requires explicit user approval, it is advisable to use Storage Access API when you can’t implement an identity use case with the other options.
\nRelated Website Sets
\nWith Related Website Sets, you can declare a primary website and associatedSites for limited purposes to grant third-party cookie access and local storage for a limited number of sites.
Chrome automatically recognizes related website sets declared, accepted, and maintained in this open-source GitHub repository: Related Website Sets
\nIt provides access through Storage Access API directly without prompting for user approval, but only after the user interacts with the relevant iframe.
\nIt is important to declare a limited number of domains in related website sets that are meaningful and used for specific purposes. Google may block or suspend any exploitative use of this feature.
\nThe top-level site can also request approval for specific cross-site resources and scripts to Storage Access API using resuestStorageAccessFor() API.
If you’re using an external identity provider for your web application, you can declare the domain of the identity provider in the related set to ensure limited third-party cookies and storage access to the identity provider, thus ensuring seamless user authentication.
\nRelated Website Sets can also work to supplement third-party cookie restrictions in web SSO and federated SSO if the number of web applications (or domains) is limited.
\nFederated Credential Management (FedCM) API
\nFedCM API enables federated SSO without third-party cookies.
\nWith FedCM API, a user follows these steps for authentication:
\n- \n
- The User navigates to a Service Provider (SP) — aka., Relying Party (RP) \n
- As the user requests to authenticate, the SP requests the browser through FedCM API to initiate authentication. \n
- The browser displays a list of available identity providers (supported by the RP), such as social IdPs like Google, Apple, LinkedIn, and Facebook, or other OAuth IdPs like LoginRadius. \n
- Once the user selects an IdP, the browser communicates with the IdP. Upon valid authentication, the IdP generates a secure token.\nThe browser delivers this secure token to the RP to facilitate user authorization. \n
You can access a user demo of FedCM here: FedCM.
\nFor more information about implementing federated SSO with FedCM API, go through the FedCM developer guide.
\nHow is LoginRadius Preparing for the Third-party Cookie Phase-out?
\nFirstly, we’re committed to solving our customers' user identity pain points — and preparing for the third-party cookies phase-out is no different.
\nWe’ll implement the most relevant and widely useful solutions to facilitate a smooth transition for our customers.
\nPlease subscribe to our blog for more information. We’ll update you on how we help with the third-party cookie phase-out.
\nIn Conclusion
\nThe proposed changes to phase out third-party cookies and suggested alternatives are evolving as Google has been actively collaborating and discussing changes with the border community.
\nMoreover, browsers like Firefox, Safari, and Edge may approach restricting third-party cookies differently than Google does.
\nFrom LoginRadius, we’ll keep you updated on what we’re doing as a leading Customer Identity and Access Management (CIAM) vendor to prepare for the third-party cookie phase-out.
\nGlossary
\nTop-level site: It is the primary site a user has visited.
\nFirst-party cookie: A cookie set by the top-level site.
\nThird-party cookie: A cookie set by a domain other than the top-level site. For example, let’s assume that a user has visited a.com, which might use an embed from loginradius.com to facilitate authentication. If loginradius.com sets a cookie when the user visits a.com, it is called a third-party cookie as the user hasn’t directly visited loginradius.com.