Cross-domain security authentication engine in a project list system

Abstract

This describes the methods, systems, and computer storage media used to provide a cross-domain secure authentication engine in a project listing system. The cross-domain secure authentication engine is an advanced modular system designed to seamlessly handle user authentication across different service domains while ensuring security features and an adaptive user experience. In the project listing system, the cross-domain secure authentication engine operates based on a security-centric framework that simplifies user authentication across multiple domains without sacrificing user experience. It integrates a modal window containing an iframe-based login interface associated with a separate authentication domain and uses the postMessage API for cross-origin communication. Key features include dynamic modal window resizing (adjusting the login window based on different authentication steps, such as email, password, or OTP) and parameterized iframes that remove unnecessary UI elements for a cleaner user experience. The cross-domain secure authentication engine also supports security measures and incremental, multi-step authentication processes to reduce user friction.

Description

Technical Field

[0001] The various aspects of the technology described in this article generally relate to systems, methods, and computer storage media for providing cross-domain secure authentication engines, etc., in project listing systems. Background Technology

[0002] Users can use various authentication solutions to authenticate to different computing environments. In a project listing system, authentication solutions ensure secure access, a smooth user experience, and seamless integration across various service domains, such as browsing projects, managing user profiles, and completing purchases. For example, OAuth 2.0 allows users to authenticate via third-party services, reducing friction and improving user convenience by enabling Single Sign-On (SSO). This method simplifies the login process, allowing users to quickly access their accounts without having to remember additional credentials. Another common solution is JWT (JSON Web Token), which provides a secure, stateless method for maintaining user sessions. After logging in, the user receives an authentication cookie used for authentication in subsequent interactions with the system. Summary of the Invention

[0003] The various aspects of the technology described in this paper generally relate to systems, methods, and computer storage media for providing cross-domain secure authentication engines, etc., in item listing systems. A cross-domain secure authentication engine is an advanced modular system designed to seamlessly handle user authentication across different service domains while ensuring security features and an adaptive user experience. This engine leverages modern Web technologies to provide secure, dynamic, and flexible authentication flows that can be integrated into various applications, particularly those involving cross-origin interactions, such as e-commerce.

[0004] In the project listing system, the cross-domain secure authentication engine operates on a security-centric framework that streamlines user authentication across multiple domains without sacrificing user experience. It integrates a lightbox modal window containing an iframe-based login interface associated with a separate authentication domain and utilizes the postMessage API for secure cross-origin communication. Key features include dynamically resizable modal windows (adjusting the login window based on different authentication steps, such as email, password, or OTP) and parameterized iframes that remove unnecessary UI elements for a cleaner user experience. The cross-domain secure authentication engine also supports robust security measures (CAPTCHA, CSP, rate limiting, and XSS protection) and incremental, multi-step authentication processes to reduce user friction. The cross-domain secure authentication engine can adapt to various application needs, seamlessly scaling across different service domains (e.g., checkout and authentication pages) and ensuring users can authenticate quickly and securely without being redirected away from their primary tasks.

[0005] As an example, a user visits cart.example.com, which is associated with the shopping cart page (i.e., the parent page), and clicks the "Checkout" button. Instead of entering the full login page, a modal window appears in the center of the screen with a darkened background, displaying the login form from signin.example.com via an iframe on the parent page. The user enters their email address in the login form, and if CAPTCHA is triggered, it is displayed within the iframe. Security features (e.g., rate limiting) ensure secure interaction throughout the process. When additional fields such as a password or one-time PIN need to be displayed, the login page sends a "resize" event to the parent shopping cart page, causing the modal window to expand. Once the user successfully logs in, the iframe sends a message indicating that authentication is complete back to the parent page. This allows navigation to the checkout page to continue the checkout process without reloading or redirecting to authenticate the user. Finally, the modal window closes, and the user can complete their purchase. It is conceivable that if the user is already on the checkout page (i.e., the checkout page is the parent page), the cross-domain security authentication engine can authenticate the user to complete their purchase without needing to leave the checkout page at all.

[0006] This invention provides a simplified overview of a series of concepts, which are further described in the detailed description below. This invention is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. Attached Figure Description

[0007] The technology described herein is described in detail below with reference to the accompanying drawings, in which:

[0008] Figures 1A to 1C This is a schematic diagram relating to the technology described in this article and the provision of cross-domain secure authentication;

[0009] Figure 2A This is a block diagram of a project list system for providing cross-domain secure authentication based on the technical aspects described herein;

[0010] Figure 2B This is a flowchart relating to the technology described in this article and the provision of cross-domain secure authentication;

[0011] Figure 3 This paper provides a first exemplary method for providing cross-domain secure authentication in a project listing system based on aspects of the technology described herein.

[0012] Figure 4 A second exemplary method is provided for providing cross-domain secure authentication in a project listing system based on aspects of the technology described herein;

[0013] Figure 5 A third exemplary method for providing cross-domain secure authentication in an item listing system is provided, based on aspects of the technology described herein;

[0014] Figure 6 A block diagram of a system computing environment is provided, which is a list of exemplary projects suitable for implementing aspects of the techniques described herein;

[0015] Figure 7 A block diagram of an exemplary distributed computing environment suitable for implementing aspects of the techniques described herein is provided; and

[0016] Figure 8 This is a block diagram of an exemplary computing environment suitable for implementing aspects of the techniques described herein. Detailed Implementation

[0017] Overview

[0018] The project listing system and platform support storing projects (products or assets) in a project database and provide a search system for receiving queries and identifying search result projects based on those queries. A project (e.g., a physical project or a digital project) refers to a product or asset offered for listing on the project listing platform. The search system supports identifying result projects from the project database in response to a received query. The project database can be dedicated to a content platform or a project listing platform, such as the eBay content platform developed by eBay Inc. of San Jose, California. The project listing system can also provide authentication solutions to ensure secure and personalized user interaction, enhance the user experience, and support essential features such as order processing and account management.

[0019] Online systems' authentication frameworks provide a secure way to protect user data and ensure that only authorized individuals can access certain features. Authentication allows users to create personalized experiences, manage their accounts, and protect sensitive information such as payment methods and personal details. Authentication is particularly important in transaction listing systems where security and privacy are paramount.

[0020] In the item list system, authentication ensures secure access to the shopping cart and the purchase process. When users log in, they can add items to their cart, save their selections for later use, and proceed to checkout without having to re-enter information each time. The authentication process ensures that only authorized account holders can access their shopping cart, preventing unauthorized changes to items or misuse of payment information. Additionally, it enables a seamless and personalized experience, allowing users to track their order history, manage shipping details, and update payment methods as needed. By providing users with a secure and efficient way to access and manage their shopping cart, authentication enhances the overall shopping experience while maintaining the integrity of the transaction process.

[0021] Conventional item listing systems lack the computational infrastructure and algorithms needed for a seamless, user-friendly buying experience due to cumbersome full-page login processes, which typically lead to cognitive overload and increased churn. This login experience, often encountered when attempting a purchase, creates a significant barrier to transaction completion. Users face a fragmented buying experience, reducing overall engagement. The lack of contextual relevance forces users away from their intended action. Furthermore, it cannot function as a standalone modular component, making integration into various buying workflows cumbersome, especially for teams operating on different technology stacks. Existing item listing systems also face challenges in maintaining consistent security features, potentially undermining user trust. Additionally, conventional login experiences frequently disrupt the user flow by removing them from their current context. This interruption forces users away from their intended action, which can be frustrating and lead to decreased overall customer satisfaction. Therefore, such interruptions can also negatively impact checkout completion rates, as users may abandon their purchase due to additional steps or the inconvenience of login. These friction points in the user experience can reduce conversion rates and hinder seamless interaction with the platform.

[0022] As an example, consider user Alex, who is browsing an online store and finds a pair of shoes he wants to buy. He adds the shoes to his cart and proceeds to the checkout page. Just before completing the purchase, instead of displaying a small, integrated login prompt, the website redirects Alex to a completely separate, full-page login screen. This abrupt switch unsettles him—he might never see his cart or item details again, and his purchase mindset is gone.

[0023] He now had to recall his login credentials on a new page separate from his previous shopping experience. The unfamiliar layout and lack of product context made him hesitate. Frustrated, Alex spent extra time resetting his password and navigating back to his cart. When he returned to the checkout process, he became hesitant, lost motivation, and decided to postpone his purchase. This entire ordeal, triggered by the cumbersome full-page login process, resulted in lost potential revenue for the store and a negative experience for Alex. Alex's checkout experience lacked a seamless, user-friendly interface due to the tedious full-page login process, which reduced his overall engagement because the checkout experience wasn't integrated in a way that allowed him to focus on his intended action. Therefore, a more comprehensive item list system (an alternative foundation with authentication capabilities) could improve the computational operations and interface authentication within the item list system.

[0024] Description of the technical solution

[0025] At a high level, a cross-domain security authentication engine is an advanced modular system designed to seamlessly handle user authentication across different service domains while ensuring robust security features and a smooth, adaptive user experience. Cross-domain security authentication engines leverage modern web technologies to provide secure, dynamic, and flexible authentication processes that can be integrated into various applications, especially those involving cross-origin interactions, such as e-commerce or SaaS platforms.

