Until the modifications are introduced to production, smart companies take advantage of API testing and so do you. In both staging and production environments, API's must be checked to ensure that the software framework meets the specifications.
\nLet's discuss how, through how your team approaches your research plan, your team can get the benefits of API testing.
\nWhat is API Testing?\nApplication Programming Interface is often called as API. An API is a set of methods and procedures that developers \"open up\" to other programmers to have their applications communicate and interact with other applications. Once an API is built, it is necessary to test the interface to provide truly secure, reliable and scalable connections between platforms.
\nAPI testing helps identify early issues and is different from UI testing. An API receives requests and sends back responses through internet protocols including, HTTP and SMTP. API tests investigate applications that have varying API functionalities and vary the API call's parameters in different ways that verify functionality and expose failures.
\nAPI testing can be done on the below aspects:
\nFunctional Testing checks API's functionality, Takes payload in the form of JSON or XML and provides the response code and response body.\nLoad Testing checks the performance under the specific load and determines how much traffic the API can handle before being overloaded.\nSecurity Testing checks vulnerabilities like authentication and sensitive data is encrypted over HTTP and includes penetration testing validating authentication.
\nAdvantages of API testing during Software development
\n1. Time efficiency
\nAPI Testing doesn't require GUI to be ready and it can be performed way early in the development cycle. The Automated API tests provide much quicker test results and significantly accelerate development workflows; thus, it helps you speed up the feedback loop and catch issues faster.
\nIn addition to that, API tests are significantly less time-consuming when compared to UI Tests. UI Tests spend much time rendering and loading the web pages and interface elements, whereas can execute API tests in seconds. Let's take an example where a user needs to register and login from UI takes at least 3 to 5 minutes, whereas API testing takes less than 30 seconds.
\n2. Reduced costs
\nIt is very closely connected with time efficiency.
\nThe cost efficiency benefit is closely connected with the previous one. Automated API tests' increased execution speed leads to more effective/efficient resource consumption and lower overall testing costs.
\nAPI tests can be executed as early as the business logic is defined and before any GUI testing. So it will help you to identify the issue at the early stage. Early identification means the less expensive it is to fix it and Reduces the cost of Application changes. API testing enables the QA team to detect and resolve issues before they become a production problem, keeping project costs at bay.
\n3. Technology Independent
\nAPI tests are Language Independent, Since the data is interchanged using JSON or XML and compromised HTTP requests and HTTP responses. So the QA team is free to choose the language of their choice that supports these technologies((JavaScript, Java, Ruby, Python, PHP, etc.).
\n4. Greater tests stability
\nWhile GUI's are dynamic and may change to accommodate new requests from stakeholders and users, API interfaces are very much stable. APIs typically come with detailed documentation, and any changes are reflected there so that QA engineers can adjust their test suites timely. And due to this inherent stability, API tests are also much easier to maintain.
\n5. Improved test coverage
\nUnlike unit tests, automated API tests are generally broader in scope and detail. While unit tests are focused on the limited functionality of components within a single application, problems often arise at the intersection where one layer's scope ends and the other begins.
\nYou won't find these issues with unit tests, but API-level tests are specifically designed to verify that all system components function as intended. API testing helps uncover potential defects in the interfaces, servers, and databases, improving the overall software quality and contributing to better user experiences.
\nEfficiency gains associated with an API testing tool can include:
\nConclusion:\nAPI testing is recognized as a better fit for Continuous Testing in Agile methodologies. Not adequately tested APIs may cause issues at the API application and the calling application. It is a necessary test in software engineering.
\n","frontmatter":{"date":"February 12, 2021","updated_date":null,"description":"Communication between software components is handled by an API (Application Programming Interface). Discover the advantages of automated API testing.","title":"What is API Testing? - Discover the Benefits","tags":["Automation","API Testing","Agile","Benefits"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.680672268907563,"src":"/static/44fa40d81595c222eae816dc48759915/f571c/api-testing.png","srcSet":"/static/44fa40d81595c222eae816dc48759915/69585/api-testing.png 200w,\n/static/44fa40d81595c222eae816dc48759915/497c6/api-testing.png 400w,\n/static/44fa40d81595c222eae816dc48759915/f571c/api-testing.png 770w","sizes":"(max-width: 770px) 100vw, 770px"}}},"author":{"id":"Surendranath Reddy Birudala","github":"reddysuren","avatar":null}}}},{"node":{"excerpt":"In reaction to the Covid-19 pandemic, as offices closed, few of us knew that we would be working from home for months or forever, Many of us…","fields":{"slug":"/engineering/why-mfa-important/"},"html":"In reaction to the Covid-19 pandemic, as offices closed, few of us knew that we would be working from home for months or forever, Many of us set to continue the trend of working from home for the foreseeable future. With remote working set to become the “new normal” for many, it's important to make sure our systems are safe and secure.
\nIn today's digital world, consumers are using more and more web and mobile apps to access various services. These apps require the consumer to create accounts with usernames and passwords. This poses the threats for password breaches due to lack of strong passwords, common passwords, or re-used passwords for multiple sites.
\nBusinesses are looking for ways to protect their digital assets while validating their consumer's identities and at the same time providing a smooth user experience. Multi-factor Authentication (MFA) is the simplest and the most effective tool to provide another layer on top of the login credentials. After the consumer enters their login credentials, whether via email, phone number, username, or social profile, the consumer verifies the system with some other independent factor. Hence, it restricts any malicious attempt to access the system or service even if someone gets access to the consumer's password.
\nMulti-factor or Two-factor Authentication verifies the consumer's identity using one of the following factors:
\nThere are several MFA authentication methods available leveraging the above authentication factors to protect the consumer account. Businesses can use one or all of the following MFA authentication methods as per their business requirements.
\nThe PIN Authentication feature allows the consumer to set a PIN in addition to the password during registration. After the consumer enters their login credentials, the consumer will be asked to enter the PIN set at the time of registration. This is generally used in devices with physical interfaces like smartphones or PIN pad on the doors. Check our LoginRadius PIN Authentication method to know more.
\nPros: It is easy for consumers to remember and enter the four-digit PIN into the application, eliminating the need to have a device to complete the MFA.
\nCons: Brute forcing the PIN is easier than a password as the PIN is generally a combination of 4 digit numbers.
\nThe consumers are asked to answer some security questions at the time of registration. The security questions should be such that the answers are easy to remember for the consumers, hard to guess for someone else, and be consistent over time. The same security question(s) can be asked as a second factor of authentication to verify the consumer identity. This is used in web applications as you can type security answers quickly on the computer. LoginRadius allows its customers to configure security questions for authentication. Please see the LoginRadius Security Question Overview document for more details.
\nPros: You can easily set up the security questions as most of the services allow you to select the questions from a series of predefined questions. It does not require any additional hardware device.
\nCons: Other people can find out the answers from your social profiles or use social engineering, like phishing emails or phone calls. If they know you, they can also guess the answers to the security questions, e.g., your favorite color, etc. You need to memorize responses for the security questions if you have set the fictitious responses so that nobody can guess or find out.
\nAfter the consumers enter their login credentials, they receive an instant text message with a unique authentication code. The consumers are required to enter the code into the application to get access to their accounts. Visit LoginRadius SMS authentication to know more.
\nPros: MFA via SMS code is the most popular method due to its low cost and easy setup. It is also fast as the text arrives almost instantly.
\nCons: The code is sent over the telecom network, hence, poses the risk of SMS messages being intercepted or redirected. In this case, the consumer will still get the code and report it to the business if it is not he who tried to login into the application. If you have misplaced or don't have the device nearby, Or the device has run out of battery, you can't log in to the application. Some disreputable services can use your phone number for marketing and sales purposes.
\nConsumers receive the code over a phone call instead of receiving the text message.
\nPros: You can receive the call on your cell phones as well as on your landline phones.
\nCons: It requires phone network connectivity to receive the call.
\nLike SMS Authentication, once the consumer enters their login credentials, they receive a unique code in the email. Enter the code to complete the authentication process.
\nPros: You can access the code on any device, hence, removing the need to have a mobile phone nearby.
\nCons: You should avoid logging into your email account on public computers or while you're connected to an unsecured Wi-Fi hotspot.
\nInstead of sending a code, a push notification is sent directly to a secure application on the user's device, e.g., a mobile phone asking them to confirm an authentication attempt is made from another device. The consumer can approve or deny access by pressing a button on the device.
\nPros: It provides a better user experience as the consumer does not need to type the code.
\nCons: The push notifications can be compromised if the device is lost, stolen, or someone gets access to the device. Your phone should have access to the internet to complete the push notification. If you are logging from multiple devices or multiple times, you will get many notifications. Hence, you might ignore the authentication information like IP address, location, etc. In the push and approve it without thinking, can grant access to the malicious person.
\nThis requires the consumer to install an authenticator app, e.g., Google Authenticator, to their mobile devices. During registration, the consumers will scan a QR code from the website with the app. The app will auto-generate a Time-Based One Time Password (TOTP) that the consumer will have to enter after they've provided their login credentials. LoginRadius supports MFA via an authenticator app, e.g., Google authenticator.
\nPros: It gives an advantage over SMS Authentication as the code is not sent over the telecom network, but the device is required to be connected to the internet. You can scan the QR code by multiple devices to avoid getting locked out.
\nCons: The authenticator app generates the code with a very short validity, which results in entering invalid codes into your service. Some malware can steal MFA code directly from the authenticator app.
\nU2F is an open authentication standard that leverages encrypted security keys to verify the identity. The consumer needs to plug in a physical security device carrying encrypted security keys into a USB port after submitting their login credentials.
\nPros: This is one of the most secure MFA authentication methods as the device works with the registered site only and can't be digitally intercepted or redirected. Also, the devices don't store any personal information. The consumers can't be authenticated without the physical device.
\nCons: U2F keys require a USB port to plug in the device, making this an untenable solution for mobile devices or devices without USB ports. There is also a cost involved in purchasing these physical devices. Employees mostly use this within an enterprise as they are required to carry the physical device for login.
\nNote: The consumers are mostly provided a set of backup codes to complete the second factor in the event of the device being lost, stolen, or not being accessible. It is recommended to keep these backup codes securely.
\nThe consumer verifies the device's identity using Biometric factors like a Fingerprint, Eye scan, Facial recognition, or Voice recognition on the device. This is mostly used in mobile applications for authenticating the consumers on smartphones with biometric verification capability.
\nLoginRadius supports various forms of biometric authentication e.g. TouchID. You can leverage Any third-party biometric services to provide secondary forms of authentication to consumers.
\nPros: It is complicated to hack biometrics.
\nCons: You can only login into the devices with biometric verification capabilities. The registered services can misuse your biometrics. Once your biometrics are hacked, you can not use them for any applications in the future.
\nWhen the consumer tries to log in to a device, the device location is derived from its IP address or GPS. If the device's location is listed as allowable in the system, access to the system is granted. LoginRadius supports triggering actions based on the stored city, browser, or device. Please see the LoginRadius Risk Based Authentication document for more information.
\nPros: This provides the best user experience as it does not require additional devices or steps to complete MFA.
\nCons: You can only access the device in specific locations or devices.
\nYou can leverage any Multi-factor Authentication method to improve security over the traditional username and password authentication. But none of the MFA methods is 100% foolproof and should not be used as a single factor of account protection. Also, MFA causes the login process longer for the consumer. Hence, the choice of any or combination of MFA methods depends on your business requirements around security and user experience. Here are some recommendations:
\nLosing users on the signup page is wasting your marketing and growth budget because the signup page has a strong password requirement for ensuring security. If you remove complex password requirements, the user will use simple passwords that can be hacked easily. Balancing security and experience is the biggest challenge these days as People have a lot of options to try, and Hackers are ready if anything goes wrong.
\nPasswordless is a way to solve this dilemma, remove passwords means remove complex password requirement and security concerns both. To learn more about how and Why of passwordless authentication, read this - \"Passwordless Authentication: Securing Digital Identity\".
\nLet's talk about How passwordless can reduce the signup friction and how to make it more user friendly.
\nIn this tech era, we have a lot of online accounts on several apps, and the following password requirements are few examples to create a secure password:
\nSeriously, this all need to do by users to keep their account safe on your app! Password Managers are a solution, but they have their issues, installing their extensions and software, Device sync available with paid plans only, and so on.
\nBut Passwordless is the answer to it. It removes all password frictions and allows users to signup with a single click.
\nThe passwordless interface must be designed as a unified interface for authentication. Either use is new or existing, just let them use a single interface. If the user is new, internally create an account and log in and for registered users, start the user's session.
\nIt allows users not to remember if they are already registered or not. It reduces the number of clicks too.
\nIt can be implemented in mobile devices as one-tap authentication, which means the user needs to tap once and sign up the user and start the session.
\nIt's impossible to ask for any other information with a unified interface because we don't know the user is new or existing. So we have to use Progressive Disclosure UX principle to ask for more details based on the user's existence in the system.
\nProgressive disclosure always reduces the complexity. User's love to enter without providing huge details.
\nPasswordless can be an excellent approach to reduce user drops on the signup page with better UX practices. The most significant friction on the signup page is too many details and Complex Passwords. Remove them. Users will love it.
\nOn the signup page, you should include better messaging to motivate the user to sign up.
\n","frontmatter":{"date":"February 10, 2021","updated_date":null,"description":"How passwordless can be an excellent approach to reduce user drops on the signup page with better UX practices.","title":"Optimize Your Sign Up Page By Going Passwordless","tags":["Passwordless"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/7a8c854feaf3313197ca307e91c3fa54/ee604/open-source.png","srcSet":"/static/7a8c854feaf3313197ca307e91c3fa54/69585/open-source.png 200w,\n/static/7a8c854feaf3313197ca307e91c3fa54/497c6/open-source.png 400w,\n/static/7a8c854feaf3313197ca307e91c3fa54/ee604/open-source.png 800w,\n/static/7a8c854feaf3313197ca307e91c3fa54/3eac8/open-source.png 1127w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Ravi Teja Ganta","github":"ravitejag","avatar":null}}}},{"node":{"excerpt":"Many developers overlook imagery on the websites they develop. The website design starts with image placeholders instead of images. They…","fields":{"slug":"/engineering/image-colorizer-tool-kolorizer/"},"html":"Many developers overlook imagery on the websites they develop. The website design starts with image placeholders instead of images. They spend weeks creating it's structure and features. Then they spend some time on the content, and after that, the images come as the last step right before launching the website with the words \"Let's just put a random image of whatever, as long as it makes sense.\"\n
\nWhen this approach works for many websites since imagery is secondary content, in many cases, you need to involve the work of a designer or a photographer to get something unique to use free of copyright. When custom work is always encouraged, there is a space for the first approach. Whether you do not have a designer to rely on, or you want to ease the load off your design team, you can find copyright-free images on the web and use them in your projects.\n
\nAll seems fair until you realize that your website is starting to look like a circus. With every image and photo having different colors, the website is like an intersection without any traffic lights - everybody is doing whatever they want. There is no uniformity or harmony between all of the imagery. This might seem like a small problem initially, but it hurts your business in the long run.
\nAs your business struggles to create a consistent unified brand, people do not sense the authority and quality of your product and in the end, they go to someone else that seems to know what they are doing. And if you think, \"Not everybody is a designer, and most people would not notice this\", while it is true, some people would not care, but in most cases, people would start noticing this. All this will be happening subconsciously. They will not tell you precisely what is wrong, but they would feel less connection with your brand, which could make them leave in the long run if they find something that feels more right.\n
\nIf your product is selling car insurance, you want people to identify you as the leader, the main place to get everything you need for car insurance. To accomplish that, you need to build a strong brand around your product.
\nYou might be thinking right now: \"Sounds like I need an expensive designer to figure all of that out!\". When a great designer could take your brand to the next level, you can do something that will not cost you a dime. A great start to building a brand is making all the colors on the website as consistent as possible. I am sure you know how to make that in CSS with the headings, paragraphs, link colors, etc., it is a little more complicated for the images.\n
\nThis is where our little tool comes in - Kolorizer. This incredibly simple online tool will have a huge impact on your brand, whether you are kicking it off or simplifying and growing an existing one.\n
\nThe task is simple - to make colors in all the imagery on your website match your brand's colors. There are mostly two different ways of doing this in the design world: \"The overlay\" method and \"The changing of the base color\" method.
\nIn the \"The overlay\" method, the color overlay is simply applied on top of the image. While it is the easiest and quickest way of adding some brand colors to the images, it comes with some downsides. The image becomes darker and some other colors might still peek through, which is not great.
\n![](01.jpg \"Image created using \"The overlay\" method\")\nImage created using \"The overlay\" method\n
\nThe second, \"The changing of the base color\" method, is less common because it requires a few more steps. First, the image is converted to black and white, making every pixel in the image based on black color. So every single pixel is a percentage of black color. Now we can replace that black color with any of the dark colors you have in your brand, like dark blue or dark orange. And voila! Every pixel in our image is now based on that color, without any overlay that darkens the image and without any other colors peeking through the overlay. This does create a little problem: since we are basing our image on a dark color that is not black, the image is lighter and we have to adjust the brightness of the image a little bit to compensate for this. The amount depends on the image itself - some would be good right after the conversion, some would need to be darkened or lightened.
\n![](02.jpg \"Image created using \"The changing of the base color\" method\")\nImage created using \"The changing of the base color\" method
\nKolorizer is built using the second method, and most of the steps are done automatically.
\nDevelopers could tap into Google's search and maps services, as well as email, etc. Native applications served their purpose superbly and became the primo factor that propelled Android and iOS as the big two phone operating systems at the time, until the present day.
\nNative smartphone applications were so common that Apple coined the tagline \"There is an app for that\" and copyrighted it in 2009.
\nHowever, come the 2010s. Web technologies saw increasingly rapid growth. Server-side rendered web pages allow for the creation of full-fledged web applications that could offer business values beyond static information. The responsive design movement also enhances accessibility for these web apps across all platforms. It was also during this time that mobile applications became stagnant. Your phone started to have too many applications, and not all of them were equally useful. Some are thin clients to web services, which you could access using your mobile web browser instead.
\nRecognizing this, Progressive Web Applications, or PWA, came in to bridge the gap between native and web applications.
\nFirst and foremost, PWAs are web applications. They run in web browsers, but also usually in webviews on smartphones. Compared to traditional websites that you would visit with a conventional web browser, progressive apps tend to be a little more low key.
\nYou may see one through a direct URL, but more commonly through a desktop/home screen icon on your phone, which takes you to a webview hosting the application. By extension, PWAs are now also distributed through app stores, standing alongside native apps.
\nThe webview itself may also be without or with minimal menu bars to provide an impression close to navigating a native application. Furthermore, progressive applications usually come with some offline viewing capabilities, allowing you to interact with the app even when you are offline or in limited network availability. This is implemented using service workers that stand in between network requests and the user and handle caching as well as push notifications, providing a user experience similar to native app caching.
\nWith that in mind, the idea behind PWA is to create applications that would be most accessible, through the web, that also offers an experience as close to native applications as possible.
\nSuppose you are a new company looking to create a mobile application for your product. If you would like to distribute your app on all major mobile platforms - namely both iOS and Android - you would then have to go through the development and distribution process for both. First off, you will need to learn the language to develop Android applications (Java, Kotlin) and then iOS (Objective-C, Swift), have the correct hardware to test and develop.
\nThis process will have you relearn everything about one platform on the other. Once you finish the initial product, you will have to maintain both codebases moving forward to complete this.
\nWith a progressive app, the process becomes a lot simpler. Your application lives within a browser, and hence only needs to be supported by the browser standards. As of now, support for PWAs is available across major browsers: Google Chrome, Mozilla Firefox, Apple Safari, Microsoft Edge, and Firefox (for Android).
\nYour language is the language of the web: JavaScript. The choice is also yours to leverage the JavaScript platform you are most familiar with, be it React, Angular, or something completely different. The JavaScript codebase will then become the only codebase you need to maintain for the app.
\nAlongside this, you also gain the advantage in the availability of the application. With PWA, your app will be available on the web, accessible by users across many platforms, including all mobile devices that have browser support.
\nPWAs live on the web; this means you do not need to download and store many executables and assets on your device, saving you precious storage space if you are using the app on your phone. This is especially useful when the native version of the application is simply a portal to a web service, which serves to make API calls and present data based on the user data on the server only, without performing any device-specific actions. The functionality of these applications is not inhibited by the browser's sandbox and thus make for perfect PWA candidates.
\nPWAs are designed to be responsive. Even though this depends largely on the individual developer of the application, a well designed and developed PWA should, in theory, provide a consistent experience across devices. With native apps, a lot of effort will be required to ensure that the user experience is uniform across multiple platforms. And even then, certain platforms will impose their own set of requirements on the UI look-and-feel, as well as the functionality of the app.
\nProgressive apps are a creative solution to smooth out the differences between a native app and the web, but not necessarily replace native apps. While it inherits all the advantages and features of the web, there are still certain disadvantages that need to be considered when deciding between a progressive app or a traditional native app.
\nFor one thing, progressive apps are designed to be uniform across devices. This means it is not the technology's focus to make use of specialized features that are available only on select devices. Its feature set will be the lowest common denominator of the range of devices that it supports. With how diverse the feature sets are on modern devices like smartphones and tablets, with high-resolution cameras or fingerprint sensors, to name a few, it would be amiss for applications not to take advantage of these features. It follows that progressive apps are not ideal for specialized workflows, while their strength is in general purpose applications.
\nCompatibility is another big-ticket item. At a baseline level, PWA should be supported by all major browsers. However, platform differences still exist, where specific features are supported by one browser but not another, which will cause inconsistencies in behavior when the user switches from one device/platform to another. A prominent example of this being push notification support on iOS, which requires jumping through some hoops to make it work, as Apple does not support this directly. With that in mind, the subtle differences between browser support become a limitation similar to the difference between native app platforms itself.
\nFor applications to reach the hands of the users, it needs a distribution platform. For native applications, the answer to this is straightforward: Apps are distributed through the native app store, be it Google Play Store or iOS App Store. However, for PWAs, it is more complicated. Distribution can be as simplistic as passing around the application's URL, and anyone who knows the link can access the app. This method has the added advantage due to Google and other search engines/web crawlers naturally picking up the app URL and returning it as a search result.
\nHowever, this method is passive and requires the user to know the application beforehand. Developers might prefer the more traditional way of having the app listed in an app store, which is possible but requires them to jump through the same hoops as native applications, following all of the distributor guidelines, which removes its advantage compared to traditional apps.
\nSo with everything considered, should you go the route of the progressive app? We do not aim to give a concrete answer, but instead a suggestion: If your application can be made a PWA, it is a good idea to do so. At the current moment, progressive apps are an evolution of web apps. Compared to the feature set that users are already familiar with in native apps, progressive apps still trail behind.
\nThis means that if the scope of the application is complex enough, PWA may not provide you with enough tools to do the job. With that said, if your application can be fully implemented with the set of tools that PWA provides, then going this route may net you added benefits that are unique to progressive apps. Are progressive apps the future? It definitely has the potential, but a large part of that answer depends on whether we can leverage its platform to build productive solutions with it today.
\n","frontmatter":{"date":"February 04, 2021","updated_date":null,"description":"How do Native Apps compare to Progressive Web Apps, and which platform does your company use to communicate with your clients? read on!","title":"PWA vs Native App: Which one is Better for you?","tags":["Progressive App","PWA","JavaScript"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/ff88b75a03f86a1891a9545ba6dcd4c4/ee604/index.png","srcSet":"/static/ff88b75a03f86a1891a9545ba6dcd4c4/69585/index.png 200w,\n/static/ff88b75a03f86a1891a9545ba6dcd4c4/497c6/index.png 400w,\n/static/ff88b75a03f86a1891a9545ba6dcd4c4/ee604/index.png 800w,\n/static/ff88b75a03f86a1891a9545ba6dcd4c4/f3583/index.png 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Nathan Nguyen","github":"nathannguyenn","avatar":null}}}},{"node":{"excerpt":"This blog will help you get started on deploying your REST API in Kubernetes. First, we'll set up a local Kubernetes cluster, then create a…","fields":{"slug":"/engineering/rest-api-kubernetes/"},"html":"This blog will help you get started on deploying your REST API in Kubernetes. First, we'll set up a local Kubernetes cluster, then create a simple API to deploy.
\nThere are already a lot of free resources available explaining basic Kubernetes concepts, so go check those out first if you haven't already. This blog is intended for beginners but assumes you already have a basic understanding of Kubernetes and Docker concepts.
\nThere's a couple options for running Kubernetes locally, with the most popular ones including minikube, k3s, kind, microk8s. In this guide, any of these will work, but we will be using k3s because of the lightweight installation.
\nInstall k3d, which is a utility for running k3s. k3s will be running in Docker, so make sure you have that installed as well. We used k3d v4.0 in this blog.
\ncurl -s https://raw.githubusercontent.com/rancher/k3d/main/install.sh | bashSet up a cluster named test:
\nk3d cluster create test -p "80:80@loadbalancer"Optionally, check that your kubeconfig got updated and the current context is correct:
\nkubectl config view\nkubectl config current-contextOptionally, confirm that k3s is running in Docker. There should be two containers up, one for k3s and the other for load balancing:
\ndocker psMake sure that all the pods are running. If they are stuck in pending status, it may be that there is not enough disk space on your machine. You can get more information by using the describe command:
\nkubectl get pods -A\nkubectl describe pods -AThere's a lot of kubectl commands you can try, so I recommend checking out the list of resources and being aware of their short names:
\nkubectl api-resourcesWe will create a simple API using Express.js.
\nSet up the project:
\nmkdir my-backend-api && cd my-backend-api\ntouch server.js\nnpm init\nnpm i express --save// server.js\nconst express = require("express");\nconst app = express();\n\napp.get("/user/:id", (req, res) => {\n const id = req.params.id;\n res.json({\n id,\n name: `John Doe #${id}`\n });\n});\n\napp.listen(80, () => {\n console.log("Server running on port 80");\n});Optionally, you can try running it if you have Node.js installed and test the endpoint /user/{id} with curl:
\nnode server.js\n\n// request:\ncurl http://localhost:80/user/123\n\n// response: {"id":"123","name":"John Doe #123"}Next, add a Dockerfile and .dockerignore:
\n// Dockerfile\nFROM node:12\n\nWORKDIR /usr/src/app\nCOPY package*.json ./\nRUN npm i\nCOPY . .\n\nEXPOSE 80\nCMD ["node", "server.js"]// .dockerignore\nnode_modulesThen, build the image and push it to the Docker Hub registry:
\ndocker build -t <YOUR_DOCKER_ID>/my-backend-api .\ndocker push <YOUR_DOCKER_ID>/my-backend-apiNow, we deploy the image to our local Kubernetes cluster. We use the default namespace.
\nCreate a deployment:
\nkubectl create deploy my-backend-api --image=andyy5/my-backend-apikubectl create -f deployment.yaml// deployment.yaml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: my-backend-api\n labels:\n app: my-backend-api\nspec:\n replicas: 1\n selector:\n matchLabels:\n app: my-backend-api\n template:\n metadata:\n labels:\n app: my-backend-api\n spec:\n containers:\n - name: my-backend-api\n image: andyy5/my-backend-apiCreate a service:
\nkubectl expose deploy my-backend-api --type=ClusterIP --port=80kubectl create -f service.yaml// service.yaml\napiVersion: v1\nkind: Service\nmetadata:\n name: my-backend-api\n labels:\n app: my-backend-api\nspec:\n type: ClusterIP\n ports:\n - port: 80\n protocol: TCP\n targetPort: 80\n selector:\n app: my-backend-apiCheck that everything was created and the pod is running:
\nkubectl get deploy -A\nkubectl get svc -A\nkubectl get pods -AOnce the pod is running, the API is accessible within the cluster only. One quick way to verify the deployment from our localhost is by doing port forwarding:
\nkubectl port-forward my-backend-api-84bb9d79fc-m9ddn 3000:80curl http://localhost:3000/user/123To correctly manage external access to the services in a cluster, we need to use ingress. Close the port-forwarding and let's expose our API by creating an ingress resource.
\nCreate an Ingress resource with the following YAML file:
\nkubectl create -f ingress.yaml\nkubectl get ing -A// ingress.yaml\napiVersion: networking.k8s.io/v1\nkind: Ingress\nmetadata:\n name: my-backend-api\n annotations:\n ingress.kubernetes.io/ssl-redirect: "false"\nspec:\n rules:\n - http:\n paths:\n - path: /user/\n pathType: Prefix\n backend:\n service:\n name: my-backend-api\n port:\n number: 80curl http://localhost:80/user/123If you want to learn more on how to deploy using a managed Kubernetes service in the cloud, such as Google Kubernetes Engine, then check out the excellent guides on the official Kubernetes docs.
\n","frontmatter":{"date":"February 03, 2021","updated_date":null,"description":"Beginner guide on how to create and deploy a REST API in local Kubernetes.","title":"How to Deploy a REST API in Kubernetes","tags":["Kubernetes"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.492537313432836,"src":"/static/efa8ecb370a0a94f380c24981ede2913/ee604/cover.png","srcSet":"/static/efa8ecb370a0a94f380c24981ede2913/69585/cover.png 200w,\n/static/efa8ecb370a0a94f380c24981ede2913/497c6/cover.png 400w,\n/static/efa8ecb370a0a94f380c24981ede2913/ee604/cover.png 800w,\n/static/efa8ecb370a0a94f380c24981ede2913/f3583/cover.png 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Andy Yeung","github":null,"avatar":null}}}}]},"markdownRemark":{"excerpt":"Google has prepared a roadmap to restrict third-party cookies in Chrome. Since 04 January 2024, Chrome has rolled out third-party cookie…","fields":{"slug":"/engineering/identity-impact-of-google-chrome-thirdparty-cookie-restrictions/"},"html":"Google has prepared a roadmap to restrict third-party cookies in Chrome. Since 04 January 2024, Chrome has rolled out third-party cookie restrictions for 1% of stable clients and 20% of Canary, Dev, and Beta clients.
\nWhat does it mean for user authentication?
\nOn one hand, Google believes third-party cookies are widely used for cross-site tracking, greatly affecting user privacy. Hence, Google wants to phase out (or restrict) supporting third-party cookies in Chrome by early Q2 2025 (subject to regulatory processes).
\nOn the other hand, Google introduced Privacy Sandbox to support the use cases (other than cross-site tracking and advertising) previously implemented using third-party cookies.
\nIn this article, we’ll discuss:
\nThird-party cookie restrictions affect user authentication in three ways, as follows.
\nIf your website or app uses an external Identity Provider (IdP) — like LoginRadius, the IdP sets a third-party cookie when the user authenticates on your app.
\nIf you have multiple apps across domains within your organization and authentication is handled using an IdP (internal or external) with web SSO, you already use third-party cookies to facilitate seamless access for each user using a single set of credentials.
\nIf you have implemented web SSO with one primary domain and multiple sub-domains of the primary domain, third-party cookie restrictions may not apply. For now, Google doesn’t consider the cookies set by sub-domains as third-party cookies, although this stance may change in the future.
\nFor example, you have apps at example.com, travel.example.com, stay.example.com, and web SSO is handled by auth.example.com. In this case, third-party cookie restrictions don’t apply.
Federated SSO is similar to, albeit different from, web SSO. It can handle multiple IdPs and applications—aka., Service Providers (SPs)—spanning multiple organizations. It can also implement authentication scenarios that are usually implemented through web SSO.
\nUsually, authentication is handled on a separate pop-up or page when the user wants to authenticate rather than on the application or website a user visits.
\nFor example, you already use federated SSO if you facilitate authentication for a set of apps through multiple social identity providers as well as traditional usernames and passwords.
\n\n\nNote: It is also possible to store tokens locally, not within cookies. In this case, third-party cookie restrictions won’t affect token-based authentication. However, the restrictions still affect authentication where tokens are stored within third-party cookies (a common and secure method).
\n
Google has been developing alternative features and capabilities for Chrome to replace third-party cookies as part of its Privacy Sandbox for Web initiative.
\nSpecific to authentication, Google recommends the following:
\nCHIPS are a restricted way of setting third-party cookies on a top-level site without making them accessible on other top-level sites. Thus, they limit cross-site tracking and enable specific cross-site functionalities, such as maps, chat, and payment embeds.
\nFor example, a user visits a.com with a map embed from map-example.com, which can set a partitioned cookie that is only accessible on a.com.
If the user visits b.com with a map embed from map-example.com, it cannot access the partitioned cookie set on a.com. It has to create a separate partitioned cookie specific to b.com, thus blocking cross-site tracking yet allowing limited cross-site functionality.
You should specifically opt for partitioned cookies (CHIPS), which are set with partitioned and secure cookie attributes.
\nIf you’re using an external identity provider for your application, CHIPS is a good option to supplant third-party cookie restrictions.
\nHowever, CHIPS may not be ideal if you have a web SSO or federated SSO implementation. It creates separate partitioned cookies for each application with a separate domain, which can increase complexity and create compatibility issues.
\nWith Storage Access API, you can access the local storage in a third-party context through iframes, similar to when users visit it as a top-level site in a first-party context. That is, it gives access to unpartitioned cookies and storage.
\nStorage Access API requires explicit user approval to grant access, similar to locations, camera, and microphone permissions. If the user denies access, unpartitioned cookies and storage won’t be accessible in a third-party context.
\nIt is most suitable when loading cross-site resources and interactions, such as:
\nVerifying user sessions when allowing interactions on an embedded social post or providing personalization for an embedded video.\nEmbedded documents requiring user verification status to be accessible.
\nAs it requires explicit user approval, it is advisable to use Storage Access API when you can’t implement an identity use case with the other options.
\nWith Related Website Sets, you can declare a primary website and associatedSites for limited purposes to grant third-party cookie access and local storage for a limited number of sites.
Chrome automatically recognizes related website sets declared, accepted, and maintained in this open-source GitHub repository: Related Website Sets
\nIt provides access through Storage Access API directly without prompting for user approval, but only after the user interacts with the relevant iframe.
\nIt is important to declare a limited number of domains in related website sets that are meaningful and used for specific purposes. Google may block or suspend any exploitative use of this feature.
\nThe top-level site can also request approval for specific cross-site resources and scripts to Storage Access API using resuestStorageAccessFor() API.
If you’re using an external identity provider for your web application, you can declare the domain of the identity provider in the related set to ensure limited third-party cookies and storage access to the identity provider, thus ensuring seamless user authentication.
\nRelated Website Sets can also work to supplement third-party cookie restrictions in web SSO and federated SSO if the number of web applications (or domains) is limited.
\nFedCM API enables federated SSO without third-party cookies.
\nWith FedCM API, a user follows these steps for authentication:
\nYou can access a user demo of FedCM here: FedCM.
\nFor more information about implementing federated SSO with FedCM API, go through the FedCM developer guide.
\nFirstly, we’re committed to solving our customers' user identity pain points — and preparing for the third-party cookies phase-out is no different.
\nWe’ll implement the most relevant and widely useful solutions to facilitate a smooth transition for our customers.
\nPlease subscribe to our blog for more information. We’ll update you on how we help with the third-party cookie phase-out.
\nThe proposed changes to phase out third-party cookies and suggested alternatives are evolving as Google has been actively collaborating and discussing changes with the border community.
\nMoreover, browsers like Firefox, Safari, and Edge may approach restricting third-party cookies differently than Google does.
\nFrom LoginRadius, we’ll keep you updated on what we’re doing as a leading Customer Identity and Access Management (CIAM) vendor to prepare for the third-party cookie phase-out.
\nTop-level site: It is the primary site a user has visited.
\nFirst-party cookie: A cookie set by the top-level site.
\nThird-party cookie: A cookie set by a domain other than the top-level site. For example, let’s assume that a user has visited a.com, which might use an embed from loginradius.com to facilitate authentication. If loginradius.com sets a cookie when the user visits a.com, it is called a third-party cookie as the user hasn’t directly visited loginradius.com.