Overview
\nThe “reconciliation” algorithm in React is how the decision to re-render the component is made. In the browser, DOM manipulation is expensive and time consuming, both in mounting and unmounting. Part of what makes React very performant is its reconciliation algorithm.
\nIn short, it watches closely for differences, and only updates the DOM when necessary and tries to update only the parts which need to be changed.
\nThe “Virtual DOM”
\nThe Virtual DOM is a theoretical DOM tree generated by React when a change is made to a component’s state. This is modeled after the state of your application upon modification of the state, for example, after calling this.setState(). React uses what is called a “snapshot” to make this comparison and analysis between the DOM before the update, and the DOM after. This is the point in time when React utilizes its reconciliation algorithm.
\nUpdating the Virtual DOM is much faster than the real DOM, since the browser doesn’t need to show a visualization of it.
\nHow updates are determined
\nThe reconciliation algorithm is run whenever the component level state is updated. It analyzes the current DOM with the Virtual DOM, in order to determine which changes need to be made to the real DOM. After this step, it has determined which DOM nodes on your application require updates, and it calls the render method.
\nEffect on DOM elements and their attributes
\nThe reconciliation algorithm does not only look at whole DOM elements, it also looks at individual attributes. You can think of the difference as a PUT request vs. a PATCH request, where it only updates the parts which have changed, rather than updating the entire object if there was a change.
\nWhile it doesn’t unmount and remount the entire element if it doesn’t have to, sometimes it does have to. An example of this would be if you render an element of a different type.
\nSuppose you wanted to switch between two components or elements, perhaps for conditional rendering. This would result in a full unmounting of the component, regardless of whether or not they contain the same child nodes.
\nThis differs from switching attributes on the same type of elements, an example of which might be dynamic class names, based on component state. In this scenario, the DOM element is not destroyed, and only the modified attributes are changed. This is useful because it performs minimal operations on the DOM, which as we know, is more resource-intensive than standard object operations.
\nKeys and rerenders
\nThe \"key\" attribute in React can be used to mark whether or not a DOM node is stable. You may have seen a message in the console if you’ve ever attempted to map over a collection and return a JSX element each iteration. This is because the reconciliation algorithm uses the keys to determine if the content has changed, and not including a key may cause unexpected behaviour. For this reason, the keys should be unique so that reconciliation can recognize and identify which elements are stable, and which elements are not.
\nSuppose that you have a list of items, which is derived from an array. If you were to splice an item into the middle of it, that will change all of the indices of the subsequent items. In this scenario, since the keys will not be a stable, unique representation of each item, React can end up mutating the unintended item, which can cause major bugs.
\nA detailed explanation of keys can be found on the official React docs:
\n\n\nFor an in-depth exploration of how and why reconciliation was implemented, please visit the official React docs:
\n\n","frontmatter":{"date":"December 03, 2019","updated_date":null,"description":null,"title":"React's Reconciliation Algorithm","tags":["React"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":2.2988505747126435,"src":"/static/b0ebc3d46b4cf70980708fadb30e73ea/ee604/react-fiber.png","srcSet":"/static/b0ebc3d46b4cf70980708fadb30e73ea/69585/react-fiber.png 200w,\n/static/b0ebc3d46b4cf70980708fadb30e73ea/497c6/react-fiber.png 400w,\n/static/b0ebc3d46b4cf70980708fadb30e73ea/ee604/react-fiber.png 800w,\n/static/b0ebc3d46b4cf70980708fadb30e73ea/31987/react-fiber.png 1000w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Team LoginRadius","github":"LoginRadius","avatar":null}}}},{"node":{"excerpt":"You'll learn about JavasScript NaN in this tutorial, how to check whether a value is NaN, and how to effectively handle NaN. What is NaN in…","fields":{"slug":"/engineering/checking-for-nan-in-javascript/"},"html":"You'll learn about JavasScript NaN in this tutorial, how to check whether a value is NaN, and how to effectively handle NaN.
\nNaN, in JavaScript, can be many things. In fact, it can be almost anything, so long as it is Not a Number. Its type is technically “number” (when evaluated with “typeof”), although it stands for Not a Number.
\nValues can become NaN through a variety of means, which usually involve erroneous math calculations (such as 0/0), or as a result of type coercion, either implicit or explicit.
\nA common example is when you run parseInt on a string that starts with an alphabetical character. This isn’t exclusive to parseInt, as it also applies when using explicit coercion with Number(), or with the unary “+” operator.
\nBefore selecting a method for checking for NaN, how should you not check for NaN?
\nNaN is a bizarre value in JavaScript, as it does not equal itself when compared, either with the loose equality (==) or strict equality (===) operator. NaN is the only value in the entire language which behaves in this manner with regards to comparisons.
\nFor example, if parseInt(“a”) returns NaN, then parseInt(“a”) === NaN will return false. This may seem strange, but it makes perfect sense after thinking about what NaN really is.
\nNaN doesn’t tell you what something is, it tells you what it isn’t.
\nThese two different strings being passed to parseInt() will both return NaN.
\nparseInt(“abc”) // NaN\nparseInt(“def”) // NaNBoth statements return NaN, but are they really the same? Maybe, but it certainly makes sense why JavaScript would disagree, given that they are derived from different string arguments.
\nHere are a few examples of strict inequality comparisons, which demonstrate the inconsistency of NaN.
\n2 !== 2 // false\ntrue !== true // false\n“abc” !== “abc” // false\n...\nNaN !== NaN // trueJavaScript has a built-in method, appropriately named “isNaN,” which checks for NaN. There is a newer function called Number.isNaN, which is included in the ES2015 spec.
\nThe difference between isNaN and Number.isNaN is that isNaN coerces the argument into a number type. To avoid complicated and unexpected outcomes, it is often advised to use the newer, more robust Number.isNaN to avoid these side effects.
\nNumber.isNaN does not perform any forcible type conversion, so it simply returns the boolean based on the parameter.
\nHere is an example of the difference between the two methods:
\nisNaN(undefined) // true\nNumber.isNaN(undefined) // falseisNaN, when passed undefined, returns true because undefined becomes NaN after number coercion. You can test this yourself by running Number(undefined). You will find that it returns NaN.
\nNumber.isNaN, on the other hand, returns false. This is because no coercion takes place, and undefined is not NaN, it is simply undefined.
\nIt is also important to note that Number.isNaN is a newer (ES2015) method in JavaScript, so browser support for Number.isNaN is not as stable as isNaN, which has been around since ES1 (1997).
\nObject.is is a JavaScript method which checks for sameness. It generally performs the same evaluations as a strict equality operator (===), although it treats NaN differently from strict equality.
Object.is(0, -0) will return false, while 0 === -0 will return true. Comparisons of 0 and -0 differ, as do comparisons of NaN. This concept is called “Same-value-zero equality.”
NaN === NaN // false\nObject.is(NaN, NaN) // trueObject.is(NaN, NaN) will in fact return true, while we already know that NaN === NaN returns false. That makes this yet another valid way to check if something is not a number.
Between the given methods of checking for NaN, the most common is to use the global isNaN function, or the ES2015 Number.isNaN method. While method #2 is valid, most people will typically use isNaN or Number.isNaN, which were created specifically for checking for NaN.
\n","frontmatter":{"date":"November 22, 2019","updated_date":null,"description":"In this guide you'll learn about JavasScript NaN, how to verify whether a value is NaN, and how to manage NaN effectively.","title":"NaN in JavaScript: An Essential Guide","tags":["JavaScript"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.3333333333333333,"src":"/static/55c8ddd31fa08f811d159c331bf44d5e/2244e/numbers-1.jpg","srcSet":"/static/55c8ddd31fa08f811d159c331bf44d5e/f836f/numbers-1.jpg 200w,\n/static/55c8ddd31fa08f811d159c331bf44d5e/2244e/numbers-1.jpg 400w","sizes":"(max-width: 400px) 100vw, 400px"}}},"author":{"id":"Greg Sakai","github":null,"avatar":null}}}},{"node":{"excerpt":"We're delightfully Announcing SDK Version 10.0.0. This full-version release includes major changes with several improvements and…","fields":{"slug":"/engineering/sdk-version-10-0-0/"},"html":"We're delightfully Announcing SDK Version 10.0.0.
\nThis full-version release includes major changes with several improvements and optimizations, the details have been given below. For complete information please visit LoginRadius API documents.
\nWe have added new APIs in this release, that will complement the existing ones.
\nTo cope up with the changes around the social platforms, we have removed some existing APIs as they are no longer supported by the social providers. Below are the details of those APIs.
\nThis blog is part 1 of a series on gRPC. Part 1 will go over some important concepts, part 2 will be a walkthrough of a client-server implementation in Go, and part 3 will be about LoginRadius' experience migrating to gRPC!
\ngRPC
\ngRPC, simply put, is just another way to send data across networks. It can be used to communicate between services in a microservice architecture, where a single service can interact with multiple others. Similarly, in client-server models, there can be multiple clients communicating with a common backend server.
\nThe gRPC framework was initially developed at Google and is now open-source. It is a modern implementation of the RPC (Remote Procedure Call) protocol, which has been around since the 80s. You will often see gRPC being compared to other technologies like SOAP, REST, and GraphQL.
\nSome features:
\nHow is it used to send data?
\ngRPC is based on the idea of calling a remote procedure just like a local one. A procedure is like a function or a method. So, ideally developers can treat remote and local calls similarly. A great thing about gRPC is that developers do not need to know the details of the remote interaction.
\nHere is a diagram from the official grpc docs showing the flow:
\nWhy gRPC?
\nOne compelling reason to use gRPC is that it provides high performance
\nHow does it differ from REST?
\n| \n | gRPC | \nREST | \n
|---|---|---|
| API | \nContract-based i.e. stubs | \nResource-based and relies on HTTP verbs i.e. GET/PUT/POST/DELETE | \n
| Network protocol | \nHTTP/2 | \nHTTP/1.1 or HTTP/2 | \n
| Data serialization format | \nProtocol buffers | \nJSON | \n
| Streaming | \nBuilt-in support for client, server, and bi-directional streaming | \nREST on HTTP/1.1 does not allow streaming | \n
Other Considerations
\nHere, we briefly go over a few other things to consider with gRPC. These will be covered in more detail in another blog.
\nManagement of proto files
\nIf you plan to have multiple proto files and client services, you need some way to manage them for distribution and version control. One solution is to keep all proto files in a central git repository, and maintain versions using git tags.
Using proto2 vs. proto3
\nProtocol buffers have two syntax versions: proto2 and proto3.
Load-Balancing
\nSomething to note about load-balancing gRPC is that HTTP/2 requires L7 (Application Layer) load-balancers. Recall that in HTTP/2, TCP connections are long-lived and requests are multiplexed. This makes L4 (Connection Layer) load-balancers ineffective. This differs from HTTP/1.1 where TCP connections get cycled and can benefit from L4 load-balancers.
That's it for now! To learn more, check out the official gRPC and protobuf docs.
\n","frontmatter":{"date":"October 30, 2019","updated_date":null,"description":null,"title":"Getting Started with gRPC - Part 1 Concepts","tags":["Engineering","gRPC"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1,"src":"/static/ceff66d5b341e58e4b85f5a6c3a7cbad/f006c/grpc.png","srcSet":"/static/ceff66d5b341e58e4b85f5a6c3a7cbad/69585/grpc.png 200w,\n/static/ceff66d5b341e58e4b85f5a6c3a7cbad/f006c/grpc.png 246w","sizes":"(max-width: 246px) 100vw, 246px"}}},"author":{"id":"Andy Yeung","github":null,"avatar":null}}}},{"node":{"excerpt":"Introduction Cross-Site Request Forgery (CSRF) is a common web application attack where a victims’ authenticated session becomes compromised…","fields":{"slug":"/engineering/introduction-to-cross-site-request-forgery-csrf/"},"html":"Introduction
\nCross-Site Request Forgery (CSRF) is a common web application attack where a victims’ authenticated session becomes compromised. This attack essentially tricks a victim into performing unintended tasks on a website they are authenticated in. There are variations to this attack, and a popular one we will discuss is utilizing authentication token to imitate api requests.
\nContext
\nIn order to understand CSRF, it is important to know how cookies and authentication tokens are used for persisting user sessions. Cookies are information stored in the browser, and often used for managing state between HTTP requests. A key feature of cookies is that they are automatically passed as a header in HTTP requests. Authentication tokens are typically stored as cookies, and are a way to keep track of a users’ authenticated session. These tokens are set as cookies after a user successfully authenticates themselves by log in.
\nHow it works
\nCSRF takes advantage of the storage of auth tokens in the browser, and constructs http requests to a target server on behalf of the user. Imitating http requests from the legitimate site requires research and preparation from the attacker beforehand, such as finding vulnerable websites and api’s suitable for the attack.
\nWhen a request is made by the client, both tokens are sent to the server, and the server will then ensure the tokens are valid pairs before processing the request as normal.
\nNow the attacker will be unable to perform CSRF since they will not have access to the token hidden in the pages HTML, and the target server requires a valid token pair before processing the request.
\nThere are also many other mitigation techniques, such as using the Same-Site cookie attribute, and requiring user interaction such as CAPTCHA for requests. Learn more on the OWASP wiki).
\n","frontmatter":{"date":"October 30, 2019","updated_date":null,"description":null,"title":"Introduction to Cross-Site Request Forgery (CSRF)","tags":["CSRF"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.3333333333333333,"src":"/static/4a13eeb54334febf9c8db79b24424eb6/2244e/crosspath.jpg","srcSet":"/static/4a13eeb54334febf9c8db79b24424eb6/f836f/crosspath.jpg 200w,\n/static/4a13eeb54334febf9c8db79b24424eb6/2244e/crosspath.jpg 400w","sizes":"(max-width: 400px) 100vw, 400px"}}},"author":{"id":"Andy Yeung","github":null,"avatar":null}}}},{"node":{"excerpt":"What is Web Accessibility? Web Accessibility (often stylized “a11y”), is the practice of ensuring that your websites and web applications…","fields":{"slug":"/engineering/introduction-to-web-accessibility-with-semantic-html5/"},"html":"What is Web Accessibility?
\nWeb Accessibility (often stylized “a11y”), is the practice of ensuring that your websites and web applications are accessible by people with disabilities of many kinds.
\nSome examples of common disabilities which we need to consider are: Blindness and visual impairment, deafness and hearing difficulties, motor skill impairment, and many more.
\nThe common categories of disabilities include:
\nThis list was taken from the W3C Web Accessibility Initiative (WAI). A link to their resources can be found at the bottom.
\nWhat is Semantic HTML? What is its correlation with Web Accessibility?
\nHTML semantics refers to conveying meaning through the use of HTML elements. An example of semantic HTML would be using <header>, <main>, <footer>, and other content-specific tags when applicable. Unsemantic HTML would be using <div> or <span> tags for every use-case.
Images and “alt” attributes
\nUsers who are visually impaired may encounter trouble when the content of a website relies on an image. Luckily, there are precautions that we - as developers - can take to ensure that their user experience does not suffer because they are unable to see images.
\nThe easiest way to do this is to add an alt attribute to all of your <img> tags. This way, screen readers will be able to describe the image to the user. Here are a few suggestions and best practices for writing alt text:
Do not include words like “image”, or “picture”. It is redundant, because the screen reader will notify the user that it’s an image. An exception to this would be if the image is of a painting, or an illustration. In this case, emphasizing that is fine, because you want the user to know that it’s specifically a painting, as opposed to any image.
\nAlways include the alt attribute, even if you don’t want the screen reader to read it. If you have a decorative image (one that is simply cosmetic, and not necessary for the site), then you can add an alt tag and assign it to an empty string. In this case, the image will be ignored by the screen reader. If this is neglected, the screen reader may read the file name instead, which may not be particularly helpful.
\nForm Labels and ARIA Labelling
\nUsers with screen readers will need some way to differentiate between multiple inputs on a single form. Without labels, the user will have a difficult time figuring out what each input is for.
\nThe easiest way to implement form labelling is with the HTML <label> tag. The <label> element uses an attribute called for in order to form a relationship with the ID of the <input> tag.
Another way to give context to a screen reader is with the ARIA aria-labelledby attribute. This attribute can be placed on (but not limited to) <input> tags, and then reference the id of the label. You can use <label for=””> in conjunction with <input aria-labelledby=””> in order to provide extra support and maximize compatibility.
Buttons and Tabindices
\nButtons should use <button> tags (or <input type=”submit”> if applicable), rather than <a>, <span>, <div>, or anything else that doesn’t have semantic meaning for clickable buttons. Often people choose to use these tags, because they want to clear all styling and not have default <button> styling. This is ill-advised because <button> tags come with a ton of functionality built-in, an important part being its tabindex. A user who isn’t able to use a mouse, and must navigate the site with their keyboard, will press the tab key to jump through interactive elements. Standard <div> tags are not tabbable by default, and assigning a tabindex to it manually can break the flow of the natural tabindices of the page.
Other Semantic HTML tags
\nOther than images and forms, there are still many ways to provide the best accessibility possible. Semantic HTML tags are useful because they describe the content and the relationship with your overall page. Using appropriate, accurate tags such as <article>, <aside>, <section> will give screen readers an idea of what the role is for those sections.
Other elements such as <h1> and other heading tags should be carefully planned before sprinkled throughout your webpage. The <h1> through <h6> tags should form direct relationships with each other in order to differentiate their meaning. Headings with lower importance (relative to the previous heading) can be used to start new subsections within its current section. Your different page sections can even use aria-labelledby to point to its corresponding heading in order to label your sections accurately.
The full W3C specification on HTML semantics can be found at: W3C Recommendation.
\nMore information about the varying disabilities and barriers can be found at: Diverse Abilities and Barriers
\n","frontmatter":{"date":"July 24, 2019","updated_date":null,"description":null,"title":"Introduction to Web Accessibility with Semantic HTML5","tags":["HTML5","HTML","Web Accessibility","Semantic HTML5"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1,"src":"/static/f3092adaa3def7fb943a47f7a5c8be4c/ee604/handicapped.png","srcSet":"/static/f3092adaa3def7fb943a47f7a5c8be4c/69585/handicapped.png 200w,\n/static/f3092adaa3def7fb943a47f7a5c8be4c/497c6/handicapped.png 400w,\n/static/f3092adaa3def7fb943a47f7a5c8be4c/ee604/handicapped.png 800w,\n/static/f3092adaa3def7fb943a47f7a5c8be4c/a8378/handicapped.png 1024w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Greg Sakai","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.