[0026] The cross-origin secure authentication engine is built on a modular architecture that can be easily integrated into any web application. It utilizes modal windows (e.g., lightbox UIs) and embedded iframes to load the login interface from a separate authentication domain. A key innovation is the use of the postMessage API for secure cross-origin communication between the parent page and the iframe, while mitigating security risks such as XSS. Operationally, the login page sets an authentication cookie in the browser, which can be accessed by any other page on the example.com domain (including shopping cart, checkout, and other pages). In one embodiment, authentication artifacts (e.g., tokens or cookies) are not passed to the parent page via postMessage. In this way, the completion message transmitted between the iframe and the parent page does not contain any tokens or cookies. The checkout page, for example, relies on cookies to determine whether the user is authenticated and has an active session. Since these cookies are set by signin.example.com in the iframe, they can be shared across any *.example.com domain. Therefore, when a user navigates to checkout.example.com, the page first checks for the existence of an active session via the authentication cookie. If the session is active, a member-specific checkout page is displayed. The cross-domain security authentication engine also features dynamic modal window resizing, adjusting the modal window size during different authentication steps (e.g., email address entry and password entry), and using custom resizing events to ensure a smooth user experience.

[0027] In typical item listing systems, user authentication usually involves a full-page redirect to a login portal or a separate in-frame integration, with the latter offering limited interactivity or adaptability. This technical solution breaks away from these conventional, rigid methods and provides a seamless, context-sensitive authentication layer. Instead of pushing users away from their expected checkout path, it embeds the login experience directly into the process, displayed as a dynamically adjustable modal overlay window. In this way, the cross-domain secure authentication engine provides dynamic integration without full-page redirection and securely leverages existing authentication infrastructure.

[0028] Traditionally, item listing systems rely on separate login pages hosted on an authentication service domain. This forces users to leave the checkout process and often results in lost context and increased abandonment upon return. The new approach introduces a lightbox modal window within the checkout domain itself, allowing users to authenticate without their cart or progress disappearing from view. In standard authentication flows, dynamically resizing the modal window, triggered by messages from a child iframe, is not standard practice. It allows the modal window to adapt to changing authentication steps (e.g., from email input to password or OTP input) without reloading or resizing the entire page.

[0029] While item listing systems have sophisticated authentication backends (including CAPTCHA, rate limiting, and strict content security policies), these backends are often limited to a full-page login experience. Cross-domain secure authentication engines leverage existing infrastructure but package it as a modular, embedded iframe. The result is a scenario that offers the best of both worlds: the flexibility and continuity of an integrated, context-sensitive login process, combined with the reliability and security of a dedicated authentication service. This architectural choice is not merely a technical convenience; it represents a conceptual shift designed to more naturally embed trusted authentication resources into the user's purchase flow. Essentially, this innovation reimagines how and where authentication can occur. It respects the boundaries and strengths of existing security frameworks while delivering a seamless, user-centric experience—something not yet widely achieved in traditional item listing system authentication models.

[0030] For example, users often abandon their intended purchase when faced with a full-page login screen, as it disrupts their shopping process and causes excessive cognitive load. To address this, authentication must be simplified through a context-sensitive mini-login solution that can be directly integrated into the purchase process. The cross-domain security authentication engine is designed for easy integration into different pages (e.g., viewing items, shopping cart, and checkout), regardless of the underlying technology stack or domain (e.g., cart.example.com, checkout.example.com). The cross-domain security authentication engine incorporates security features for full-page login, including CAPTCHA, bot signature detection, rate limiting, XSS mitigation, and CSP (Context Security Policy) enforcement, ensuring the process remains both user-friendly and robust. Furthermore, the cross-domain security authentication engine components are easy to adopt, scalable to new domains, and do not rely on consumer-specific codebases for authentication tasks.

[0031] To achieve this, a cross-domain security authentication engine is provided. Cross-domain security authentication can be provided via web development programming (e.g., pure or native JavaScript). The cross-domain security authentication engine accepts data structure-driven formats from integrated applications (e.g., JSON-based configurations) and uses JavaScript events to relay information back to the host page. By creating modal windows or modal interfaces (e.g., lightbox UIs—a modal window that dims its background and appears in the foreground), the login experience becomes visually distinctive yet blends seamlessly into the context.

[0032] Within the modal window, the iframe hosts the login interface. The login interface can be parameterized to remove headers or footers for a clean, unobtrusive environment while retaining critical security measures. The cross-origin security authentication engine also relies on bidirectional messaging via the postMessage API, allowing communication between the parent page (e.g., a shopping cart page) and the embedded login page, even if they are associated with different domains. Consumers (e.g., checkout apps) do not need to deal with the underlying complexities of cross-origin messaging; they can simply subscribe to high-level events such as "authentication complete."

[0033] The cross-domain security authentication engine is specifically designed to handle dynamically resizing modal windows. Typically, due to cross-domain restrictions, iframes cannot directly change their own size from within. However, as users move from one authentication step to another (e.g., from entering an email address to providing a password or one-time PIN), embedded login pages require more or less space. Therefore, the iframe sends a custom "resize" event via postMessage, prompting the parent page to seamlessly resize the modal window. This ensures a smooth, adaptive interface that reflects the user's immediate needs without interrupting their checkout process. In this way, the cross-domain security authentication engine eliminates user fatigue, preserves secure authentication practices, and adapts to various domains and technology stacks. By combining flexibility and a simplified user experience, the cross-domain security authentication engine significantly reduces friction in the purchase process.

[0034] Operationally, the message delivery payload (a structured object, such as {source: "id-signin-to-parent", action: "signInLoad", version: "1.0.0", timestamp: ...}) and message type (signinLoad, error, success, close, resize) act as unique fingerprints for implementing cross-domain secure authentication. Similarly, cross-domain secure authentication can be provided based on unique animation parameters used for modality transitions (e.g., minimum height 0.5s cubic Bézier curve (0.785, 0.135, 0.15, 0.86), maximum width 0.5s cubic Bézier curve (0.785, 0.135, 0.15, 0.86)).

[0035] Consider the following scenario: A parent web page hosts a login modal window loaded via an embedded iframe from a separate domain. When the iframe is fully initialized and ready for interaction, it uses the postMessage API to send a structured data object (e.g., {Source: "id-signin-to-parent", Action: "signInLoad", Version: "1.0.0", Timestamp: 1697040532}) back to the parent page. Each element of this payload is selected to uniquely identify the type of message and the stage of the authentication process. For example, the source indicates that the message specifically originates from the login component, the action indicates the event type (in this case, signInLoad indicates that the iframe has completed loading its initial state), the version helps maintain backward compatibility and track updates over time, and the timestamp provides the precise moment of occurrence. These attributes collectively act as a "fingerprint" to ensure that the parent page only processes the identified, genuine messages, thereby improving security and trust.

[0036] Similarly, unique style properties can serve as another form of fingerprint recognition. Consider transitions used to resize or animate modal windows, such as a minimum height of 0.5s using a cubic Bézier curve (0.785, 0.135, 0.15, 0.86) and a maximum width of 0.5s using the same cubic Bézier curve (0.785, 0.135, 0.15, 0.86). These specific cubic Bézier curves and transition durations create a unique “animation signature.” If another unrelated implementation uses the exact same messaging pattern combined with these specific timing curves and easing functions used for modal transitions, it strongly suggests that they are copying the original solution. Therefore, both the structured message payload and the unique animation parameters constitute a recognizable “fingerprint” that can help identify and ensure the authenticity of cross-domain secure authentication system implementations.

[0037] As an example, imagine user Jane browsing an online marketplace and adding a pair of branded headphones to her cart. Instead of being redirected to a separate login page when she reaches the checkout page, a small overlay window dims the background and displays a compact modal window at her current location. Within this modal window, a simple email address field from a separate login domain is displayed. After Jane enters her email address and clicks "Next," the modal window communicates with the parent page in the background, automatically expanding to reveal the password field without reloading or changing labels. Jane enters her password, and the modal window smoothly makes a final adjustment to add a one-time PIN input box. Once these steps are completed and her credentials are verified, the modal window closes easily, allowing Jane to return to her checkout process. Instead of dealing with a cluttered, full-page login process, she experiences a seamless, secure, and context-aware authentication process that doesn't interrupt her purchase.

[0038] Example systems and resources

[0039] Examples and references are available. Figures 1A to 1C , Figure 2A and Figure 2B To describe aspects of this technical solution. References Figure 1A , Figure 1A This diagram illustrates a secure cross-domain login integration that seamlessly embeds the authentication workflow into an e-commerce checkout page. By combining a modal overlay window on cart.example.com with an iframe that loads the login form from signin.example.com and utilizing a messaging protocol for event-driven communication, it demonstrates how users can complete the required authentication steps without leaving the checkout process.

[0040] Figure 1A Including checkout.example.com 102, signin.example.com 104, modal window 106, postMessage 108, event 110A, login form 120, iframe 130, and postMessage protocol 140, these support a cross-domain secure authentication engine designed to enhance user experience, maintain context integrity, and ensure security.

