DEV Community: Suvin Nimnaka

Why a Developer Portal Is Not an Internal Developer Platform

Suvin Nimnaka — Fri, 30 Oct 2026 08:22:39 +0000

Imagine a developer joining a new team. On the first day, they're told that the team runs its applications on Kubernetes, uses GitHub for source code, has CI/CD pipelines for deployments, and uses a few different tools for monitoring and security. None of this is unusual. In fact, this is probably a fairly normal setup for a modern engineering team.

Then the developer gets their first task: create a new service.

That simple request suddenly opens a much bigger list of questions. Where should the repository be created? How should the deployment pipeline be configured? Which Kubernetes resources are needed? How does the service get its environment variables and secrets? Who creates the database? Which monitoring dashboard should be used? What security rules need to be followed?

The developer can spend a few days figuring all of this out, or they can ask the platform team for help. If every new developer and every new service follows the same path, the platform team can quickly turn into a help desk answering the same set of questions over and over again.

This is one of the problems that platform engineering tries to solve. Instead of asking every development team to understand all the infrastructure and tools underneath their applications, organizations can build a set of reusable capabilities and give developers a simpler way to use them.

This is where two terms often appear: Internal Developer Platform (IDP) and Internal Developer Portal (IDP).

They're closely related, but they are not the same thing.

The Platform Behind the Developer Experience

An Internal Developer Platform is the collection of technologies, automation, workflows, and services that make it easier for developers to build, deploy, and operate applications.

It can bring together infrastructure provisioning, CI/CD, Kubernetes, cloud resources, secrets, security policies, observability, and other engineering capabilities. The point isn't just to put these tools in one place. The platform should hide unnecessary complexity and provide developers with reliable ways to perform common tasks.

For example, a platform team might create a standard way to deploy a web service. Instead of every development team writing its own Kubernetes configuration and deployment pipeline, the platform provides a reusable workflow. The developer supplies the information that matters to the application, while the platform takes care of the underlying details.

This is where the idea of a golden path comes in.

A golden path is a recommended way of doing something. It doesn't mean that developers are forced to use only one technology or one approach. It means that if they want the path that is already supported, secure, and maintained by the platform team, they have an easy way to follow it.

This distinction is important because an Internal Developer Platform is not simply a collection of DevOps tools. Kubernetes, GitHub Actions, Terraform, Argo CD, Prometheus, and other tools can all be part of a platform, but putting them next to each other doesn't automatically create one.

The value comes from connecting them into useful workflows.

The CNCF Platforms White Paper describes platforms in a similar way: they bring together capabilities and provide an interface that reduces the amount of infrastructure complexity developers need to deal with. Humanitec frames it as a set of capabilities that creates a self-service experience for developers and supports the organization's preferred ways of building and delivering software.

That's half the picture. The other half is still a question: How does a developer actually find and use all these capabilities?

The front door: Internal Developer Portals

Go back to our developer who needs to create a new service. Suppose the organization has already built a good internal platform. There are templates for new services, automated deployment workflows, documentation, monitoring integrations, and all the required infrastructure automation.

That sounds great.

Now imagine the developer has to search through Git repositories, internal documentation, Slack messages, and several different tools to find all of it.

The platform may be excellent, but the developer experience is not.

An Internal Developer Portal helps solve this problem by giving developers a central place to discover and interact with the software and capabilities available to them.

One of the best-known examples is Backstage, the open-source developer portal framework created at Spotify. Backstage provides a software catalog where teams can keep information about their services, documentation, ownership, and dependencies. It also provides templates that can help developers create new software using the organization's preferred patterns.

This matters because, as an engineering organization grows, knowing what exists can become almost as difficult as building it.

A developer may know that a payment service exists, but who owns it? Where is its source code? What does it depend on? Where is its documentation? Which team should they contact if something breaks?

A good developer portal answers these questions without requiring the developer to play Sherlock Holmes.

Spotify's experience with Backstage is quite interesting because it started as an internal tool and grew into an open-source project used by many organizations. Spotify has written about this journey in Celebrating Five Years of Backstage.

Commercial products such as Port and Cortex take a similar idea and add capabilities around service catalogs, engineering standards, scorecards, and self-service workflows.

But calling a portal a "directory" would undersell what modern portals can do. A developer portal can also be the place where a developer starts an action. It might allow them to create a service, request an environment, trigger a deployment, or perform another operational task.

This is where the line between the portal and the platform starts to become less obvious.

So where does the platform end and the portal begin?

Let's return to that new service.

The developer opens the internal portal and selects Create a new component. They choose a service template, enter the name of the application, connect the source code repository, and submit the request.

The portal itself doesn't need to know how Kubernetes works. It doesn't need to know which API should be called or how the deployment pipeline should be configured. Instead, it passes the request to the underlying platform capabilities.

The platform then does the hard work with it's control plane acting as its brain.

The control plane coordinates the underlying tools and capabilities through a platform contract, enforcing governance. It knows how the different pieces of the platform need to work together and based on the request, it manages the necessary steps behind the scenes. It can create the Kubernetes manifests, configure the required resources, set up the deployment workflow, apply security policies, and connect the application to monitoring and other services.

From the developer's point of view, this might feel like one simple action. Behind that button, however, there could be several systems working together.

That is the key difference.

The portal is the place where developers discover and interact with the platform. The platform is the set of capabilities that actually enables the work.

The distinction isn't always a clean technical boundary. A portal can contain automation. A platform can expose APIs and command-line tools. Some products combine both ideas. What matters more is understanding the roles they play in the developer experience.

This is also where a lot of the confusion comes from. Backstage's Software Templates can run real actions: create a repository, open a pull request, etc. It's tempting to keep adding steps until the template is your deployment process. At that point you've built a platform, just a thin one that lives inside your portal's template files. That holds up until a second interface, like a CLI, a CI job, or an AI agent, needs the same capability and has no way to reach it.

It's also why you can have an Internal Developer Platform without a traditional portal. Developers could interact with the platform through APIs, CLIs, MCP (Model Context Protocol), or other interfaces. In the same way, it's possible to have a developer portal that provides a catalog and documentation without having a strong platform underneath it.

The two become much more useful when they work together.

What does this look like in a real platform?

Open-source projects such as OpenChoreo provide an interesting example of the platform side of this story.

OpenChoreo is an open-source Internal Developer Platform designed to simplify application development and deployment on Kubernetes. Instead of exposing every Kubernetes detail to application developers, it provides higher-level concepts and workflows that allow platform teams to define how applications should be built and deployed.

This is an important idea in platform engineering.

Developers don't necessarily need less technology. They need less unnecessary complexity.

Kubernetes is powerful. So is a commercial aircraft. Neither means every passenger should have to understand how the engine works. Most application developers do not want to think about every Kubernetes resource required to deploy a service. They want to build the service and have a reliable way to run it.

OpenChoreo approaches this by providing platform abstractions, reusable workflows, deployment capabilities, GitOps, and observability. Platform engineers can define the capabilities and rules of the platform, while application developers work with simpler application-level concepts.

OpenChoreo also includes a developer portal experience built around Backstage. This creates a useful example of how the two ideas can come together: the portal provides the developer-facing experience, while the underlying platform provides the capabilities and automation.

The OpenChoreo architecture documentation describes how its different platform components work together. At the heart of this architecture is the control plane, which acts as the brain of the platform. It brings the underlying tools and capabilities together, providing a consistent way to enforce governance and manage how applications are built, deployed, and operated.
In addition to the control plane, OpenChoreo separates the platform into multiple planes, each with a distinct role. The experience plane provides the interaction interface (for both humans and agents), the data plane runs application workloads, the workflow plane handles build and deployment workflows, and the observability plane collects logs, metrics, and traces. The control plane coordinates the other planes, ensuring their capabilities work together as a cohesive platform while each plane focuses on its specific role.

Looking at examples like this makes one thing clear. An Internal Developer Platform doesn't have to be a single tool. It can be a system made up of several connected capabilities, with clear interfaces between them.

And the portal doesn't have to replace those capabilities. It gives developers a simpler way to consume them.

Why does the distinction matter?

It may be tempting to say that this is all just terminology. After all, developers do not really care whether something is called a portal or a platform. They care whether they can get their work done without spending three hours searching for the right configuration file.

True, but the distinction becomes useful when deciding what to build.

Imagine a company where developers constantly ask, "Who owns this service?", "Where is the documentation?", or "Which repository contains this application?" The immediate problem is discoverability. A software catalog and developer portal could make a big difference.

Now imagine another company where developers know exactly where everything is, but creating a new environment takes three days and every team has a different deployment process. In that case, adding another portal page probably will not solve the real problem. The organization needs better platform automation.

In many organizations, the answer is both.

The portal becomes the front door, while the platform provides what is behind the door.

This also explains why simply installing a developer portal doesn't automatically create an Internal Developer Platform. You can have a beautiful catalog with hundreds of services listed in it and still require developers to open tickets every time they need an environment.

That is a very nice catalog. It is not necessarily a platform.

The reverse is also true. An organization can have excellent platform automation but make developers interact with it through a confusing collection of scripts, repositories, and internal documentation.

The machinery works, but nobody knows where the buttons are.

Building the right thing

Platform engineering usually goes better when you don't start with the question, "Which platform should we build?"

Start with a developer problem.

Maybe creating a new service takes too long. Maybe developers spend too much time configuring deployment pipelines. Maybe service ownership is difficult to discover. Maybe every team has invented its own way of deploying applications.

Pick one of these problems and solve it well.

A good platform team can then turn the solution into a reusable capability. A good portal can make that capability easy to discover and use. Over time, more workflows can be added as new problems appear.

This is also why platform engineering should be treated as an ongoing product rather than a one-time infrastructure project. Developers are the users of the platform, and their feedback should shape what the platform provides.

The CNCF Platform Engineering Maturity Model is useful here because it looks at platform engineering as something that evolves as organizations mature.

The goal is to remove the right complexity, not to build the biggest platform or the most impressive portal.

The difference, in short

After all the architecture diagrams, tools, portals, Kubernetes clusters, templates, and very serious platform-engineering discussions, the difference can be reduced to something quite simple:

An Internal Developer Platform provides the capabilities and automation developers need to build and run software, while an Internal Developer Portal gives them a simple place to discover and use those capabilities.

The two are not competitors. A portal without useful platform capabilities can become a nice-looking directory. A platform without a good developer experience can become another complicated system developers have to learn.

When they work together, something much better happens.