[0041] When a user navigates to checkout.example.com 102 and initiates a purchase, the cross-domain security authentication engine does not redirect the user to a separate full-page login screen. Instead, it displays a modal window 106 directly on the same page. This modal window is not a simple static overlay; instead, it uses an iframe 130 to load the login form 120 from signin.example.com 104. Using a separate authentication domain ensures that all security and compliance measures, from CAPTCHA checks to strict content security policies, are maintained independently and on a large scale.

[0042] To achieve this seamless interaction, the modal window 106 and its embedded iframe 130 rely on a secure communication channel. Browser security policies restrict direct function calls between the parent checkout page and iframe 130, therefore the cross-domain authentication engine implements the postMessage 108 method. This capability of postMessage 108 and JavaScript event 110 allows for secure message delivery between two different domains. Instructions for resizing the modal window, updating UI elements, or signaling successful authentication are sent using the postMessage protocol 140, ensuring that both parties remain synchronized. For example, when a user first enters their email address on a login form, iframe 130 sends a "resize" instruction to the parent page via postMessage 108, prompting the parent page to resize the modal window and display the password field or one-time PIN hint, without requiring a page reload.

[0043] Therefore, integrating a modal overlay window on checkout.example.com 102, loading the login form 120 from signin.example.com 104, and coordinating interactions via the postMessage protocol 140 and JavaScript events 110 represent a refined approach to authentication. It maintains the user's original context, reduces friction, and leverages existing trusted authentication infrastructure—while still ensuring secure and seamless communication between both parties using postMessage 108.

[0044] refer to Figure 1B , Figure 1BThis paper demonstrates dynamic lightbox authentication based on a cross-domain security authentication engine for a seamless mobile user experience. The cross-domain security authentication engine utilizes dynamic lightbox authentication to provide a secure and adaptable user experience on mobile devices. By integrating authentication directly into the shopping process (whether via one-time code, email-based login, or password), the lightbox (e.g., Lightbox GUI 122B, Lightbox GUI 132B, Lightbox GUI 142B) maintains user context and eliminates disruptive navigation to a separate login page. The flexibility of the cross-domain security authentication engine ensures compatibility with various authentication methods, thereby providing a smooth and secure experience that enhances user engagement and complies with modern security standards.

[0045] The cross-domain security authentication engine is designed to provide a seamless and adaptive authentication experience, maintaining the user context within the mobile device environment. On mobile devices 100B associated with the 123.com domain, the cross-domain security authentication engine utilizes a graphical user interface (GUI) and dynamically adjustable lightboxes to authenticate users without disrupting their workflow.

[0046] When users interact with GUI 110B, which displays basic shopping options such as "Item," "Price," "Buy Now," and "Add to Cart," they can select the "Buy Now" option 112B to make a purchase. At this stage, authentication may be required to ensure security and verify the user's identity. Instead of redirecting users to a separate login page, the lightbox GUI 122B is presented as a modal overlay window. This overlay window maintains the user's context and welcomes them with a personalized message, such as, "Welcome back! Log in using the one-time code we sent to 555-555-5555." The lightbox minimizes distractions, ensuring users remain focused on completing their purchase.

[0047] Alternatively, depending on the authentication method supported or preferred by the user, the lightbox can dynamically adjust to present different processes. For example, GUI 130B displays lightbox GUI 132, which introduces an email-based login process. Here, the user is prompted to enter their email address in a modal window. The flexibility of the lightbox design allows it to adapt to this method without departing from the original context of the transaction.

[0048] When prioritizing advanced security measures or user convenience, lightboxes can be adapted to provide password authentication. GUI 140B illustrates this scenario through lightbox GUI 104B, where a modal overlay window prompts the user, "Welcome back! Please log in with your password." This approach leverages modern authentication mechanisms to provide a seamless and secure experience.

[0049] The ability of a lightbox to dynamically adjust to different authentication methods (e.g., one-time codes, email-based login, or passwords) while preserving the user's context is a crucial aspect of cross-domain secure authentication engines. It eliminates the need for page reloads or navigation interruptions, ensuring users remain focused during their purchase. Furthermore, the lightbox's modular nature allows for seamless integration with various authentication infrastructures, making it adaptable to current and future security technologies.

[0050] It can be envisioned that the lightbox GUI dynamically adjusts its size based on resizing events triggered by the authentication process. For example, when transitioning from an initial email address input to an additional field displaying a password or one-time code, the lightbox seamlessly resizes without disrupting the user experience. This dynamic resizing ensures the interface remains clear and user-friendly, accommodating the needs of a multi-step authentication process. Once authentication is successfully completed, the lightbox automatically closes, and the user is directly navigated to the checkout page, maintaining a smooth and uninterrupted transaction flow.

[0051] By providing a consistent, user-centric interface across different authentication processes, the lightbox solution enhances usability, supports multiple authentication methods, and ensures a secure, context-aware shopping experience on mobile devices. This flexibility not only improves user retention but also aligns with evolving authentication standards, thus providing a future-proof solution.

[0052] refer to Figure 1C , Figure 1C Cross-domain secure authentication with dynamic lightbox integration is illustrated, where the parent page 100C contains a lightbox graphical user interface (GUI) (e.g., lightbox GUI 110A, lightbox GUI 110B, and lightbox GUI 110C) for user authentication without navigating outside the current page. By leveraging the login service domain, the cross-domain secure authentication engine dynamically processes user input, verifies credentials, and authenticates access to the requested resource. This integration maintains context, enhances the user experience, and utilizes robust security features provided by existing authentication infrastructure.

[0053] The parent page 100C provides a seamless user experience through a lightbox GUI 110C that includes a modal overlay interface. The lightbox appears when the user interacts with the page (e.g., initiating a security action or accessing restricted resources) without redirecting the user away from the parent page. The lightbox GUI 110C displays a personalized message such as: “Welcome back! We found the user@email.com account. Please log in using the one-time code we sent to your email address.” This contextual approach reduces friction by recognizing the user and providing a familiar, simplified authentication method.

[0054] Once the user enters a one-time code into the lightbox GUI 120C, the modal window updates dynamically to reflect the ongoing process. When the input is validated on the lightbox GUI 130C, the user is notified with a message such as "Verifying...". This interaction is handled via a login form associated with the existing authentication infrastructure of the login service domain.

[0055] Using an authentication infrastructure based on a login service domain offers several significant advantages. Security is enhanced by centralizing advanced features such as CAPTCHA, rate limiting, and Content Security Policy (CSP) enforcement, ensuring consistent application of these measures. Seamless integration is achieved because the parent page leverages the robustness of the login service domain, avoiding redundant and complex authentication logic. This approach also improves user retention by using users within a lightbox overlay window, preserving their context and reducing the likelihood of churn.

[0056] Furthermore, efficiency is maximized because authentication is handled by the dedicated infrastructure of the login domain. This implementation allows users to securely authenticate to the requested page without leaving the parent page 100C, providing a seamless and secure experience that leverages the existing login infrastructure.

[0057] refer to Figure 2A , Figure 2A The project listing system 100 is shown, which includes a project listing platform 100A, a cross-domain security authentication engine 110, a parent page 112, a child iframe 114, a postMessage API 116, security integration engines 118A and 118B, a user client 120, a login service domain engine 130, and a checkout service domain engine 140.

[0058] Within the item listing system 100, users interact on the item listing platform 100A via a user client 120 (typically a browser or dedicated application), accessing items and considering potential purchases. At some point during user interaction, they may be prompted to proceed to checkout. Traditionally, this would prompt a full-page login, potentially interrupting the purchase experience. Instead, the integration of a cross-domain security authentication engine 110 transforms this interaction into a seamless, embedded process.

[0059] When a user initiates checkout from their client device (user client 120), the parent page 112, hosted on the checkout domain, displays a modal overlay window containing an inline frame of a hosted child iframe 114. This child iframe 114 originates from a dedicated login service domain and loads a minimal authentication UI. This separation ensures that the login logic, including credential processing and secondary factor verification, remains isolated and strictly controlled.

[0060] Since the parent page 112 and the child iframe 114 typically reside on different domains, the browser's same-origin policy prevents direct DOM-level scripting between them. To facilitate secure, event-driven communication, the postMessage API 116 is used. The child iframe 114 can send structured messages to the parent page, such as requests to resize its modal container or signals indicating successful authentication. The parent page 112 then adjusts the modal window layout or continues the checkout process accordingly. From the user client 120's perspective, the interaction of these messaging events completes the user process, eliminating the need to switch contexts or leave an ongoing transaction.

[0061] Security Integration Engine 118A and Security Integration Engine 118B manage oversight of security measures and compliance. They enforce robust protections such as CAPTCHA, CSP directives, rate limiting, and other security measures to maintain the integrity of the authentication process. Security Integration Engine 118A (client-side) and Security Integration Engine 118B (server-side) are components that work together to provide users with a secure and seamless authentication process, particularly for scenarios such as authenticating users in the Item Listing Platform 100A to access the checkout page. These engines are designed to ensure that user credentials are verified, their identity is authenticated, and the integrity of the authentication process is maintained across different domains and sessions.

[0062] The client-side security integration engine 118A handles initial user interactions and authentication-related information on the user's device (e.g., a browser or mobile application). The security integration engine 118A manages tasks requiring direct user input and securely communicates with the server-side system. Key responsibilities include user authentication initiation, session management, secure communication, local verification, and interaction with the server.

[0063] The server-side security integration engine 118B is responsible for handling backend authentication logic, verifying the authenticity of requests, and ensuring that sensitive user data is protected throughout the authentication process. Key responsibilities include authentication verification, token and session management, authorization control, cross-domain authentication, and logging and monitoring.

[0064] Meanwhile, the login service domain engine 130 handles all aspects of verifying user identity, issuing cookies, and maintaining session state. This separation of concerns ensures that the checkout domain codebase remains lightweight and focused on its core functionality. The login service also ensures that the latest security standards are applied, including encryption and token authentication protocols, without requiring frequent updates to the checkout system. Through centralized authentication and session management, the login service reduces the risk of security vulnerabilities in the checkout domain. Furthermore, this approach allows for more flexible and scalable user authentication, as updates to security protocols can be made independent of the checkout system code.

[0065] Session management can be implemented as a small library integrated into each page that performs a session check before the page loads. The code checks authentication cookies (such as JWTs or security tokens) to verify that the user is already logged in. If a valid session exists, the page continues loading; otherwise, the user is redirected to the login page.

[0066] There are two main approaches to session management. The first approach uses a centralized session management platform that handles authentication and session verification across various pages, ensuring a consistent and secure user experience. The second approach involves embedding session management directly into the code of each page, such as a shopping cart or checkout page. In this case, the page code checks for a valid session, and if no session is found, it triggers actions such as displaying a login modal window or initiating checkout.

[0067] In some cases, the parent page can include session verification to determine whether a user needs to be logged in before loading any other content, thus centralizing session checks at a higher level to maintain consistency across multiple pages.

[0068] On the checkout side, the checkout service domain engine 140 continues to manage the shopping cart, pricing, shipping details, and other transaction-related elements. By clearly separating these responsibilities, each domain can be optimized and updated independently. The synergy of these components—the user client (120), parent page (112), child iframe (114), postMessage API (116), security integration engine (118), login service domain engine (130), and checkout service domain engine (140)—enables a streamlined, context-integrated login experience. It ensures that users remain engaged, secure, and informed throughout their transaction, enjoying a coherent and uninterrupted process facilitated by the cross-domain security authentication engine 110.

[0069] Therefore, a cross-domain security authentication engine is a bundled client-side and server-side solution that operates alongside the web pages of the checkout domain. In the checkout service domain 140 (e.g., checkout.example.com), the parent page includes this authentication engine, typically implemented as a JavaScript library. When triggered by a user action (e.g., attempting to checkout), the engine dynamically creates a modal overlay window and loads the login form within an iframe. This cross-domain security authentication engine 110 code, provided by the checkout domain's own server or a trusted CDN, is seamlessly integrated into the page's front-end logic.

[0070] The login form and backend authentication infrastructure reside in the login service domain 130 (e.g., signin.example.com). This dedicated authentication domain handles sensitive operations such as credential verification, CAPTCHA challenge execution, rate limiting, and issuing security tokens. By retrieving an iframe from this domain, the solution ensures that all authentication-related tasks occur within a tightly controlled and security-centric environment, leveraging the domain's dedicated infrastructure and expertise.

[0071] By utilizing the secure cross-origin communication of the postMessage API, communication between the checkout and login domains is fully facilitated on the client side. This API enables structured and secure messaging between the parent page and the iframe, eliminating the need for complex server-side integration. Properly configured event listeners in the JavaScript running on both the parent page and the iframe handle these messages, ensuring smooth and responsive interaction.

[0072] The core functionality of this engine is built around a client-side messaging channel that acts as a secure bridge between the checkout and authentication domains. While the engine itself resides alongside the checkout page, the actual authentication interface and logic remain isolated within the authentication domain. This architecture not only maintains a high level of security but also ensures a smooth user experience, allowing the checkout domain to focus on its primary tasks while delegating all authentication responsibilities to a dedicated login service domain.

[0073] For clarity and effectiveness, a glossary of key terms and concepts related to the technical solution is provided below.

[0074] Parent Page (Checkout Service Domain): In cross-domain authentication settings, the "parent page" is the main webpage that initiates the user's action (e.g., accessing the checkout process). This page typically runs on a domain (e.g., cart.example.com) and is embedded via an iframe containing an external authentication form. The parent page is responsible for hosting the modal overlay window, listening for events from child iframes, and adjusting the checkout-related user interface in response.

[0075] Child iframe (login service domain): A child iframe is a contained, sandboxed environment running on a different domain (e.g., signin.example.com). It renders the actual login form and handles multi-step authentication logic. Due to browser security restrictions, iframes cannot directly manipulate the layout of the parent page and must use messaging protocols to request changes, such as resizing.

[0076] Modal Overlays: Modal overlays are user interface elements that appear on top of the current page content and typically have a darkened or blurred background. In this technical solution, it hosts an iframe-based login form. It can dynamically resize and update based on the authentication steps, thus providing users with a focused yet interrupted but context-sensitive experience.

[0077] Lightbox User Interface: A lightbox interface dims or blurs the page below it to draw attention to the content in the foreground (in this case, the login modal window). This technique keeps users focused on the current task (login) without navigating away from the context of the homepage (e.g., the checkout process).

[0078] Cross-origin secure communication refers to the secure transmission of data between pages hosted on different domains. Standard web security policies prevent direct DOM manipulation or variable sharing across domains. Instead, controlled communication mechanisms such as the postMessage API must be used. In this solution, cross-origin secure communication ensures the secure flow of authentication data, event signals, and layout adjustment requests between the parent page and the iframe.

[0079] The postMessage API is a browser-provided method for sending messages between windows or iframes (even if they are in different domains). It allows child iframes to send structured "resize" or "authentication successful" events to their parent pages without violating the same-origin policy. The parent page can also respond to or initiate communication, thus enabling a secure, two-way interactive channel.

[0080] Parameterized iframes: Parameterized iframes are embedded frames whose URLs or initial load states can include special parameters or flags. These parameters can remove unnecessary UI elements (such as headers, footers, or navigation), creating a minimalist, unobtrusive login experience. Parameterization ensures that the iframe's content can be customized to the limitations of a modal window without code duplication or separate construction.

[0081] Minimalist UI / Minimalist Modal Window Experience: The minimalist user interface focuses on providing only the essential inputs and indicators needed for the current step in the authentication process. By removing extra elements and branding, user distractions are reduced, and the modal window can remain small and focused, thereby improving conversion rates and reducing cognitive load.

[0082] Multi-step authentication process: Authentication doesn't require providing all credentials at once, but typically involves multiple steps, such as entering an email address, then a password, and possibly a one-time PIN or security question. Each step may require different amounts of space in the UI. This solution's dynamic resizing capability ensures that the modal window adapts to the constantly changing layout requirements of these successive authentication steps without forcing a full page reload.

[0083] Dynamic modal window resizing: This concept refers to the ability of a modal overlay window to dynamically adjust its size. For example, when only an email field is displayed, the modal window can remain small. When the user progresses to password input or OTP verification, the iframe sends a "resize" message, prompting the parent page to enlarge the modal window so that the new input field can fit comfortably. This provides a smooth user experience and prevents unnecessary scrolling or cluttered layouts.

[0084] Security features (CAPTCHA, CSP, rate limiting, XSS protection): These are standard security and abuse prevention measures integrated into the certification process.

[0085] CAPTCHA: Ensure that the request comes from a human, not a robot.

[0086] Content Security Policy (CSP): Restricts which scripts and resources can be loaded, thereby reducing the risk of cross-site scripting attacks.

[0087] Rate limiting: Limits the number of authentication attempts within a given time period to prevent brute-force attacks.

[0088] XSS protection: Prevents cross-site scripting attacks by sanitizing input and controlling content injection.

[0089] Authentication token / user status:

[0090] These are data representing a user's authentication status (e.g., session tokens or JWTs). JWTs (JSON Web Tokens), cookies, and tokens are used to manage user authentication and maintain secure sessions. A JWT is a compact URL-secure token used for authentication, containing digitally signed encoded data to verify its authenticity. Cookies store authentication data (e.g., JWTs or other session tokens) on the client's browser. These cookies ensure that users maintain their authenticated status across different pages or sessions. In a broader sense, a token refers to any data (including JWTs, OAuth tokens, or session tokens) used to authenticate or authorize users. These elements are collectively referred to as "authentication credentials" or "security tokens," ensuring secure authentication and authorization of users throughout the system.

[0091] Abandoned cart reminder requests / quick account actions / in-product promotions: these are examples of contexts in which a user might be prompted to log in via a modal overlay window. Instead of forcing a full page reload for login, the system can display the modal window as needed (e.g., when a user attempts to checkout after receiving a reminder email about abandoning their cart).