When the two work together, a developer can open one place, pick the supported path, get what they need, and go back to writing code. Tht might be the real test of a developer platform: how little time developers spend thinking about the platform itself.

One More Mile - Bringing Joy to Runners with Twilio

Suvin Nimnaka — Mon, 19 Oct 2026 13:16:14 +0000

If you've ever run a long race, you probably know that there are parts where things get a little difficult. Your legs hurt. You are tired. You start questioning your life choices and wondering why you voluntarily paid money to do this.

And then you hear someone cheering for you.

It could be your mum, your partner, a friend, or anyone else you care about. Just hearing a familiar voice can give you that little push to keep going.

The problem is that your favourite people are usually not running alongside you. I've felt this myself during runs in Colombo. There are parts of some city races where you are running between buildings, with hardly anyone around to cheer. You have thousands of runners around you, but somehow it can still feel pretty lonely.

That got me thinking. Most runners already have their phones with them, and a lot of them run with headphones. So why not use the phone to bring some of that support to them?

The idea was simple. Friends and family could record short voice messages for a runner. During the race, the runner could open a link and listen to those messages.

Then I started thinking about how to build it.

The first idea

My first thought was a phone hotline.

A supporter could call a number, enter the runner's bib number, record a message, and hang up. The runner could then call another number and listen to the messages.

Twilio seemed perfect for this. It already handles phone calls, recordings, menus and pretty much everything else you need for a voice application.

There was just one problem.

Then I hit a wall

Twilio phone numbers aren't available in Sri Lanka. That made the phone hotline idea pretty useless.

I could have used an international number, but then supporters would have to pay international call charges just to leave a 20 second message. The runner would also have to spend phone credit listening to those messages during the race. Like running is not already expensive :D

That didn't make much sense.

So I started looking at the problem again.

The mundane workaround

I realized I was too focused on the phone number.

The number wasn't really what I needed. I just needed a way to send audio from a supporter to a runner, with the runner's bib number connecting the two.

And a browser can handle audio.

Twilio's Voice SDK supports WebRTC, which means a web page can connect to Twilio and behave much like a phone call, without actually using a phone number.

That was enough.

Instead of asking someone to call a number, I could just give them a link.

The supporter opens the link, enters the bib number, records a message and sends it. The runner gets their own private link and can listen to everything.

No app. No phone number. No international call charges.

I called it One More Mile.

Leaving a message

A supporter opens the page and enters the runner's bib number.