[0092] Standalone, plug-and-play component: The login modal window solution is designed for easy integration into different workflows and pages with minimal development effort. It does not require tight coupling with the parent page's codebase, allowing teams with different technology stacks to adopt it without significant rewriting.

[0093] Full-page login vs. overlay window login: Traditional methods may redirect users to a separate full-page login screen, leading to loss of context and potential user churn. In contrast, overlay window login keeps users on the same page with a smaller, integrated login box, reducing friction and improving conversion rates.

[0094] By understanding these key terms and concepts, developers and stakeholders can understand how the described technical solutions can enhance user experience, security, and integration flexibility in cross-domain authentication workflows.

[0095] refer to Figure 2B , Figure 2B A schematic diagram 200B is shown, illustrating an embodiment of the cross-domain security authentication engine. The technical solution for the cross-domain security authentication engine can be described through the following steps.

[0096] 201B: Initialization in the parent page (cart domain) — Initially, the parent page (e.g., a page hosted on cart.example.com) is loaded by the user's client, embedding a small JavaScript library for cross-domain authentication and providing minimal placeholders for future modal overlay windows.

[0097] 202B: Triggered Authentication Process – When a user attempts to complete a purchase or other protected action, the parent page recognizes that authentication is required. Instead of redirecting to a separate login screen, the parent page triggers a sequence of dynamically generated modal overlay windows.

[0098] 203B: Modal Overlay Window Creation and Iframe Injection — Then create a modal overlay window element on the parent page. It darkens the background content and provides a clean foreground area. Inject an inline frame (iframe) into this overlay window, with the iframe's source pointing to the login interface available at the dedicated login domain.

[0099] 204B: Parameterized login page (subpage) – The iframe's URL is parameterized to display only basic authentication elements. Headers, footers, and unnecessary UI components are omitted, ensuring a focused login experience free of unnecessary clutter.

[0100] 205B: Initial Load and the “signinLoad” Message – Once the login page within the iframe loads its initial steps (e.g., a single email input field), it sends a “signinLoad” message to the parent page using the postMessage API. Upon receiving this message, the parent page confirms that the interface is ready and prepared for user input.

[0101] 206B: Initial User Input Processing – The user enters their email address into a login field embedded in an iframe. This input is verified by both the client-side and server-side security integration engines, which then determine the next stage – which may involve introducing a password hint or a one-time PIN field.

[0102] 207B: Determine if modal window resizing is needed—If additional screen space is required in the next stage, the iframe calculates the new size needed for the modal window. The login page cannot directly resize the parent page's modal window, therefore it must rely on cross-domain messaging.

[0103] 208B: Sending a resize request via postMessage—Through the postMessage API, the iframe sends a "resize" request to the parent page, specifying the exact width and height required for the next step. This is a structured message that the parent page is configured to recognize and trust.

[0104] 209B: Parent Page Resizes Modal Overlay Window—Upon receiving a resize message, the parent page dynamically adjusts the modal overlay window's CSS properties, smoothly increasing its size so that users can comfortably view the additional authentication elements. This adjustment does not require a page reload, thus preserving the user's context.

[0105] 210B: Advance the authentication process in a subpage—by resizing the modal window now, the next set of authentication inputs (password field or OTP input) can be presented via an iframe. As the user continues to provide credentials, the login logic, executed by the dedicated login service domain, handles CAPTCHA, CSP rules, and rate limiting measures.

[0106] 211B: Report Successful Authentication – Once the user's authentication is confirmed, the iframe sends a "success" message via postMessage. The parent page recognizes this signal as the end of the login process.

[0107] 212B: Closing the Modal Window and Resuming Checkout—After receiving the success message, the parent page removes the modal overlay window and iframe from the DOM, thus returning the user's focus to the original checkout page. With valid authentication credentials, the parent page can now proceed with the protected checkout process—completing the purchase and submitting order details.

[0108] It's conceivable that in the event of an error (e.g., an invalid password), the iframe could send an "Error" message, prompting the parent page to display the error state within the modal window or gracefully handle the situation. If the user closes the modal window prematurely, the "Close" message causes the parent page to revert to its previous state without completing authentication. This arrangement supports scalability: new authentication factors, updated UI flows, or integration with additional domains can be introduced by adjusting parameters, message types, or supported UI elements. Future enhancements will only require updates within the login domain or configuration logic, without requiring a complete redesign of the architecture.

[0109] In this way, steps 201B to 212B outline the technical solutions for maintaining a seamless, context-aware authentication process. The parent page, user client, iframe, and cross-domain messaging work together to ensure a smooth user experience while maintaining security, compliance, and modular scalability.

[0110] For example, when a user visits a parent page (e.g., a shopping cart or checkout page hosted on a first domain (e.g., cart.example.com)) and initiates an action requiring authentication (e.g., accessing the checkout process or responding to an abandoned cart reminder), a modal overlay window is dynamically generated. This modal overlay window is a lightbox user interface that dims or blurs the background to preserve the user's context when a login form is introduced.

[0111] The login form is hosted in an inline iframe originating from the login service domain (e.g., signin.example.com). This iframe is parameterized to remove unnecessary elements such as headers and footers, resulting in a minimalist interface tailored to the modal context. A cross-domain security authentication engine ensures communication between parent and child pages via the postMessage API (a secure messaging protocol that allows structured cross-domain interactions while adhering to strict security policies).

[0112] Initially, the login form displays a single input field (e.g., email address). When the user enters their email address (the first user input) and submits it, the child iframe determines that the next authentication step requires more screen space, such as for a password or one-time PIN (OTP). Because the iframe cannot directly resize its container due to security restrictions, it uses the postMessage API to send a resize event. This event sends the new size required for the modal overlay window to the parent page.

[0113] Upon receiving a resize event, the parent page dynamically adjusts the size of the modal window. This process is part of a dynamic modal window resizing mechanism that supports multi-step authentication. When the updated modal overlay appears, the user sees additional input fields rendered by the updated login form within the iframe.

[0114] The user then provides their second user input (e.g., a password or OTP) via an updated login form. This input is validated by the login service domain, which uses application authentication security mechanisms including CAPTCHA, CSP enforcement, and rate limiting. Once the second input is validated, the iframe securely sends an authentication success event back to the parent page via the postMessage API.

[0115] A multi-step authentication process, supported by a modular architecture and secure cross-source communication, enables seamless login interactions. These interactions, triggered by actions such as shopping cart access or account updates, maintain the user's flow and context, thus providing an optimized, secure authentication experience embedded within the e-commerce workflow.

[0116] Examples and references are available. Figures 1A to 1C, Figure 2A and Figure 2B To describe aspects of the technical solution. Figure 2A Based on reference Figure 6 , Figure 7 and Figure 8 A block diagram of an exemplary technical solution environment for implementing embodiments of the technical solution. Typically, this technical solution environment includes a technical solution system suitable for providing an example item list system 100 that can employ the methods of this disclosure. Specifically, Figure 2A A high-level architecture of an item list system 100 according to an embodiment of this disclosure is shown. In addition to other engines, managers, generators, selectors, or components not shown (collectively referred to herein as "components"), Figure 2A Project list platform system 100 supports Figures 1A to 1C The functions described above.

[0117] Example Method

[0118] refer to Figure 3 , Figure 4 and Figure 5 The flowchart illustrates a method for providing a cross-domain secure authentication engine in an item list system. This method can be executed using the item list system described herein. In embodiments, one or more computer storage media have computer-executable or computer-usable instructions embodied thereon that, when executed by one or more processors, can cause one or more processors to perform methods (e.g., computer-implemented methods) within the item list system (e.g., a computerized system or computer system).

[0119] refer to Figure 3 The document provides a flowchart illustrating method 300 for providing a cross-domain security authentication engine in an item listing system. At box 302, the cross-domain security authentication engine accesses a parent page request that triggers a login service form to access the checkout process. At box 304, the cross-domain security authentication engine generates a modal overlay window including a login form associated with the login service domain. At box 306, the cross-domain security authentication engine determines that a first user input triggers resizing of the modal overlay window. At box 308, the cross-domain security authentication engine sends a resizing event to the parent page. At box 310, the cross-domain security authentication engine generates a resized modal overlay window including an updated login form. At box 312, the cross-domain security authentication engine authenticates access to the checkout process based on a second user input received via the updated login form.

[0120] Turning Figure 4The document provides a flowchart illustrating method 400 for providing a cross-domain secure authentication engine in a project listing system. At box 402, the login service domain causes the generation of a modal overlay window including a login form. At box 404, the login service domain validates first user input received via the login form. At box 406, the login service domain determines that the first user input triggers an adjustment of the modal overlay window's size. At box 408, the login service domain causes a resizing event to be sent to the parent page. At box 410, the login service domain validates second user input received via an updated login form. At box 412, the login domain authenticates access based on the second user input received via the updated login form.

[0121] Turning Figure 5 A flowchart illustrating method 500 for providing a cross-domain secure authentication engine in an item listing system is provided. At box 502, the user client causes the parent page to be displayed. At box 504, the user client transmits a request received via the parent page. This request triggers a login form to access the checkout page. At box 506, the user client causes a modal overlay window to be displayed, including a login form associated with the login service domain. At box 508, the user client causes a resized modal window to be displayed, associated with a resizing event transmitted to the parent page. At box 510, the user client causes the checkout page associated with the checkout process to be displayed based on access to the checkout process via a second user input authentication received via the resized modal window.

[0122] Technological improvements

[0123] Embodiments of the invention have been described with reference to various inventive features (e.g., operations, systems, engines, and components) associated with a project listing system. The described inventive features include the operations, interfaces, data structures, and arrangements of computational resources associated with providing the functionality described herein, which relates to a cross-domain secure authentication engine associated with the project listing system.

[0124] Embodiments of the present invention relate to the field of computing, and more specifically to item list systems. The exemplary embodiments described below particularly provide systems, methods, and program products for performing generative cross-domain secure authentication engine operations that provide improved seamless authentication. Therefore, this embodiment improves the technical field of authentication and item list platform technologies by introducing scalable, efficient, and nuanced methods for modeling user preferences and generating personalized recommendations.

[0125] For example, by isolating the authentication process within a dedicated login service domain, sensitive operations such as credential verification, CAPTCHA enforcement, rate limiting, and token issuance are ensured to occur in a highly controlled and secure environment. This separation reduces the risk of vulnerabilities arising from improper handling of authentication logic in the checkout domain, while leveraging the expertise of specialized infrastructure.

[0126] Using a cross-domain secure authentication engine integrated into the checkout domain frontend provides flexibility and seamless user interaction. Modal overlay windows allow users to complete the login process without leaving the checkout page, preserving their context and reducing the likelihood of abandonment. Dynamically loading the login form within an iframe originating from the authentication domain ensures the authentication workflow can be updated or enhanced without altering the core code of the checkout domain.

[0127] Secure cross-origin communication via the postMessage API eliminates the need for complex server-side integration between domains. This approach simplifies the architecture while adhering to strict security policies, as all sensitive data is exchanged through controlled and authenticated messaging channels. Properly configured event listeners on both the parent page and the iframe ensure robust communication and responsiveness, enabling features such as dynamically resizing modal overlay windows and real-time updates during multi-step authentication processes. In this way, the technical solution offers several significant advantages in both enhanced functionality and security.

[0128] The functionality of embodiments of the invention has been further described through implementations and anecdotal examples—demonstrating that the operations used to provide authentication using a cross-domain secure authentication engine in an item list system are a solution to a specific problem in artificial intelligence technology to improve computational operations in the item list system. Overall, these improvements result in less CPU computation, lower memory requirements, and increased flexibility in the item list system compared to previous conventional item list system operations performed for similar functionality.

[0129] Additional support for the detailed description of the invention

[0130] Example project list system environment

[0131] Now for reference Figure 6 , Figure 6 A computing environment for an example item listing system 600 capable of employing embodiments of this disclosure is shown. Specifically, Figure 6A high-level architecture of platform 610, a sample project list capable of hosting a technical solution environment or a portion thereof, is shown. It should be understood that this and other arrangements described herein are illustrated as examples. For instance, as mentioned above, many of the elements described herein can be implemented as discrete or distributed components or combined with other components, and implemented in any suitable combination and location. Other arrangements and elements (e.g., machine, interface, function, command, and function groupings) may be used in addition to or in place of the arrangements and elements shown.

[0132] The project listing system 600 may be a cloud computing environment that provides computing resources for the functions associated with the project listing platform 610. For example, the project listing system 600 supports the delivery of computing components and services, including servers, storage, databases, networks, applications, and machine learning associated with the project listing platform 610 and client devices 620. Multiple client devices (e.g., client device 620) include hardware or software for accessing resources on the project listing system 600. Client device 620 may include applications (e.g., client application 622) and interface data (e.g., client application interface data 624) that support client functions associated with the project listing system. Multiple client devices may access the computing components of the project listing system 600 via a network (e.g., network 630) to perform computing operations.

[0133] The project listing platform 610 is responsible for providing a computing environment or architecture, which includes the infrastructure to support the provision of project listing platform functionality (e.g., e-commerce functionality). The project listing platform supports storing projects in a project database and provides a search system for receiving queries and identifying search results based on those queries. The project listing platform can also provide a computing environment with features for managing, selling, purchasing, and recommending different types of projects. The project listing platform 610 can be specifically used as a content platform, such as the eBay content platform or e-commerce platform developed by eBay Inc. of San Jose, California.

[0134] The project list platform 610 can provide project list operations 630 and project list interfaces 640. Project list operations 630 may include service operations, communication operations, resource management operations, security operations, and fault-tolerance operations that support specific tasks or functions within the project list platform 610. Project list interfaces 640 may include service interfaces, communication interfaces, resource interfaces, security interfaces, and management and monitoring interfaces that support functions between project list platform components. Project list operations 630 and project list interfaces 640 enable communication, coordination, and seamless operation of the project list system 600.

[0135] As an example, the functionalities associated with the item listing platform 610 may include: shopping operations (e.g., product search and browsing, product selection and shopping cart, checkout and payment, and order tracking); user account operations (e.g., user registration and authentication, and user profiles); seller and product management operations (e.g., seller registration, product listing, and inventory management); payment and financial operations (e.g., payment processing, refunds, and returns); order fulfillment operations (e.g., order processing and fulfillment, and inventory management); customer support and communication interfaces (e.g., customer support chat / email and notifications); security and privacy interfaces (e.g., authentication and authorization, payment security); recommendation and personalization interfaces (e.g., product recommendations and customer reviews and ratings); analytics and reporting interfaces (e.g., sales and inventory reports, and user behavior analytics); and APIs and integration interfaces (e.g., APIs for third-party integration).

[0136] The project listing platform 610 can provide a project listing platform database (e.g., project listing platform database 650) to effectively manage and store different types of data. The project listing platform database 650 may include relational databases, NoSQL databases, search databases, cache databases, content management systems, analytics databases, payment gateway databases, customer relationship management databases, log and error databases, inventory and supply chain databases, and multi-channel databases, which are used in combination to effectively manage data and provide users with an e-commerce experience.

[0137] The project listing platform 610 supports applications (e.g., application 660), which are computer programs, software components, or services that serve a specific function or set of functions to meet the requirements of a specific project listing platform or user requirements. Applications can be client-side (user-facing) and server-side (backend). Applications can also include applications without any AI support (e.g., application 662), applications supported by traditional AI models (e.g., application 664), and applications supported by generative AI models (e.g., application 666). As examples, applications may include online storefront applications, mobile shopping applications, management consoles, payment gateway integrations, user account and authentication applications, search and recommendation engines, inventory and stock management applications, order processing and fulfillment applications, customer support and communication tools, content management systems, analytics and reporting applications, marketing and promotion applications, multi-channel integration applications, log and bug tracking applications, customer relationship management (CRM) applications, security applications, and APIs and web services, which are combined to effectively provide users with an e-commerce experience.

[0138] Platform 610 in the project list may include a machine learning engine (e.g., machine learning engine 670). Machine learning engine 670 refers to a machine learning framework or platform that provides the infrastructure and tools for designing, training, evaluating, and deploying machine learning models. Machine learning engine 670 can serve as the backbone for developing and deploying machine learning applications and solutions. Machine learning engine 670 may also provide tools for visualizing data and model results, as well as interpreting model decisions to understand how the model makes predictions.

[0139] The Machine Learning Engine 670 provides the necessary libraries, algorithms, and utilities to perform various tasks within a machine learning workflow. Machine learning workflows can include data processing, model selection, model training, model evaluation, hyperparameter tuning, scalability, model deployment, inference, integration, customization, and data visualization. The Machine Learning Engine 670 can include pre-trained models for various tasks, thus simplifying the development process. In this way, the Machine Learning Engine 670 streamlines the entire machine learning process, from data preparation and model training to deployment and inference, making it accessible and efficient for different types of users engaged in a wide range of machine learning applications—e.g., clients, data scientists, machine learning engineers, and developers.

[0140] Machine learning engine 670 can be implemented as a component in item list system 600, which leverages machine learning algorithms and techniques (e.g., machine learning algorithm 672) to enhance various aspects of the item list system's functionality. Machine learning engine 670 can provide a range of machine learning algorithms and techniques for teaching computers to learn from data and make predictions or decisions without explicit programming. These techniques are widely used in various applications across different industries and include examples such as: supervised learning (e.g., linear regression: classification, support vector machines (SVM)); unsupervised learning (e.g., clustering, principal component analysis (PCA), association rules (e.g., priors)); reinforcement learning (e.g., Q-learning, deep Q-networks (DQN)); deep learning (e.g., neural networks, convolutional neural networks (CNN), and recurrent neural networks (RNN)); and ensemble learning random forests.