The app checks it and shows the runner's name. This is a small thing, but it helps avoid a surprisingly easy mistake. You never know if it's 1234 or 2444 (One 2, three 4 in case you didn't get it :p).

Once the runner is confirmed, the supporter enters their own name and starts recording.

They can say whatever they want. Well, not just anything. Only the good things.

It might be a serious motivational message. It might be "Come on, you've got this!" Or it might be a (good?) friend reminding them that therapy is much cheaper than running.

When they're done, they hit stop and the message is saved.

There is a small trick happening here.

With a normal phone call, you can press the # key to tell Twilio that the recording is finished. Obviously, a browser doesn't have a phone keypad. So the stop button sends the same signal through the WebRTC connection. Twilio receives it, stops the recording and stores it.

The person recording doesn't need to know any of that.

Listening to the messages

The runner gets a private link, usually through a QR code or a message from the event organizer.

When they open it, they see one big play button.

That's basically the whole interface.

At kilometer 32, nobody wants to read instructions or figure out which menu to open. You just want to press something and hear someone you know.

The messages play one after another, with the sender's name announced before each one. Sometimes, just hearing the sender's name is enough to brighten your day, if you know what I mean. :wink

If there aren't any messages yet, the app tells the runner to keep going anyway. Hopefully someone remembers to send one soon.

The listening link also contains a secret token, so the messages aren't publicly accessible. If someone opens the page without a valid token, they just get an invalid-link screen.

Nobody else gets to listen to your race-day fan mail.

What Twilio is actually doing

Once I had the basic idea working, here is how I designed all the features around Twilio.

The Voice SDK connects the browser to Twilio using WebRTC.

A small token function gives the browser a short-lived token so it can make the connection. Think of it as a wristband at a concert.

The TwiML App tells Twilio where to send the call.

The Serverless Functions handle the calls and return TwiML instructions such as "start recording" or "play this recording."

Twilio Sync stores the runner roster and keeps track of the messages associated with each bib number.

The actual audio is stored as recordings, which Twilio can then play back.

The whole app also lives in Twilio. The web pages are served as Twilio Assets alongside the Functions, so the frontend and backend can be deployed together.

That means there isn't another server I need to worry about on race morning.

One less thing to break at 5 am!

The race organizer's side

Someone still needs to tell the application who is actually running.

For that, I built a small admin page where the organizer can upload a CSV containing the bib numbers and runner names.

The page validates the file before replacing the existing roster.

It also generates a private listening link for each runner, which the organizer can distribute before the race.

And yes, there is a CSV template. Because whenever you give someone a CSV upload, the first question is almost always, "What columns do I need?"

Want to try it yourself?

If you have a Twilio account, just run:

curl -fsSL https://raw.githubusercontent.com/Suvink/one-more-mile/main/init.sh | bash

The script walks you through the setup and deploys the app for you. You only have to input the Twilio Auth Token and account SID. Yes, it's a bit of a black box. But hey, at least it's a box that works!

Now if you don't wanna put your blind faith in a total stranger, head over to the GitHub repo for the source code and setup instructions.

Suvink / one-more-mile

One More Mile

Voice messages for marathon runners. Supporters enter a runner's bib number and record a message in the browser. On race day, each runner opens a private link and hears every message through their headphones.

It runs entirely on Twilio, with no phone number needed. The browser places the call over WebRTC using the Twilio Voice SDK, so it works in countries where Twilio numbers aren't available.

Functions (functions/): access tokens, bib lookup, roster upload, and the TwiML for recording and playback
Sync stores the roster and each runner's message list. Recordings stay in Twilio's recording storage.
Web app (web/): a Vite + React PWA, served as Twilio Assets on the same domain

Setup

You need git, Node 18+, and your Twilio Account SID and Auth Token from the Twilio Console.

curl -fsSL https://raw.githubusercontent.com/Suvink/one-more-mile/main/init.sh | bash

This clones the repo, asks for your…

View on GitHub

Where I could take it next

The first version is intentionally simple, but there are a few things I'd like to add as I keep working on One More Mile.

The first is moderation. Give people a microphone and eventually, someone is going to use it to say something they probably shouldn't.

Twilio's Conversational Intelligence could help here. Voice messages could be transcribed and analyzed before they reach the runner, allowing the application to flag or reject messages containing profanity or other unwanted content. That would be especially useful if this is being used for a large public race where hundreds or thousands of people might be sending messages.

There is also room to make the experience more fun for supporters. Maybe they could choose a few quick prompts like "Give them a pep talk" or "Make them laugh" when they start recording. That could make it easier for someone who wants to send a message but has no idea what to say.

The finish line

The original phone hotline idea would have worked if Twilio phone numbers were available in Sri Lanka. The web version ended up being just as good anyways.

It is easier to share, works directly from the runner's phone, doesn't require an app, and works without relying on local phone numbers.

But the technical part is only half the reason I built it.

The real reason is what happens during a long race when you are tired and the crowd disappears.

You might hear your mum saying, "I'm so proud of you." You might hear your partner telling you that they're waiting at the finish line. Or you might hear your best friend saying something so stupid that you actually laugh when you are supposed to be conserving whatever energy you have left.

For a moment, they feel like they're right there with you. And maybe that's enough to keep running.

One more mile.

Don't become a victim of PII Harvesting

Suvin Nimnaka — Sat, 06 Dec 2025 14:11:31 +0000

Disclaimer:
This post is for educational and security awareness purposes only. The techniques described were performed as a proof-of-concept to demonstrate vulnerabilities in how personal information is shared on social media platforms. No data was collected, stored, or misused in any way. The goal is to help job seekers protect their personal information online. Please do not use these techniques for malicious purposes or to harvest data without consent. Unauthorized data collection may violate platform terms of service and applicable privacy laws.

I was scrolling through LinkedIn earlier today when I came across a job posting that looked completely legitimate at first glance.

Backend Developer position. Remote work. Open to freshers.

Then I saw this line:

"Comment your #email_ID and we'll send the assignment link within 24 hours."

The post already had 35+ comments. People were dropping their personal email addresses in plain view.

The Red flags

I clicked on the poster's profile to learn more about the company and the recruiter's background.

Their About section was blank. No company listed. Their post history showed random photos of "onboarding kits" from various tech companies, but nothing connecting them to an actual organization.

Meanwhile, real people were publicly exposing their contact information.

Maybe it was a legitimate post. Maybe it wasn't. I had no solid proof either way. But something felt off. Empty profile, no company affiliation, dozens of people publicly exposing their emails in the comments.

That's when a different question hit me. Even if this poster had good intentions, how easy would it be for someone else to harvest all these publicly visible emails?

I decided to find out.

Let's write some code

I wanted to understand the technical barrier to exploiting this kind of post. Turns out, it's almost non-existent.

I opened ChatGPT and typed: "Write a Chrome extension that extracts email addresses from LinkedIn post comments."

One minute later, I had working code.

I didn't need to understand the LinkedIn DOM structure. I didn't need to write regex patterns for email validation. I didn't need to figure out Chrome extension manifests. The AI handled all of it.

Copy, paste, load unpacked extension in Chrome. Done.

I clicked on the malicious job post, opened the extension, hit "Extract." Within seconds, I had a clean list of 9 email addresses that people had publicly commented.

No LinkedIn API access needed. No authentication bypass. No rate limiting to circumvent. No technical expertise required.

The entire process, from idea to harvested emails, took under 3 minutes. With a little more time playing with the prompt, I would've gotten every single email extracted from the post.

Now imagine this: multiple posts, multiple sock-puppet accounts, automated monitoring with Puppeteer or Selenium running on a cheap VPS. You're looking at thousands of emails harvested daily with basically zero effort or infrastructure cost.

The scary part? I'm not even a security researcher. I'm just someone who knows how to use ChatGPT. And if I can do this in 3 minutes, imagine what someone with actual malicious intent can do.

What happens after emails are harvested

Let me be very clear here. I collected nothing beyond the proof of concept. But bad actors absolutely do, and the downstream attacks are more sophisticated than most people realize. I'll explain a couple of them.

Context-aware spear phishing

When an attacker knows you commented on a backend developer posting, they can craft targeted messages:

"Thanks for your interest in the Senior Backend Engineer role. We've reviewed your background and would like to move forward. Please access the technical assessment here: [malicious link]"

This isn't generic spam. It references your actual behavior and interests. The click-through rate on context-aware phishing is 5-10x higher than traditional campaigns.

Malicious payload delivery

That "assignment link" the recruiter will be sending could resolve to many things.

Phishing pages that clone Google Docs or GitHub's login interface
ZIP archives containing RATs (Remote Access Trojans)
Fake repositories with malicious dependencies buried in package.json or requirements.txt

Developers are especially vulnerable because our workflow involves downloading and executing code regularly. We're trained to git clone and npm install without suspicion.

Long-term dataset enrichment

Harvested emails get added to larger databases for future use. Your email from this LinkedIn comment can be correlated with many other information coming from various diffierent sources such as,

Your GitHub activity (public repos, commit patterns, starred projects)
Breach databases from previous incidents (haveibeenpwned, leaked credentials)
OSINT from Twitter, personal blogs, conference talks
Account enumeration across AWS, Azure, Digital Ocean

This creates a persistent digital footprint. Attackers can revisit this data months or years later, long after you've forgotten about that one LinkedIn comment.

Automated account enumeration

Once they have your email, attackers run automated checks to see where else you have accounts. Tools like holehe or custom scripts can enumerate which cloud providers you use (AWS, GCP, Azure), your presence on GitHub, GitLab, Bitbucket, and developer tool accounts like npm, PyPI, or Docker Hub. Each confirmed account becomes another potential attack surface.

Why does this work so well for the attackers?

This works so well because LinkedIn's "professional environment" creates a false sense of security where people assume bad actors wouldn't operate where identities are theoretically verifiable. Job seekers, especially early-career developers, are economically vulnerable and when opportunity appears, critical evaluation goes out the window. The technical barrier for pulling off something like this is now close to zero. You don't need programming expertise anymore when you can ask an LLM to generate the code in 30 seconds. And it scales exponentially. One post harvests dozens of emails, ten posts hundreds, automated monitoring across multiple sock-puppet accounts captures thousands daily.

So, how to protect yourself from being a victim?

Never post personal information publicly

Use LinkedIn's DM feature. Real recruiters understand this. If someone insists on public email drops, disengage immediately.

Validate the poster thoroughly

Before engaging with a recruitment post,

Verify company affiliation (check if the domain exists and has a careers page)
Look for consistent employment history
Check if actual employees from that company interact with the post
Search the company's official job board

Empty profiles + urgency = big red flags.

Use platform-provided channels

Most of the time, legitimate companies have:

Branded career portals with proper TLS certificates (served over HTTPS)
Corporate email domains (not free providers like Gmail)
Application tracking systems (Greenhouse, Lever, Workday or LinkedIn Quick Apply)

If they're running hiring through comment sections, they're either fake or incompetent. Neither is worth your time.

Compartmentalize your identity

Use dedicated email addresses for job applications. Services like SimpleLogin or AnonAddy let you create unique aliases per application. If one gets compromised, you know exactly where the leak happened, and you can kill that alias without affecting your main inbox.

Think of it as the principle of least privilege, applied to your digital identity.

Bottom line

Look, I get it. We all want jobs. But posting your email in a public LinkedIn comment is like pulling down your pants in a crowded mall and yelling "I'm here for the interview!" Sure, maybe a recruiter sees you. But so does everyone else, including the guy in the corner taking notes for all the wrong reasons.

This isn't about paranoia. LinkedIn remains valuable for networking and career growth. But recognize that modern social engineering doesn't require technical sophistication. Attackers just don't exploit software vulnerabilities, They exploit human psychology in professional contexts.

Your email is PII. It can be a primary key in multiple databases. It's the recovery mechanism for most of your accounts. Treat it with the same caution you'd treat your home address or SSN.

Next time you see "Drop your email in the comments," pause and evaluate. Is this legitimate, or is someone harvesting data?

Your inbox security depends on that split-second decision. Stay skeptical. Verify everything. And keep your PII out of public spaces as much as you can.

I Built a Twitter Bot So I Don't Have to Check Twitter Every 5 Minutes!

Suvin Nimnaka — Sun, 24 Aug 2025 06:02:43 +0000

Picture this. You've built an amazing product. You're proud of it. Your mom's proud of it. Even your cat seems impressed (though cats are notoriously hard to please). But here's the thing: people are talking about your product on Twitter (well, “X” now, but let’s be real, we’re all still calling it Twitter), and you have absolutely no idea what they're saying.

Sure, you could spend your entire day doom-scrolling through Twitter, searching for mentions of your product. But let's be honest. That's about as appealing as watching paint dry in slow motion. Plus, you've got actual work to do, like building more amazing features or figuring out why the coffee machine in the office keeps making that weird noise.

The solution? Build a bot that watches Twitter for you and sends updates directly to your team's Google Chat. It's like having a really dedicated intern who never sleeps, never complains, and never eats your lunch from the office fridge.

What We're Building

We're creating a Node.js service that:

Monitors Twitter for tweets containing your product's hashtag.
Forwards the juicy details to your Google Chat workspace.
Runs once, exits, and repeats the same every 15 minutes.
Does all this without you having to touch Twitter with a 10-foot pole.

Prerequisites (The boring, necessary stuff)

Before we dive into the fun part, make sure you have:

Node.js installed (version 14 or higher – we're not animals here)
A Twitter Developer Account
A Google Chat workspace (or the ability to create webhooks in one)
A Choreo Account. If you don't have one, sign up for free at https://console.choreo.dev/signup.

Step 1: Setting Up Your Twitter API Access

First things first. You need to get cozy with the Twitter API. Don't worry, it's not as scary as it sounds.

Head over to developer.twitter.com.
Create an app (call it something cool like "HashtagWatcher3000").
Generate a Bearer Token.
Keep that token safe.

Step 2: Google Chat Webhook Setup

Now let's set up the delivery mechanism – Google Chat webhooks.

Go to your Google Chat space.
Click on the space name → "Manage webhooks".
Create a new webhook.
Copy that URL and note it down somewhere.

Step 3: Project Setup (The Base)

Create a new directory and initialize your project:

mkdir twitter-hashtag-monitor
cd twitter-hashtag-monitor
npm init -y

Install the dependencies we'll need:

npm install axios dotenv

Why these packages?

axios: For making HTTP requests
dotenv: For managing environment variables (keeping secrets secret)

Step 4: Environment Configuration

Create a .env file to store your sensitive information:

TWITTER_BEARER_TOKEN=your_actual_bearer_token_here
GOOGLE_CHAT_WEBHOOK_URL=your_webhook_url_here
HASHTAG=#yourproducthashtag

And create a .gitignore file just to make sure you don't accidentally commit your API keys.

node_modules
.env

Important: Never, ever, EVER commit your .env file to version control. That's like leaving your house key under the doormat with a note saying "free stuff inside."

Step 5: The Main Event – Building the Bot

Now for the fun part! Create an index.js file.

require("dotenv").config();
const axios = require("axios");

// Configuration object (keeping configs organized)
const config = {
    bearerToken: process.env.TWITTER_BEARER_TOKEN,
    googleChatWebhookUrl: process.env.GOOGLE_CHAT_WEBHOOK_URL,
    hashtag: process.env.HASHTAG || "#choreoisawesome", // Default hashtag
    checkInterval: 15, // minutes to look back
    maxResults: 10,
    twitterServiceUrl: "https://api.twitter.com/2/tweets/search/recent",
};

The Tweet Search Function

This function is the heart of our operation:

async function searchTweets() {
    try {
        const now = new Date();
        // Twitter needs a 10-second buffer, so we use 20 to be safe
        const endTime = new Date(now.getTime() - 20 * 1000);
        const timeAgo = new Date(endTime.getTime() - config.checkInterval * 60 * 1000);

        const params = {
            query: config.hashtag,
            start_time: timeAgo.toISOString(),
            end_time: endTime.toISOString(),
            max_results: config.maxResults,
            "tweet.fields": "created_at,author_id,public_metrics,text",
            "user.fields": "username,name",
        };

        const response = await axios.get(config.twitterServiceUrl, {
            headers: {
                Authorization: `Bearer ${config.bearerToken}`,
            },
            params,
        });

        return response.data.data || [];
    } catch (error) {
        console.error("Error searching tweets:", error.response?.data || error.message);
        return [];
    }
}

What's happening here?

We create a time window (last 15 minutes, but ending 20 seconds ago)
We ask Twitter for tweets containing our hashtag in that timeframe
We request additional fields like metrics and user info (because context matters)
If something goes wrong, we gracefully return an empty array instead of crashing

To learn more about the search API, head over to the Search Recent Posts API on X API Documentation.

The Google Chat Messenger

This function takes our Tweet data and formats it nicely for Google Chat.

async function sendTweetsToService(tweets) {
    if (tweets.length === 0) {
        console.log("No tweets found in the last", config.checkInterval, "minutes");
        return;
    }

    try {
        const tweetToSend = tweets[0]; // We only send the first tweet for now
        console.log(`Found ${tweets.length} tweet(s), sending the first one to Google Chat`);

        // Format message for Google Chat
        const message = {
            text:
                `🐦 New Tweet Found!\n\n` +
                `*Hashtag:* ${config.hashtag}\n` +
                `*Author:* ${tweetToSend.username || tweetToSend.author_id}\n` +
                `*Created:* ${tweetToSend.created_at}\n\n` +
                `*Tweet:*\n${tweetToSend.text}\n\n` +
                `*Metrics:* ❤️ ${tweetToSend.public_metrics?.like_count || 0} | 🔁 ${
                    tweetToSend.public_metrics?.retweet_count || 0
                }`,
        };

        const response = await axios.post(config.googleChatWebhookUrl, message, {
            headers: {
                "Content-Type": "application/json",
            },
        });

        console.log("Successfully sent tweet to Google Chat");

        // Mission accomplished – time to exit
        console.log("Tweet sent successfully. Stopping the service...");
        process.exit(0);
    } catch (error) {
        console.error("Error sending tweet to Google Chat:", error.response?.data || error.message);
    }
}

Pro Tip: Instead of just sending a text message to Google Chat, you can send nicely formatted cards. Check the Google Chat Cards Documentation for more information.

Tying It All Together

async function checkAndSendTweets() {
    console.log(`\n[${new Date().toISOString()}] Checking for tweets with hashtag: ${config.hashtag}`);

    const tweets = await searchTweets();
    await sendTweetsToService(tweets);
}

function startMonitoring() {
    console.log("Starting Twitter Hashtag Monitor");
    checkAndSendTweets(); // Run immediately
}

// Handle graceful shutdown (Ctrl+C)
process.on("SIGINT", () => {
    console.log("\nShutting down Twitter Hashtag Monitor...");
    process.exit(0);
});

// Start the service
startMonitoring();

If you are too lazy to read the entire thing, here is the full source code: https://github.com/Suvink/fetch-tweets-from-hashtag

Step 6: Package.json Scripts

Add some convenient scripts to your package.json:

{
  "name": "twitter-hashtag-monitor",
  "version": "1.0.0",
  "description": "Service to monitor Twitter hashtags and forward tweets",
  "main": "index.js",
  "scripts": {
    "start": "node index.js",
    "dev": "node index.js"
  },
  "dependencies": {
    "axios": "^1.5.0",
    "dotenv": "^16.3.1"
  },
  "keywords": ["twitter", "api", "monitoring", "hashtag"],
  "author": "Tony Stark",
  "license": "MIT"
}

Step 7: Testing Your Creation

Time to see if your digital creation comes to life.

npm start

If everything is configured correctly, you should see:

A log message indicating the bot is checking for tweets.
Either a "no tweets found" message or a successful Google Chat notification.
The process exits gracefully.

Important:
Twitter (X) API has very low rate limits (duh) for free accounts. You will only be able to search Tweets once every 15 minutes.

Step 8: Scheduling The Script on Choreo

Choreo is a fantastic platform for running scheduled tasks without the hassle of managing infrastructure. Here's how to deploy your task there.

Before following the below steps, make sure you commit your code to GitHub.

Step 8.1: Set Up Your Choreo Component

Log into Choreo: Head over to console.choreo.dev and sign in with your account.
Create a Component: Click on "Create Component" to start the magic.
Choose Component Type: Select "Scheduled Task" as your component type.
Link Your Repository: Connect your GitHub repository that contains the source code.
Configure Build Settings:
- Choose NodeJS as your Build Preset.
- Select your preferred Node.js version.
Click Create: Hit that create button and let Choreo work its magic

Step 8.2: Wait for the Build

Once your component is created, Choreo will start building your project:

Go to Build page from the left menu.
Watch the build process complete (grab another coffee while you wait).
Make sure the build status shows as successful.

Step 8.3: Configure and Deploy

Now comes the fun part. Deployment!

From the left menu, click on "Deploy".
Click the "Configure and Deploy" button.
Environment Configurations:
- In the pop-up drawer, click "Add Configuration"
- Add your environment variables from your .env file:
  - TWITTER_BEARER_TOKEN: Your Twitter API bearer token
  - GOOGLE_CHAT_WEBHOOK_URL: Your Google Chat webhook URL
  - HASHTAG: Your product hashtag (e.g., #choreoisawesome)
Click Next: Move to the scheduling configuration
Set Schedule:
- In the schedule drawer, set it to run every 15 minutes
- This ensures the task is compatible with Twitter API rate limits :(

Hit (just press!) that deploy button and watch your task come to life!

Step 8.4: Monitoring the Execution

Want to see your bot in action?

Go to Execute from the left menu
Check the execution history to see when your bot runs
View execution logs to see if tweets are being found and sent
Monitor for any errors or issues

Why Choreo is awesome for this:

No server management headaches
Built-in scheduling (no cron jobs needed)
Easy environment variable management
Execution history and logging out of the box
Scales automatically (though our bot is pretty lightweight)

Conclusion (The Part Where I Wrap This Up)

And there you have it! You've just built a Twitter monitoring bot that saves you from the endless scroll of social media doom. Your bot will dutifully watch Twitter for mentions of your product and deliver the good news (or constructive feedback) straight to your team's Google Chat.

No more FOMO about what people are saying about your product. No more manual searching through Twitter. No more wondering if that one customer actually liked your latest feature.

Just pure, automated, social media monitoring bliss.

Now go forth and monitor those hashtags! And maybe treat yourself to a cheesecake from Barista. You've earned it.

P.S. - If this helped you become the office hero, consider buying me a coffee or simply putting a reaction!

How to Build a Discord to Google Chat Bridge Bot (And Why Your Team Will Love You)

Suvin Nimnaka — Fri, 15 Aug 2025 14:37:32 +0000

Ever been in a meeting discussing important project updates in Google Chat while your devrel team drops fire memes in Discord? Yeah, me too. Today, we're fixing that communication chaos once and for all.

Image credits: Masters of AI & Automation

The Problem Many Modern Teams Face

Let's be honest. Your team probably lives in multiple chat apps. Marketing loves Slack, developers worship Discord, and management insists on Google Chat because "it integrates with our workspace." Meanwhile, important messages are getting lost in the shuffle faster than my motivation on Monday mornings.

Sound familiar? Well, grab your favorite caffeinated beverage because we're about to build something that'll make you the office hero.

What We're Building

We're creating a Discord bot that acts like a digital messenger pigeon between Discord and Google Chat. Here's what this little guy will do:

Listen to a specific Discord channel like it's eavesdropping at a coffee shop
Capture messages and format them nicely (because we're not animals)
Forward everything to Google Chat with rich formatting and direct links
Make your team think you're some kind of integration wizard

By the end of this tutorial, you'll have a bot that bridges these platforms seamlessly. No more "did you see what Janaka posted in Discord?" moments.

Before We Start Coding

Make sure you've got these obvious but important stuff.

Node.js (version 20 or newer - if you're still on Node 14, it's time to upgrade, friend)
NPM (comes with Node.js, like fries with a burger)
Discord Developer Account with bot creation privileges
Google Workspace Account (the kind that gives you access to Google Chat)
A Choreo Account: If you don't have one, sign up free at https://console.choreo.dev/signup

Step 1: Creating Your Discord Bot

First, let's bring a new Discord bot into existence:

Head over to the Discord Developer Portal
Click "New Application" and give it a name (I went with "PingKong" - King Kong, but for pinging across apps.)
Navigate to the "Bot" tab and click "Add Bot".
Important: Enable "Message Content Intent" - this is like giving your bot permission to actually read what people are saying.
Copy that bot token (keep it secret, keep it safe).
In OAuth2 URL Generator, select "bot" scope and these permissions:
- Read Messages/View Channels
- Send Messages
- Read Message History
Use the generated URL to invite your bot to your server.

Pro tip: Your bot will show up offline initially - don't panic, it's not broken, just offline until we turn it up

Step 2: Setting Up Google Chat Webhook

Google Chat webhooks are surprisingly straightforward and probably the easiest thing to do in this tutorial:

Open Google Chat and find your Chat Space.
Click the space name → "Apps & integrations"
Click "Add webhooks"
Give it a name.
Add an avatar if you're feeling fancy.
Hit "Save" and copy that webhook URL

Step 3: Project Setup

Time to create our project structure:

Create a new directory for the project home.

mkdir discord-to-gchat-bot
cd discord-to-gchat-bot

Initialize a new Node project.

npm init -y

Install our dependencies.

npm install discord.js axios dotenv typescript @types/node
npm install -D typescript ts-node

Set up TypeScript.

npx tsc --init

What we just installed:

discord.js - The library that connects your bot to Discord.
axios - For making HTTP requests.
dotenv - Keeps our secrets safe in environment variables.
typescript - Because we're professionals who like type safety.

Step 4: TypeScript Configuration

Update your tsconfig.json with these settings:

{
  "compilerOptions": {
    "target": "ES2020",
    "module": "CommonJS",
    "outDir": "./dist",
    "rootDir": "./src",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true,
    "resolveJsonModule": true
  },
  "include": ["src/**/*"],
  "exclude": ["node_modules", "dist"]
}

This configuration basically tells TypeScript: "Compile our code to ES2020, be strict about types, and don't include node_modules in compilation" (because that would be chaos).

Step 5: Environment Variables

Create a .env file in your project root:

DISCORD_TOKEN=your_discord_bot_token_here
GOOGLE_CHAT_WEBHOOK_URL=your_webhook_url_here
TARGET_CHANNEL_ID=discord_channel_id_to_watch

Getting your Discord channel ID: Enable Developer Mode in Discord settings (Settings → Advanced), then right-click any channel and select "Copy ID".

Security note: Never commit your .env file to version control. It's like posting your passwords on a billboard.

Step 6: Type Definitions

Create src/types.ts:

export enum BOT_EVENTS {
    READY = "ready",
    MESSAGE_CREATE = "messageCreate",
    ERROR = "error",
}

export interface EnvironmentVariables {
    DISCORD_TOKEN: string;
    GOOGLE_CHAT_WEBHOOK_URL: string;
    TARGET_CHANNEL_ID: string;
}

export interface GoogleChatPayload {
    cardsV2: {
        cardId: string;
        card: {
            header: {
                title: string;
                subtitle?: string;
                imageUrl?: string;
                imageType?: "CIRCLE" | "SQUARE";
                imageAltText?: string;
            };
            sections: {
                header?: string;
                widgets: {
                    decoratedText?: {
                        topLabel?: string;
                        text: string;
                        startIcon?: {
                            knownIcon?: string;
                            iconUrl?: string;
                        };
                    };
                    textParagraph?: {
                        text: string;
                    };
                    buttonList?: {
                        buttons: {
                            text: string;
                            onClick: {
                                openLink?: {
                                    url: string;
                                };
                            };
                        }[];
                    };
                }[];
            }[];
        };
    }[];
}

What's happening here:

We're defining the structure for Google Chat's card format (it's like HTML but in JSON form). For more info, refer to the Google Chat Cards Documentation.
TypeScript will yell at us if we try to use the wrong structure (which is good!)
Think of interfaces as contracts - they define what shape our data should have

Step 7: The Main Event - Building Our Bot

Create src/server.ts - this is where the magic happens:

import { Client, GatewayIntentBits, Message, TextChannel } from "discord.js";
import axios from "axios";
import * as dotenv from "dotenv";
import { BOT_EVENTS, EnvironmentVariables, GoogleChatPayload } from "./types";

// Discord's logo - because branding matters
const discordLogoUrl = "<REPLACE_WITH_A_URL_TO_DISCORD_LOGO>";

dotenv.config(); // Load our secret variables

// This function makes sure we have all our required environment variables
// Think of it as a pre-flight checklist
const validateEnv = (): EnvironmentVariables => {
    const { DISCORD_TOKEN, GOOGLE_CHAT_WEBHOOK_URL, TARGET_CHANNEL_ID } = process.env;

    if (!DISCORD_TOKEN || !GOOGLE_CHAT_WEBHOOK_URL || !TARGET_CHANNEL_ID) {
        throw new Error("Missing required environment variables - check your .env file!");
    }

    return { DISCORD_TOKEN, GOOGLE_CHAT_WEBHOOK_URL, TARGET_CHANNEL_ID };
};

const env = validateEnv();

// Create our Discord client with the right permissions
const client = new Client({
    intents: [
        GatewayIntentBits.Guilds,           // Access to server info
        GatewayIntentBits.GuildMessages,    // Read messages
        GatewayIntentBits.MessageContent    // Actually see message content
    ],
});

Now for the heart of our bot - the message forwarding function:

/**
 * This function takes a Discord message and formats it nicely for Google Chat
 */
async function sendToGoogleChat(discordMessage: Message): Promise<void> {
    try {
        let channelName: string;
        let threadTitle = "";

        // Handle different channel types (because Discord has many flavors)
        if (discordMessage.channel.isThread()) {
            const thread = discordMessage.channel;
            const parentChannel = thread.parent;

            if (parentChannel) {
                channelName = parentChannel.name;
                threadTitle = thread.name;
            } else {
                channelName = thread.name;
            }
        } else {
            channelName = (discordMessage.channel as TextChannel).name;
        }

        // Extract the details from the message
        const username = discordMessage.author.username;
        const avatarUrl = discordMessage.author.displayAvatarURL();
        const messageContent = discordMessage.content;

        // Create a direct link back to the original message
        // It's like leaving breadcrumbs, but digital
        const messageLink = `https://discord.com/channels/${discordMessage.guild?.id}/${discordMessage.channel.id}/${discordMessage.id}`;

        // Build our fancy Google Chat card
        const payload: GoogleChatPayload = {
            cardsV2: [
                {
                    cardId: `discord-message-${discordMessage.id}`,
                    card: {
                        header: {
                            title: "New Message from Discord",
                            subtitle: threadTitle || channelName,
                            imageUrl: discordLogoUrl,
                            imageType: "CIRCLE",
                            imageAltText: "Discord logo",
                        },
                        sections: [
                            {
                                widgets: [
                                    {
                                        decoratedText: {
                                            topLabel: "Posted by",
                                            text: username,
                                            startIcon: {
                                                iconUrl: avatarUrl,
                                            },
                                        },
                                    },
                                    {
                                        textParagraph: {
                                            text: messageContent || "(No text content - probably an emoji battle)",
                                        },
                                    },
                                    {
                                        buttonList: {
                                            buttons: [
                                                {
                                                    text: "View in Discord",
                                                    onClick: {
                                                        openLink: {
                                                            url: messageLink,
                                                        },
                                                    },
                                                },
                                            ],
                                        },
                                    },
                                ],
                            },
                        ],
                    },
                },
            ],
        };

        // Send it off to Google Chat
        await axios.post(env.GOOGLE_CHAT_WEBHOOK_URL, payload, {
            headers: {
                "Content-Type": "application/json",
            },
        });

        console.log(`Message forwarded from ${username} in ${channelName} ✅`);
    } catch (error) {
        console.error("Error sending to Google Chat:", error);
        // In production, you might want to add retry logic here
    }
}

Finally, let's set up our event listeners:

// Listen for new messages (this is where the magic happens)
client.on(BOT_EVENTS.MESSAGE_CREATE, async (message: Message) => {
    // Skip DM messages - we're only interested in server messages
    if (!message.guild) return;

    // Ignore bot messages (including our own) - prevents infinite loops
    if (message.author.bot) return;

    // Only process messages from our target channel or its threads
    const channelId = message.channel.id;
    const parentId = message.channel.isThread() ? message.channel.parentId : null;

    if (channelId !== env.TARGET_CHANNEL_ID && parentId !== env.TARGET_CHANNEL_ID) return;

    // Forward the message to Google Chat
    await sendToGoogleChat(message);
});

// When the bot successfully connects
client.on(BOT_EVENTS.READY, () => {
    console.log(`🤖 Bot logged in as ${client.user?.tag}!`);
    console.log(`👀 Monitoring channel ID: ${env.TARGET_CHANNEL_ID}`);
    console.log(`🚀 Ready to accept messages!`);
});

// Handle errors gracefully
client.on(BOT_EVENTS.ERROR, (error: Error) => {
    console.error("Discord client error:", error.message);
    // In a real app, you might want to restart the bot or alert administrators
});

// Start the bot
client.login(env.DISCORD_TOKEN).catch((error) => {
    console.error("Failed to login:", error.message);
    process.exit(1);
});

Step 8: Package Scripts

Update your package.json scripts section with the following:

{
  "scripts": {
    "build": "tsc",
    "start": "node dist/server.js",
    "dev": "tsc && node dist/server.js"
  }
}

Note: These are pretty standard TypeScript stuff.

Step 9: Launch Time! 🚀

Build and run your bot:

# Compile TypeScript to JavaScript
npm run build

# Start the bot
npm start

If everything works, you should see your bot come online in Discord and start monitoring your channel. Send a test message and watch it appear in Google Chat like magic!

Taking It a Step Further

Filter Messages by Keywords

Want to only forward important messages? Add some filtering.

// Only forward messages containing "urgent" or "important"
const keywords = ['urgent', 'important', 'breaking'];
if (!keywords.some(keyword => message.content.toLowerCase().includes(keyword))) {
    return;
}

Monitor Multiple Channels

Replace single channel monitoring with multiple:

const targetChannels = env.TARGET_CHANNEL_ID.split(',');
if (!targetChannels.includes(channelId) && !targetChannels.includes(parentId)) {
    return;
}

Deploying the Bot

WSO2's Choreo is a developer-friendly cloud platform that makes deploying applications as easy as clicking a button. Let's walk through deploying our Discord bot as a Webhook component on Choreo.

Step 1: Commit Your Code to GitHub

You already know what to do here :)

Step 2: Create a Webhook Component

Click "Create Component" in your project.
Select Component Type: Choose "Webhook" from the component types. You might want to click "View All Component Types" to find this.
Connect Your Repository:
- Select "GitHub" as your source
- Authorize Choreo to access your repositories
- Choose the repository containing your bot code
Setup the Component:
- Set the Build Preset to Node.js
- Set the Language Version to 20.x.x
Click Create and Deploy.

For more information, refer to Develop a Webhook documentation on Choreo.

Step 3: Configure Environment Variables

This is where we safely store our Discord token and webhook URL:

In your component, go to the "DevOps" tab from the left menu.
Click on "Configs & Secrets" in the left sidebar.
Click + Create.
Set the type of the Configuration as "Environment Variables" and mark it as a secret.
Give the configuration a Display Name: Mine is ping-kong-configs.
Add your environment variables one by one. After adding each, click Add.
Click Create to create the configutation group and save it.

For more information, refer to Manage Configurations and Secrets documentation on Choreo.

Some Basic Troubleshooting Steps If Things Go Wrong

Bot shows offline?

Double-check your Discord token
Verify the bot has proper server permissions

No messages forwarding?

Confirm your TARGET_CHANNEL_ID is correct
Make sure "Message Content Intent" is enabled
Check that the bot can read the target channel

Google Chat webhook failing?

Verify your webhook URL is still valid
Check if the webhook was removed from the Chat space

TypeScript compilation errors?

Run npm run build to see detailed error messages
Make sure all dependencies are installed

Wrapping Up

Congratulations! You've just built a communication bridge that would make you a hero at work. Your team can now stay connected across platforms without missing important messages.

This project demonstrates the power of APIs and webhooks for platform integration. With this foundation, you could do more cool stuff like:

Add bidirectional messaging
Support more message types (images, reactions, etc.)
Create bridges to other platforms like Slack or Microsoft Teams
Add message threading and advanced formatting

The best part? Your team will think you're some kind of integration wizard, when really you just know how to make different APIs play nicely together.

Now go forth and bridge those communication gaps! And remember: with great power comes great responsibility to not spam your teammates with bot messages. 😉

P.S. - If this helped you become the office hero, consider buying me a coffee or simply add a reaction. If it broke everything... well, that's what version control is for!

Redis Headless Service vs. Cluster IP Service: Which one should you use?

Suvin Nimnaka — Tue, 18 Mar 2025 17:07:18 +0000

If you’ve ever tried to set up a Redis cluster in Kubernetes, you’ve probably stumbled upon two types of services: the ClusterIP service and the Headless service. At first glance, they might seem like two sides of the same coin, but trust me, they’re not.

What’s a Redis Cluster?

Before we get into the services, let’s quickly recap what a Redis cluster is. Redis cluster is a distributed version of Redis that allows you to shard your data across multiple nodes automatically. It’s like having a team of Redis instances working together, each handling a portion of the data. This setup gives you high availability, fault tolerance, and the ability to scale horizontally. For more info on the Redis cluster, see Redis documentation.

In my local K8s cluster, I’ve deployed a Bitnami Redis cluster. When I do a kubectl get pods -n redis, it shows me 6 pods because I have configured the cluster to have 3 master nodes and one slave node each.

Now, let's check what are the services created for the Redis cluster with kubectl get svc -n redis:

It lists three services: redis-cluster (also known as the Cluster IP service), redis-cluster-headless, and redis-cluster-metrics. As the name suggests, the metrics service is used to expose Redis cluster metrics for monitoring.

In this blog, we’ll focus on the headless service and the cluster IP service.

The Cluster IP Service

The cluster IP service, or in my example, the redis-cluster service is a standard Kubernetes service that provides a single, stable IP address for accessing a set of pods. It load-balances traffic across the pods, making it easy to use for basic operations. When a client connects to this service, Kubernetes load-balances requests across the Redis nodes making it a straightforward method for simple use cases.

While the cluster IP service is easy to use, it has some limitations when it comes to a Redis cluster.

Redis cluster uses MOVED and ASK redirections to make sure the commands are routed to the correct node. In a cluster setup, each node is responsible for a specific range of hash slots. The hash slot for a given key is determined using the CRC16 algorithm, with the total number of hash slots being fixed.

For example, in my Bitnami Redis cluster, let's assume that the master nodes handle the following ranges:

Node 1: 0–5460
Node 2: 5461–10922
Node 3: 10923–16383

If a key falls into hash slot 1234, it belongs to Node 1. However, when a client sends a command to store this key, it cannot directly connect to Node 1. The cluster IP service load balances the request and forwards it to a random pod. If the selected pod doesn’t serve the required hash slot, it responds with MOVED or ASK, instructing the client to reach the correct node.

When the client retries to connect to the correct node, it again connects via the cluster IP service, but since the service is load-balanced, the request is sent to another random pod. This cycle continues, preventing a direct connection to the intended node.

Click here for the full quality image.

The Headless Service

Unlike the cluster IP service, the headless service is designed to expose the individual IPs of your Redis pods, allowing clients to connect directly to the Redis nodes as needed.

If you look at the earlier image showing the list of services, you’ll notice that the headless service doesn’t have an assigned IP. Instead, when a client queries its DNS name (e.g.: redis-headless.namespace.svc.cluster.local), it gets back the IP addresses of all Redis pods in the cluster. The client can then connect to one of these nodes and use the CLUSTER NODES or CLUSTER SLOTS command to retrieve the full cluster topology. This provides key details like node roles (master or slave) and hash slot assignments, allowing the client to map out the cluster.

With this information, when a client needs to store a key, it can determine which node is responsible for that key and connect directly using the headless service—ensuring efficient and accurate routing of requests.

Which service should I use?

If you’ve tried setting up a service that connects to a Redis cluster using a Redis client, you might have run into connection issues when using the cluster IP service. That’s because most Redis clients (if not all) are designed to understand the cluster topology and send commands directly to the right node, avoiding redirections.

So, if you’re connecting to a Redis cluster from a client, you need to use the headless service.

However, if you’re just running simple operations and performance isn’t a concern—like testing the Redis cluster from the CLI—the cluster IP service will work just fine.

That’s it for this post! If you have any questions, drop them in the comments. Thanks for reading!

Coding Authentication? Stop now and let Choreo manage it.

Suvin Nimnaka — Wed, 27 Dec 2023 19:16:17 +0000

As a developer, you might have come across situations where you want to add authentication to a web app but it takes so much time/effort to do so writing all the code and managing protocols that you kind of wished there was an easy way. Well, Choreo's Managed Authentication lets you add authentication to your web app with a few clicks and a few lines of code easily.

Let's see how.

Note: Choreo's managed authentication is currently available only for React, Angular, and Vue.js web applications.

Prerequisites

A React app
A GitHub Account
A Choreo Account (Create an account here. It's FREE)
Basic understanding of React JS

Step 1: The Code

Once you enable Managed Authentication (which we will be doing in step 2), you need to redirect your application users to the respective login and logout paths for them to authenticate.

Configure Login

To implement the login functionality, all you have to do is, redirect the user to the /auth/login path. Once redirected, Choreo will show a login form and users can use their credentials to log in.

Let's implement this in a sample app.

import React from 'react';
import { Link } from "react-router-dom";

function App() {
  return (
    <div className="App">
      {/* Vanilla JS */}
      <button onClick={() => { window.location.href = "/auth/login" }}>Login</button>
      {/* React Router v6 */}
      <Link to="/auth/login">Login</Link>
    </div>
  );
}

export default App;

If you are using React Router to handle navigation, you can use the respective navigation components offered by the React Router DOM. For this tutorial, we will be using vanilla JS.

Read user information

Once the user is logged in, you may need to access information like the user's name, email, etc. Choreo sends this information encoded in a cookie (named userinfo) upon successful login. We can extract the information using a cookie parsing library. For this example, we will be using js-cookie library.

You can execute npm i js-cookie command from your terminal to install the library.

import React, { useState, useEffect } from 'react';
import Cookies from 'js-cookie';

function App() {
  const encodedUserInfo = Cookies.get('userinfo');
  const [userInfo, setUserInfo] = React.useState(null);

  useEffect(() => {
    if (!encodedUserInfo) return;
    // Read the cookie and set it to the state.
    const userInfo = JSON.parse(atob(encodedUserInfo))
    if (userInfo) {
      const info = JSON.stringify(userInfo);
      localStorage.setItem('userinfo', info);
      setUserInfo(info);
      Cookies.remove('userinfo', { path: '/' })
    }
  }, [encodedUserInfo]);

  return (
    <div className="App">
      <button onClick={() => { window.location.href = "/auth/login" }}>Login</button>
    </div>
  );
}

export default App;

In this example code, first, we use the js-cookie library to read the userinfo cookie and then we set the information to the local state as well as to the local storage for persistence. After that, we clear the cookie (or biscuit if you're British).

Now, at this point, we can modify our code a bit to show the user's username if authenticated and if not, we'll show the login button.

import React, { useState, useEffect } from 'react';
import Cookies from 'js-cookie';

function App() {
  const encodedUserInfo = Cookies.get('userinfo');
  const [userInfo, setUserInfo] = React.useState(null);

  useEffect(() => {
    if (!encodedUserInfo) return;
    // Read the cookie and set it to the state.
    const userInfo = JSON.parse(atob(encodedUserInfo))
    if (userInfo) {
      const info = JSON.stringify(userInfo);
      localStorage.setItem('userinfo', info);
      setUserInfo(info);
      Cookies.remove('userinfo', { path: '/' })
    }
  }, [encodedUserInfo]);

  return (
     <div className="App">
      {
        userInfo ? <div>
          <h1>Welcome {userInfo.username}</h1>
        </div> :
          <button onClick={() => { window.location.href = "/auth/login" }}>Login</button>
      }
    </div>
  );
}

export default App;

Configure Logout

Similar to the login, we have to redirect the users to auth/logout path to log a user out. But for logout, we have to redirect the user with the session hint parameter which we can find in the 'session_hint cookie. This cookie is also set when the user is successfully authenticated. Let's add that code to our example.

import React, { useState, useEffect } from 'react';
import Cookies from 'js-cookie';

function App() {
  const encodedUserInfo = Cookies.get('userinfo');
  const [userInfo, setUserInfo] = React.useState(null);

  useEffect(() => {
    if (!encodedUserInfo) return;
    // Read the cookie and set it to the state.
    const userInfo = JSON.parse(atob(encodedUserInfo))
    if (userInfo) {
      const info = JSON.stringify(userInfo);
      localStorage.setItem('userinfo', info);
      setUserInfo(info);
      Cookies.remove('userinfo', { path: '/' })
    }
  }, [encodedUserInfo]);

  const handleLogout = async () => {
    // Read the cookie
    const sessionHint = Cookies.get('session_hint');

    // Clear session data
    Cookies.remove('userinfo', { path: '/' })
    localStorage.clear();

    // Redirect the user
    window.location.href = `/auth/logout?session_hint=${sessionHint}`;
  }

  return (
    <div className="App">
      {
        userInfo ? <div>
          <h1>Welcome {userInfo.username}</h1>
          <button onClick={handleLogout}>Log Out</button>
        </div> :
          <button onClick={() => {
            window.location.href = "/auth/login"
          }}
          >
            Login
          </button>
      }
    </div>
  );
}

export default App;

To explain the handleLogout function, first, we read the session_hint cookie. Then we clear the user information we persisted in the browser for better security. Lastly, we direct the user to the auth/logout path with the session hint as a query parameter.

🎉 Congratulations. Now you have an app with authentication enabled. Still, there's one more step to be done.

Step 2: Host the code on Choreo.

To complete this step, you need to have you source code committed to a GitHub (public) repository and you need to log into your Choreo Console.

Create a WebApp Component

Once you are logged in to the Choreo Console, select the Web Application component and create a new web app.

Enter a name for the component and connect your GitHub repository to the component. From the buildpack section, choose "React" buildpack as we are creating a React Web App.

In the build configurations, input your build command (default: npm run build), build path (default: /build) and Node.js version. Finally, click on Create button.

Build the web application

After the component creation, navigate to the "Build" area of the Choreo Console.

Click on Build, Choose the latest commit of your GitHub repository and build it. It will take some time for the application to be built so in the meantime, feel free to explore the Choreo Console and see what it can do for you!

Deploy the web application

Once the web app is built, navigate to the Deploy area from the left navigation menu.

From the "Set up" area, click on "Configure & Deploy" button to deploy the web application.

From the right drawer, just click next because we are not mounting any configurations for this web app and then you will see the Authentication step. You can already see that "Managed Authentication with Choreo" is enabled.

In this menu, we have to configure the Post Login Path, Post Logout Path and the Error Path.

Post Login Path - The relative path that the application will be redirected to on successful sign-in. In our example, we used the same page to display the user's info as well as to handle login/logout. So we will use / as the Post Login Path.
Post Logout Path - The relative path to which Choreo redirects you on successful sign-out. For the same reason as above, we will use / for this.
Error Path - The relative path to which Choreo redirects you when an error occurs during a redirection. By default, Choreo has a built-in error page to display errors. So we can leave this blank and let Choreo take care of that.

Configure Users

To test the authentication settings we implemented, we can quickly add a demo user in the same "Authentication Settings" step. Click on the Create button and you can create a demo user with a strong password.

After creating the demo user, click on the "Deploy" button to deploy the app. Again, it will take a moment for the app to get deployed. Once deployed, you can click on the Web App URL on the Development Environment card and explore the app we created.

Step 3: Try out a flow

Click on the login button on the application. It will redirect you to the /auth/login path and you can see Choreo's default login page.

Add your demo user's credentials and click on "Sign In". After successful sign in, you will see "Welcome demouser" message and the logout button on the screen.

Add more users

When your app goes to production, you need to add more users than the demo user we created. To do that, go to the Choreo Console, navigate to Organization Settings > Application Security > Identity Providers and Click the "Manage" button on the "Choreo built-in Identity Provider". From there, you can download the CSV template for the users, fill it and upload it to the console.

That's it folks!

Conclusion

In this tutorial, we implemented authentication functionality to a React JS web application using Choreo Managed Authentication. If you want to quickly start and experiment this feature, feel free to fork this repository and deploy it on the Choreo Console.

Choreo Managed Authentication can be used for more advanced scenarios and it has more features that we can user in an enterprise environment. We will discuss them in the next article.

Until then, Happy Coding!

Understanding Istio: A Beginner's Guide to Service Mesh

Suvin Nimnaka — Thu, 16 Nov 2023 16:32:52 +0000

In the ever-changing world of modern software engineering, creating and managing applications with many moving parts can feel a bit like conducting a symphony. Imagine you're Hans Zimmer and your application is a musical masterpiece of the Pirates of the Caribbean, with each instrument representing a different microservice playing in harmony. Now, keeping this symphony in tune and ensuring every note is played just right becomes a complex challenge.

This is where Istio steps onto the stage. Istio is like the conductor for your microservices orchestra, making sure each component plays its part seamlessly. In simpler terms, Istio is a powerful tool designed to simplify the management of applications made up of many smaller, interconnected pieces.

Let's break it down in technical terms. Imagine that you have a web application with various services like user authentication, database access, and front-end rendering. As your user base grows, so does the complexity of managing these services. Istio comes to the rescue by providing a set of tools that help you manage traffic, enhance security, and gain insights into what's happening behind the scenes.

But what's a service mesh and what does Istio have to do with it?

In simple terms, the service mesh is our Hans Zimmer. Just like Zimmer instructs his instrument players to play a symphony, the service mesh takes care of managing and optimizing the communication pathways between services. Istio offers tools and features to implement and manage this service mesh, ensuring that your software's performance is orchestrated smoothly and securely. (It's open source!)

How Istio works:

The Istio architecture can be explained in two main sections:

The Data Plane
The Control Plane

Istio Data Plane

The Data Plane is the operational heart of Istio, and it consists of a network of sidecar proxies, typically Envoy proxies, that are injected alongside each of your services. These sidecar proxies act as messengers, carrying out the instructions from the conductor (Control Plane) to ensure seamless communication between services.

If we go back to our Hans Zimmer example, each of the players in Zimmer's orchestra has a dedicated trainer. This trainer runs around whispering instructions and ensuring the player's performance aligns with the overall symphony. Similarly, the envoy proxies act as the trainers for the services, managing traffic, enforcing policies, and providing vital information about what's happening within each service.

Image Credits: Istio

Istio Control Plane

The Control Plane in Istio serves as the command center, overseeing the entire operation of your service mesh. It consists of three principal components, each playing a distinct role in ensuring your software's performance is orchestrated with precision.

Image Credits: Istio

1. The Galley

The galley component is Istio's configuration management, distribution and processing component. In a Hanz Zimmer show, there is a master choreographer backstage who is responsible for all the amazing dances on the stage. They may not show themselves on the stage, but they make sure that every dancer is ready and follows the script. Similarly, the galley receives the configuration file from the developer with instructions on how to configure the service mesh and hands it over to the next component; the Pilot.

2. The Pilot

Istio Pilot is a critical component within the Istio service mesh architecture, serving as the navigation system that guides the various services through the ocean of microservices. The pilot receives the configuration from the Galley and then converts it to Envoy configurations and will distribute it to each of the Envoy proxies in the network. This is just like Zimmer ensures each musician in his orchestra knows when to play and how loud to be.

3. The Citadel

Citadel plays a crucial role in Istio's security features, providing a robust infrastructure for securing communication within the service mesh. It provides each of these services with strong identities and generates certificates so that services can trust each other and communicate confidentially via mutual TLS (mTLS). In a Zimmer concert, this is something like the backstage pass that all the players get. The pass ensures that only authorized performers can access the backstage areas.

To put all these things together, it can be illustrated like this.

Image Credits: Istio

or something like this :p

Why Istio?

Istio ensures that organizations deliver decentralized applications at scale by simplifying network operations such as inter-service traffic management, encryption, authorization, troubleshooting, auditing, etc.

According to solo.io, Istio provides the following capabilities beyond what plain Kubernetes provides:

Quoting from solo.io,

1. Cloud native application security — you can focus on application-level security with strong identity-driven authorization, authentication, and encryption.

2. Efficient traffic management— achieve granular control over traffic and network behavior using rich routing rules, failover, retries, and error injection. In post-production testing, the Chaos Monkey integration allows SREs to inject faults and delays to improve resilience.

3. Service mesh monitoring — Itsio provides service-level visibility so you can track, monitor, and troubleshoot issues. Without fine-grained details, bottlenecks take a long time to resolve. A service mesh makes it easy to disable failed services and replicas and maintain API responsiveness.

4. Easy deployment with Kubernetes — Istio offers network controls and visibility for modern and traditional workloads, including virtual machines and containers.

5. Simplified load balancing — advanced features can automate load balancing, provide client-based routing, and support canary deployments.

6. Policy enforcement —a configuration API and policy layer help enforce policies with access control, quotas, and rate limits.

That's about it folks! Hope y'all had a brief idea about what service mesh is and how Istio works. If you're wondering why Hans Zimmer was the highlight of this blog, please spare some time to watch Bastille, Hans Zimmer - Pompeii MMXXIII! It is amazing.

If you have any questions or clarifications or have some extra points to add to this article, please drop them in the comments. I'm happy to read them and get back to you.
Happy coding!

OIDC Authentication for Express Apps with Asgardeo

Suvin Nimnaka — Sat, 30 Apr 2022 03:15:41 +0000

In my previous article, I discussed how we can use Asgardeo Node SDK to add authentication to your Express app. As I mentioned before, the process of using the Node SDK in an Express app is not straightforward because the Node SDK is a generic SDK which is compatible across any Node JS platform. In this article, I will show you how you can use the Asgardeo Express SDK to add authentication to your Express app easily.

TLDR;
Try the official sample app here.

Prerequisites

An Asgardeo organization. (You can create an organization upon registration at https://asgardeo.io/signup).
A Standard Based Application - Once you create an organization in the Asgardeo Console, you can create a Standard Based Application from the dashboard. (More info)

Projet Initialization
Create a new directory (a folder) and open the directory using your code editor. Open a terminal and type yarn init --y and it will initialize a new project and create a package.json file.

The next step is to install the dependancies.

yarn add @asgardeo/auth-express cookie-parser express

Then add Nodemon as a dev dependancy to hot reload your changes.

yarn add -D nodemon

Once you install Nodemon, modify the package.json and add "serve": "nodemon server.js" in the scripts section so we can use Nodemon to run the server.

Create an Express app
Create a new file and name it as server.js.
Then create a simple express server inside your server.js file. You can use the code below.

const express = require('express');
const cookieParser = require('cookie-parser');

//Define the Port
const PORT = 5000;

//Initialize Express App
const app = express();
app.use(cookieParser());

app.get("/", (req, res) => {
    res.send("Hello World");
});

//Start the app and listen on the PORT
app.listen(PORT, () => { console.log(`Server Started at PORT ${ PORT }`); });

After creating the server, run it using,

yarn run serve

Now if you navigate to http://localhost:5000, you should see a "Hello World" response from the server.

Add configuration for Asgardeo Authentication
Create a new file in the directory and name it as config.js. Inside this file, you need to specify the configuration for the Asgardeo Auth.

const config = {
   clientID: "YOUR_CLIENT_ID",
   clientSecret: "YOUR_CLIENT_SECRET",
   baseUrl: "YOUR_BASE_URL",
   appURL: "http://localhost:5000",
   scope: ["openid", "profile"]
};
module.exports = config;

Replace the clientID, clientSecret and baseUrl from the values you get from Asgardeo Console. Since we run our server in http://localhost:5000, we have to add it as the appURL.

Note:
Make sure you add localhost:5000 as an allowed origin and add localhost:5000/login as an authorized redirect URL in the console. We will discuss why should we authorize localhost:5000/login endpoint specifically later on.

Use the AsgardeoAuth middleware
Open the server.js file and import the middleware from the SDK.

const { AsgardeoExpressClient } = require("@asgardeo/auth-express");

Then instantiate the Asgardeo Express client with the config we created earlier.

AsgardeoExpressClient.getInstance(config);

Now you have to define three callback functions which are needed to initiate the middleware.

onSignIn - Handle a successful user sign in.
onSignOut - Handle a successful user sign out.
onError - Handle errors that might occur in the authentication process.

const onSignIn = (res, response) => {
  if (response) {
    res.status(200).send(response);
  }else{
    res.status(500).send("Something went wrong");
  }
};

const onSignOut = (res) => {
  res.status(200).send("Sign out successful");
};

const onError = (res, error) => {
  if(error){
    res.status(400).send(error);
  }else{
    res.status(500).send("Something went wrong");
  }
};

After defining the callback functions, use the middleware with the Express app we created.

app.use(
  AsgardeoExpressClient.asgardeoExpressAuth(onSignIn, onSignOut, onError)
);

That is all you have to do with the Express SDK to implement authentication. At this point, you can just navigate to http://localhost:5000/login and authenticate yourself. That brings me to explain why we added localhost:5000/login as an authorized redirect URL. The SDK itself is pre-configured to set the login endpoint to /login and to set the logout endpoint to /logout. So even though you didn't have to implement the logic for those 2 endpoints, you still need to authorize the endpoints in the console in order to function properly.

In case you don't like the pre-configured login and logout paths, you can always override the defaults in the config file. All you have to do is add another property to the config object as follows.

const config = {
   ...config,
   loginPath : "/customLogin",
   logoutPath: "/customLogout"
}

Don't forget to change the authorized redirect URL in the console if you're using a custom login and logout paths.

Implementing Protected Routes
In some use cases, you may want to protect a specific route with a login. To do this, Asgardeo Express SDK provides you with a simple middleware. All you have to do is, attach the isAuthenticated middleware to the route you want to protect.

app.get("/protected", isAuthenticated, async (req, res) => {
    res.status(200).send({
        message: "Hello from protected route!"
    });
});

The Asgardeo Express SDK has many features in addition to the basic login functions I described above. You can check them out at Express SDK GitHub repo. As always, feel free to reach me if you have any questions and you are welcome to make contributions to the SDK as well. Thanks for reading!

Add authentication to your Express app with Asgardeo

Suvin Nimnaka — Fri, 22 Apr 2022 04:09:13 +0000

When you are writing code for a project, at some point you're gonna have to come across user logins. To perform user specific tasks, to save user data and to do various kinds of stuff, user accounts is a mandatory feature in any system. But building a fully fledged login system is not so easy: especially having the flexibility to incorporate many kinds of login options (Email and password, Social Logins, Magic Links, etc) securely takes in a lot of effort. That is where Asgardeo by WSO2 comes into play.

TLDR;

Try the official sample app here.

Asgardeo is an IDaaS (Identity as a Service) empowering developers to implement secure and frictionless access. In a broader sense, it is a cloud-based solution that offers Identity and Access Management (IAM) capabilities to your applications easily. Now let's have a look at how we can integrate Asgardeo OIDC (Open ID Connect) authentication to our Express application. For that, we will be using Asgardeo Node SDK.

Prerequisites

An Asgardeo organization. (You can create an organization upon registration at https://asgardeo.io/signup).
A Standard Based Application - Once you create an organization in the Asgardeo Console, you can create a Standard Based Application from the dashboard. (More info)

Projet Initialization
Let's get started. First and foremost you're gonna have to create a new folder (or a directory) and initialize a new project. You can do that with yarn init --y and it will create a new package.json file for you. Now open your folder in your favourite code editor and we're ready to proceed.

Now you have to install all the dependancies.

yarn add @asgardeo/auth-node cookie-parser express uuid

To live reload the changes as we do, we need nodemon as a dev dependancy.

yarn add -D nodemon

After installing, add the following to your package.json file. (If you already have a scripts block, you can replace it)

"scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "serve": "nodemon server.js"
  }

Implement an Express app
Create a new file and name it as server.js. (You can choose whatever the name you want :p but make sure you change the name in the package.json as well!)
Then create a simple express server inside your server.js file. Something similar to this.

const express = require('express');
const cookieParser = require('cookie-parser');

//Define the Port
const PORT = 5000;

//Initialize Express App
const app = express();
app.use(cookieParser());

app.get("/", (req, res) => {
    res.send("Hello World");
});

//Start the app and listen on the PORT
app.listen(PORT, () => { console.log(`Server Started at PORT ${ PORT }`); });

Run the server with

yarn run serve

Now if you navigate to localhost:5000, you should see a "Hello World".

Integrate Asgardeo Authentication

Now that we have a working Express app, let's integrate Asgardeo authentication. First you need to create a new file and name it to config.js.
Inside that file, you need to specify the configuration for Asgardeo initialization.

const config = {
    "clientID": "YOUR_CLIENT_ID",
    "clientSecret": "YOUR_CLIENT_SECRET",
    "baseUrl": "YOUR_BASE_URL",
    "signInRedirectURL": "http://localhost:5000/login",
    "signOutRedirectURL": "http://localhost:5000",
    "scope": [ "openid", "profile" ],
};
module.exports = config;

Replace the clientID, clientSecret and baseUrl from the values you get from Asgardeo Console. The signInRedirectURL is the one a user should be redirected after the login. Keep in mind that the login endpoint and signInRedirectURL should be the same (You'll see why later).
Also make sure you add localhost:5000 as an allowed origin and add signInRedirectURL as an authorized redirect URL in the console.

Now open the server.js file and import the Asgardeo Node SDK and our config file. (Note: As an additional package, we need the uuid package as well.)

const { AsgardeoNodeClient } = require('@asgardeo/auth-node');
const { v4: uuidv4 } = require("uuid");
const config = require('./config');

Then initialize the AsgardeoNodeClient with the configuration.

const authClient = new AsgardeoNodeClient(config);

After that, we can move onto implementing the login endpoint.
Earlier, we declared our signInRedirectURL in the config file to a /login endpoint. So we'll implement that endpoint here.

app.get("/login", (req,res) => {

});

Inside the route handler, first you need to check if the incoming request is already authenticated or not. To do this, we can check the ASGARDEO_SESSION_ID cookie. If the request has a session ID, we can use that to re-authenticate the user and if not, we can create a new session ID and assign it to the request.

let userID = req.cookies.ASGARDEO_SESSION_ID;
if (!userID) {
    userID = uuidv4();
}

After that, you have to implement a callback function which will be used to redirect the user to the authorization URL. At the same time, you can send the user ID as a cookie back to the user. Make sure you use the httpOnly and sameSite attributes to prevent your cookie from cross-site request forgery (CSRF) attacks.

const redirectCallback = (url) => {
       if (url) {
           //Make sure you use the httpOnly and sameSite attributes to prevent from cross-site request forgery (CSRF) attacks.
           res.cookie('ASGARDEO_SESSION_ID', userID, { maxAge: 900000, httpOnly: true, sameSite:'lax' });
           res.redirect(url);
           return;
       }
  };

This function will take in the authorization URL string as a parameter and will redirect the user. Now we will use the signIn function from the SDK to authorize the user.

authClient.signIn(redirectCallback, userID, req.query.code, req.query.session_state, req.query.state).then(response => {
    //Just to see whats going on
    console.log(response);
    if (response.idToken) {
        res.status(200).send(response);
    }
});

Now let's figure out why we added the signInRedirectURL in the config file as same as the login endpoint (/login). The signIn method accepts 5 parameters namely redirectCallback, userID, code, session_state and state. When a user logs in for the first time, the /login endpoint will not get any values for code, session_state and state even though the signIn function expects the URL to have them. If those parameters are not present, the SDK will generate an authorization URL and passes it down to the redirectCallback function. From there, the user will be redirected to the Asgardeo Login Page and will securely authenticated. After doing so, as per our config file, the user will be redirected into the signInRedirectURL. This redirection will have the code, session_state and state URL parameters. Now the SDK knows this user has been redirected from the Asgardeo Login and will validate the code, session_state and state, then create a session in the Express app against the userID. There is a complicated process under the hood, but the user just have to call /login endpoint once and the SDK will handle the flow smoothly.

The final code block for the /login endpoint will look like this.

app.get("/login", (req, res) => {

    let userID = req.cookies.ASGARDEO_SESSION_ID;
    if (!userID) {
        userID = uuidv4();
    }

    const redirectCallback = (url) => {
        if (url) {
           //Make sure you use the httpOnly and sameSite attributes to prevent from cross-site request forgery (CSRF) attacks.
           res.cookie('ASGARDEO_SESSION_ID', userID, { maxAge: 900000, httpOnly: true, sameSite:'lax' });
           res.redirect(url);
           return;
       }
    };
    authClient.signIn(redirectCallback, userID, req.query.code, req.query.session_state, req.query.state).then(response => {
        console.log(response);
        if (response.idToken) {
            res.status(200).send(response);
        }
    });
});

Now you have a working login endpoint for your users 🥳. Let's add a log out endpoint as well.

Logging out is rather easy than implementing the log in. We'll start with defining a new route.

app.get("/logout", (req,res) => {

});

In the logout logic, first we need to check if the session ID cookie is present in the request. If so, we know this user has already been authenticated.

if (req.cookies.ASGARDEO_SESSION_ID === undefined) {
    res.send("Unauthenticated");
}

If the cookie is not present, we reject the logout request. But if it's present, we need to logout the user and delete the session.

authClient.signOut(req.cookies.ASGARDEO_SESSION_ID).then(response => {
    //Invalidate the session cookie
    res.cookie('ASGARDEO_SESSION_ID', null, { maxAge: 0 });
    res.redirect(response);
}).catch(err => {
    console.log(err);
    res.send(err);
});

We can extract the session ID from the cookie and then pass it on to signOut function. It will identify the relevant user's session and will destroy accordingly. After that, we need to invalidate the cookie. This can be done by setting the value to null sending back. So the code block for /logout endpoint will look like this.

app.get("/logout", (req, res) => {
    if (req.cookies.ASGARDEO_SESSION_ID === undefined) {
        res.send("Unauthenticated");
    } else {
        authClient.signOut(req.cookies.ASGARDEO_SESSION_ID).then(response => {
            //Invalidate the session cookie
            res.cookie('ASGARDEO_SESSION_ID', null, { maxAge: 0 });
            res.redirect(response);
        }).catch(err => {
            console.log(err);
            res.send(err);
        });
    }
});

Congratulations now you have implemented @asgardeo authentication to your Express app. The Asgardeo Node SDK comes up with more functions that will be useful to implement your next project so do check them out as well. Please check the official sample app here and you can try out the SDK including the functions we coded earlier in this article. That's it for now, thanks for reading. See you folks soon!

Easily add certifications to LinkedIn from your website.

Suvin Nimnaka — Sat, 18 Dec 2021 14:05:23 +0000

A few weeks back @lakindu and I were building a platform for @Richmond Live 's new training program. The students were given a digital certificate for the courses they completed at the Richmond Live's academy and once they log in, they can share their certificate across social media platforms or simply download the PDF certificate. In addition to that, students can maintain their public profile which can be used as a portfolio for their achievements at the academy.

While building this platform, we needed a feature to have a button that will add the certification directly to LinkedIn. Checked the official LinkedIn documentation but to keep things simple, we wanted a small NPM package that can do the job. Unfortunately we couldn't find anything that is flexible and stable enough to use in out application. We ended up using the hard way; building the button from the scratch.

After a few days we decided to create a package ourselves for people to use easily. So Linkedin-certification was born!

What does it do?

It will let you to add your certifications directly into LinkedIn from your website. (Not directly! You still need to confirm the details :wink)

How to install?

If you're using npm,

npm install linkedin-certification --save

or else if you're a yarn user,

yarn add linkedin-certification

How to use it?

First, import the package

import { LinkedinCertification } from "linkedin-certification";

Then use the imported component with your certification details.

<LinkedinCertification
  certificationName="My Sample Certification"
  organizationName="My Sample Organization"
  issuedMonth={12}
  issuedYear={2021}
  expirationMonth={3}
  expirationYear={2023}
  certificateId="29c2e87e-5c1c-11ec-bf63-0242ac130002"
  certificateURL="https://www.google.com"
  newTab={true}
/>

Thats it! You can see a button like this on your application upon saving.

The property list

Property	Type	Description
`certificationName`	`string`	The name of the certification. `[Required]`
`organizationName`	`string`	The name of the organizaion. `[Required]`
`issuedMonth`	`number`	Certification issued month
`issuedYear`	`number`	Certification issued year
`expirationMonth`	`number`	Certification expiry month
`expirationYear`	`number`	Certification expiry year
`certificateId`	`number`	Unique ID of the certification
`certificateURL`	`string`	URL for the certification
`newTab`	`boolean`	Set `true` to open the LinkedIn Certification window in a new tab
`customButton`	`React Node`	Lets you pass your own custom button.

YES you saw it right!

linkedin-certification lets you add your custom buttons instead of the default one that comes with the package! Got a really cool button with a bunch of animations? Or need a button that goes with your website theme? We got you! Use the customButton property and pass down your own button component.

Contributions are welcome!

If you come across any bugs or feature requests, please open an issue or send a pull request. I'm happy to improve this with your cool ideas!

Help me more!

If you like this package, please consider buying me a coffee so that I can keep improving this even further!

Thanks for reading folks! Happy coding!

E-Waste Admin Panel

Suvin Nimnaka — Thu, 07 Jan 2021 16:02:11 +0000

How it works

Admin panel shows you an overview of how the system works. It provides realtime numbers and charts so you can have an idea of how the system performs at a glance. Also these charts are downloadable so it is easy to make reports with these. I'm using chart.js to create these charts. It was easy to integrate and provides a good looking customizable charts.

Screenshots

If you have any concerns or suggestions for improvements, please let us know!