[0141] Machine Learning Training Data 120 supports the process of building, training, and fine-tuning machine learning models. Machine Learning Training Data 120 consists of labeled datasets used to teach machine learning models to recognize patterns, make predictions, or perform specific tasks. Training data typically includes two main components: input features (X) and labels or target values ​​(Y). Input features can include variables, attributes, or characteristics that serve as input to the machine learning model. Input features (X) can be numerical, categorical, or even textual, depending on the nature of the problem. For example, in a model used to predict house prices, input features might include the number of bedrooms, square feet, neighborhood, etc. Labels or target values ​​(Y) include the values ​​that the model aims to predict or classify. Labels represent the expected output or basic fact for each corresponding set of input features. For example, in a spam classifier, labels would indicate whether each email is spam (i.e., binary classification). The training process involves feeding training data to the model, and the model learns to make predictions or decisions by recognizing patterns and relationships between the input features (X) and target values ​​(Y). Machine learning algorithms adjust their internal parameters during training to minimize the discrepancy between their predictions and the actual labels in the training data. The Machine Learning Engine 670 can use historical and real-time data to train models and make predictions, thereby continuously improving performance and user experience.

[0142] Machine learning engine 670 may include machine learning models (e.g., machine learning model 676) generated using machine learning engine workflows. Machine learning model 676 may include generative AI models and traditional AI models, both of which can be used in item listing system 600. Generative AI models are designed to generate new data (typically in the form of text, images, or other media) based on patterns and knowledge learned from existing data. Generative AI models can be used in a variety of ways, including: content generation, product image generation, personalized product recommendations, natural language chatbots, and content summarization. Traditional AI models encompass a wide range of algorithms and techniques and can be used in a variety of ways, including: recommender systems, predictive analytics, search algorithms, fraud detection, customer segmentation, image classification, natural language processing (NLP), and A / B testing and optimization. In many cases, a combination of generative AI models and traditional AI models can be used to deliver a comprehensive and efficient e-commerce experience, combining data-driven insights and creativity.

[0143] Machine learning engines 670 can be used to analyze data, make predictions, and automate processes to provide users with a more personalized and efficient shopping experience. Examples include product recommendation search and filtering; pricing optimization; inventory and stock management; customer segmentation; customer churn prediction and retention; fraud detection; sentiment analysis; customer support and chatbots; image and video analytics; and ad targeting and marketing. The specific applications of machine learning within the project list platform 610 can vary depending on the specific objectives, available data, and resources.

[0144] The item list system 600 provides item list system data that informs customer service interactions. Therefore, it can work with a customer service management system (e.g., customer service management system 100 in Figure 1) to resolve any issues or questions arising from these item lists. The customer service management system can be a software solution designed to simplify and automate the processing of customer inquiries and support requests across various communication channels. The customer service management system centrally manages customer interactions, allowing service teams to efficiently categorize, prioritize, and resolve issues while tracking and managing the entire lifecycle of each case. Through integrated tools such as ticketing systems, knowledge bases, and automation features (e.g., AI-driven chatbots), the customer service management system reduces response times, minimizes manual intervention, and ensures consistently high-quality customer service. The item list system and the customer service management system can be integrated to ensure seamless communication and efficient resolution of customer issues.

[0145] Example Distributed Computing System Environment

[0146] Now for reference Figure 7 , Figure 7 An example distributed computing environment 700 capable of employing embodiments of the present disclosure is shown. Specifically, Figure 7 A high-level architecture of an example cloud computing platform 710 capable of hosting a technology solution environment or a portion thereof (e.g., a data trustee environment) is illustrated. It should be understood that this and other arrangements described herein are illustrative only. For example, as stated above, many of the elements described herein can be implemented as discrete or distributed components or in combination with other components, and implemented in any suitable combination and location. Other arrangements and elements (e.g., machines, interfaces, functions, commands, and function groups) may be used in addition to or in place of the arrangements and elements shown.

[0147] The data center can support a distributed computing environment 700, which includes a cloud computing platform 710, racks 720, and nodes 730 (e.g., computing devices, processing units, or blades) within the racks 720. A technical solution environment can be implemented using the cloud computing platform 710, which runs cloud services across different data centers and geographical regions. The cloud computing platform 710 can implement a fabrication controller 740 component for providing and managing the resource allocation, deployment, upgrades, and management of cloud services. Typically, the cloud computing platform 710 is used to store data or run service applications in a distributed manner. The cloud computing infrastructure 710 in the data center can be configured to host and support the operation of endpoints for specific service applications. The cloud computing infrastructure 710 can be a public cloud, a private cloud, or a dedicated cloud.

[0148] Node 730 may provide a host 750 (e.g., an operating system or runtime environment) on which a defined software stack runs on Node 730. Node 730 may also be configured to perform specialized functions (e.g., compute node or storage node) within the cloud computing platform 710. Node 730 is allocated to run one or more portions of a tenant's service application. A tenant may refer to a customer utilizing the resources of the cloud computing platform 710. The service application components of the cloud computing platform 710 supporting a particular tenant may be referred to as multi-tenant infrastructure or lease. In this document, the terms service application, application, or service are used interchangeably and broadly refer to any software or software portion that runs on top of or accesses storage and compute equipment locations within a data center.

[0149] When node 730 is supporting more than one individual service application, node 730 can be partitioned into virtual machines (e.g., virtual machine 752 and virtual machine 754). Physical machines can also run individual service applications simultaneously. Virtual machines or physical machines can be configured as personalized computing environments supported by resources 760 (e.g., hardware and software resources) in the cloud computing platform 710. It is envisioned that resources can be configured for specific service applications. Furthermore, each service application can be divided into functional parts, allowing each functional part to run on a separate virtual machine. In the cloud computing platform 710, multiple servers can be used to run service applications and perform data storage operations in a cluster. Specifically, servers can perform data operations independently, but are presented as a single device referred to as a cluster. Each server in the cluster can be implemented as a node.

[0150] Client device 780 can connect to service applications in cloud computing platform 710. Client device 780 can be configured to correspond to a reference... Figure 7Any type of computing device described in the computing device 700, such as client device 780, can be configured to issue commands to the cloud computing platform 710. In embodiments, client device 780 can communicate with service applications via Virtual Internet Protocol (IP) and load balancers or other means of directing communication requests to designated endpoints in the cloud computing platform 710. Components of the cloud computing platform 710 can communicate with each other via a network (not shown), which may include, but is not limited to, one or more local area networks (LANs) and / or wide area networks (WANs).

[0151] Example computing environment

[0152] Having briefly described the overview of embodiments of the present invention, the following describes an example operating environment in which embodiments of the present invention can be implemented, in order to provide a general context for various aspects of the present invention. Specifically, reference is made first to... Figure 8 An example operating environment for implementing embodiments of the present invention is shown and is generally designated as computing device 800. Computing device 800 is merely an example of a suitable computing environment and is not intended to imply any limitation on the scope or functionality of the invention. Nor should computing device 800 be construed as having any dependency or requirement associated with any one or combination of the illustrated components.

[0153] This invention can be described in the general context of computer code or machine-usable instructions, including computer-executable instructions (e.g., program modules) that are executed by a computer or other machine (e.g., a personal data assistant or other handheld device). Generally, a program module, including routines, programs, objects, components, data structures, etc., refers to code that performs a specific task or implements a specific abstract data type. This invention can be practiced in a variety of system configurations, including handheld devices, consumer electronics, general-purpose computers, and more specialized computing devices. This invention can also be practiced in distributed computing environments, where tasks are performed by remote processing devices linked via a communication network.

[0154] refer to Figure 8 The computing device 800 includes a bus 810 that directly or indirectly couples to the following devices: memory 812, one or more processors 814, one or more presentation components 816, input / output ports 818, input / output components 820, and a schematic power supply 822. Bus 810 represents one or more buses (such as an address bus, a data bus, or a combination thereof). For clarity of concept, Figure 8 The various boxes are shown with lines, and other arrangements of the described components and / or component functions are also envisioned. For example, a presentation component such as a display device can be considered an I / O component. Additionally, a processor has memory. We recognize this as essential to the art and reiterate... Figure 8The figures are merely illustrative examples of computing devices that can be used in conjunction with one or more embodiments of the present invention. There is no distinction between categories such as “workstation,” “server,” “laptop,” and “handheld device,” as all of these categories are... Figure 8 Within the scope and with reference to "Computing Devices".

[0155] Computing device 800 typically includes a variety of computer-readable media. Computer-readable media can be any available medium that can be accessed by computing device 800, and includes volatile and non-volatile media, removable and non-removable media. By way of example and not limitation, computer-readable media can include computer storage media and communication media.

[0156] Computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to: RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, Digital Universal Optical Disc (DVD) or other optical disc storage devices, magnetic tape cassettes, magnetic tape, disk storage devices or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computing device 800. Computer storage media does not include the signal itself.

[0157] Communication media typically embody computer-readable instructions, data structures, program modules, or other data in the form of modulated data signals (e.g., carrier waves or other transmission mechanisms), and include any information transmission medium. The term "modulated data signal" refers to a signal having one or more characteristics set or altered in a manner that encodes information in the signal. By way of example and not limitation, communication media include wired media such as wired networks or direct wired connections, and wireless media such as acoustic, RF, infrared, and other wireless media. Any combination of the above should also be included within the scope of computer-readable media.

[0158] Memory 812 includes computer storage media in the form of volatile memory and / or non-volatile memory. The memory can be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard disk drives, optical disk drives, etc. Computing device 800 includes one or more processors that read data from various entities such as memory 812 or I / O components 820. Presentation component 816 presents data indications to a user or other device. Exemplary presentation components include display devices, speakers, printing components, vibration components, etc.

[0159] I / O port 818 allows computing device 800 to be logically coupled to other devices, including I / O components 820 (some of which may be built-in). Illustrative components include microphones, joysticks, game controllers, satellite antennas, scanners, printers, wireless devices, etc.

[0160] Additional structural and functional features of embodiments of this technical solution

[0161] Having identified the various components used herein, it should be understood that any number of components and arrangements can be employed to achieve the desired functionality within the scope of this disclosure. For example, for clarity of concept, components in the embodiments depicted in the accompanying drawings are shown in lines. Other arrangements of these and other components can also be implemented. For example, although some components are depicted as single components, many elements described herein can be implemented as discrete or distributed components or combined with other components, and implemented in any suitable combination and location. Some elements may be omitted entirely. Furthermore, as described below, the various functions performed by one or more entities described herein can be performed by hardware, firmware, and / or software. For example, various functions can be performed by a processor executing instructions stored in memory. Therefore, other arrangements and elements (e.g., machines, interfaces, functions, commands, and function groups) may be used in addition to or in place of the arrangements and elements shown.

[0162] The embodiments described in the following paragraphs can be combined with one or more of the specifically described alternatives. Specifically, the claimed embodiments may include references to more than one other embodiment in the alternatives. The claimed embodiments may specify additional limitations on the claimed subject matter.

[0163] This document specifically describes the subject matter of embodiments of the invention to meet legal requirements. However, this specification itself is not intended to limit the scope of this patent. Rather, the inventors have envisioned that the claimed subject matter may also be embodied in other ways in combination with other prior art or future art to include different steps or combinations of steps similar to those described in this document. Furthermore, although the terms “step” and / or “box” may be used herein to denote different elements of the method employed, such terms should not be construed as implying any particular order between or between the various steps disclosed herein, unless and only if the order of the various steps is explicitly described.

[0164] For the purposes of this disclosure, the word "comprising" has the same broad meaning as the word "including," and the word "access" includes "receiving," "quoting," or "retrieval." Furthermore, the word "communication" has the same broad meaning as the words "receiving" or "transmitting," which is facilitated by a software- or hardware-based bus, receiver, or transmitter using the communication medium described herein. Additionally, unless otherwise stated, words such as "a" or "an" include both plural and singular forms. Thus, for example, the constraint "one feature" is satisfied when one or more features are present. Furthermore, the term "or" includes conjunctions, disjuncts, and both (a or b therefore includes a or b, and a and b).

[0165] For the purposes of the detailed discussion above, embodiments of the present invention are described with reference to a distributed computing environment; however, the distributed computing environment described herein is merely exemplary. Components may be configured to perform novel aspects of the embodiments, wherein the term "configured for" may mean "programmed to" perform a specific task or implement a specific abstract data type using code. Furthermore, while embodiments of the present invention can generally be referred to in the technical environment and illustrations described herein, it should be understood that the described techniques can be extended to other implementation contexts.

[0166] Embodiments of the invention have been described with reference to specific embodiments intended to be illustrative and not limiting in all respects. Alternative embodiments will become apparent to those skilled in the art without departing from the scope of the invention.

[0167] As can be seen from the foregoing, this invention is well-suited to achieving all the goals and objectives set forth herein, as well as other obvious and inherent advantages of the structure.

[0168] It should be understood that certain features and sub-combinations are useful and can be employed without reference to other features or sub-combinations. This is contemplated by the claims and is within the scope of the claims.

Claims

1. A computerized system, comprising: One or more computer processors; as well as A computer memory stores computer-usable instructions that, when used by the one or more computer processors, cause the one or more computer processors to perform operations, the operations including: A request to access the checkout process is triggered via a login form accessed through a parent page associated with a first domain; Based on the request, a modal overlay window is generated including a login form associated with a login service domain, which is different from the first domain; A first user input is determined to trigger an adjustment of the size of the modal overlay window, wherein the first user input is received via the login form; Based on determining that the first input triggers the adjustment of the size of the modal overlay window, an adjustment event is transmitted to the parent page, wherein the adjustment event is a cross-origin secure communication associated with the login service domain and the first domain; Based on the resizing event transmitted to the parent page, a resized modal overlay window is generated, the resized modal overlay window including an updated login form associated with the login service domain; and Access to the checkout process is authenticated based on the second user input received via the updated login form.

2. The system according to claim 1, wherein, The request corresponds to a seamless login interaction selected from one of the following: shopping cart access request, quick account action request, in-product promotion request, and abandoned shopping cart reminder request.

3. The system according to claim 1, wherein, The parent page is either the shopping cart page associated with the shopping cart service domain or the checkout page associated with the checkout service domain.

4. The system according to claim 1, wherein, The modal overlay window supports a modular architecture with embedded inline frames to load the login form from the login service domain, which operates as an existing authentication infrastructure supporting a full-page login process associated with the login service domain.

5. The system according to claim 1, wherein, The modal overlay window is an inline frame that is parameterized to selectively remove unnecessary elements, and wherein the modal overlay window is a lightbox user interface that darkens or blurs the background content.

6. The system according to claim 1, wherein, The generation of the modal overlay window is associated with adjusting the size of the modal overlay window based on an initial resizing event, which is sent to the parent page to initially display the modal overlay window.

7. The system according to claim 1, wherein, Cross-origin secure communication enables communication between a parent page and a child inline frame, and this cross-origin secure communication is implemented via the first domain using the existing infrastructure of the login service domain.

8. The system according to claim 1, wherein, The resizing event supports dynamic modal window resizing, which allows the modal overlay window to be adjusted based on the current step of the authentication process associated with the login service domain.

9. The system according to claim 1, wherein, The resizing event is associated with the postMessage API to comply with security policies associated with resizing inline frames, the postMessage API supporting custom resizing events from the modal overlay window to the parent page.

10. The system according to claim 1, wherein, The modal overlay window supports multi-step authentication and dynamically adjusts the modal overlay window, wherein the multi-step authentication is associated with one or more authentication security mechanisms.

11. One or more computer storage media having computer-executable instructions embodied thereon, which, when executed by a computing system having a processor and a memory, cause the processor to perform operations, the operations including: Using a login service domain enables the generation of a modal overlay window that includes a login form associated with the login service domain, which authenticates access to the service; Verify the first user input received via the login form; It is determined that the first user input triggers an adjustment of the size of the modal overlay window, wherein the first user input is received via the login form; Based on the determination that the first input triggers the adjustment of the size of the modal overlay window, an adjustment event is transmitted to the parent page; Verify the second user input received via the updated login form associated with the resizing event; and Access to the service is authenticated based on a second user input received via the updated login form.

12. The medium according to claim 11, wherein, The modal overlay window is generated based on a request associated with the parent page, wherein the modal overlay window is an inline frame that is parameterized to selectively remove unnecessary elements.

13. The medium according to claim 11, wherein, Cross-origin secure communication enables communication between a parent page and a child inline frame, and the cross-origin secure communication is implemented via a first domain using the existing infrastructure of the login service domain.

14. The medium according to claim 11, wherein, The resizing event supports dynamic modal window resizing, which allows the modal overlay window to be adjusted based on the current step of the authentication process.

15. The medium according to claim 11, wherein, The modal overlay window supports multi-step authentication and dynamically adjusts the modal overlay window, wherein the multi-step authentication is associated with one or more authentication security mechanisms.

16. A computer-implemented method, the method comprising: The login form request is triggered via a parent page, which is associated with the first domain; Based on the request, a modal overlay window is generated including a login form associated with a login service domain, which is different from the first domain; A first user input is determined to trigger an adjustment of the size of the modal overlay window, wherein the first user input is received via the login form; Based on determining that the first input triggers the adjustment of the size of the modal overlay window, an adjustment event is transmitted to the parent page, wherein the adjustment event is a cross-origin secure communication associated with the login service domain and the first domain; Based on the resizing event transmitted to the parent page, a resized modal overlay window is generated, the resized modal overlay window including an updated login form associated with the login service domain; and The user is authenticated based on second user input received via the updated login form.

17. The computer-implemented method according to claim 16, wherein, Cross-origin secure communication enables communication between a parent page and a child inline frame, and this cross-origin secure communication is implemented via the first domain using the existing infrastructure of the login service domain.

18. The computer-implemented method according to claim 16, wherein, The resizing event supports dynamic modal window resizing, which allows the modal overlay window to be adjusted based on the current step of the authentication process.

19. The computer-implemented method according to claim 16, wherein, The resizing event is associated with the postMessage API to circumvent security policies associated with resizing inline frames. The postMessage API supports custom resizing events from the modal overlay window to the parent page.

20. The computer-implemented method according to claim 16, wherein, The modal overlay window supports multi-step authentication and dynamically adjusts the modal overlay window, wherein the multi-step authentication is associated with one or more authentication security mechanisms.

Images