WO2023248179A1 - Actions d'application dans un système de gestion de contenu - Google Patents

Actions d'application dans un système de gestion de contenu Download PDF

Info

Publication number
WO2023248179A1
WO2023248179A1 PCT/IB2023/056468 IB2023056468W WO2023248179A1 WO 2023248179 A1 WO2023248179 A1 WO 2023248179A1 IB 2023056468 W IB2023056468 W IB 2023056468W WO 2023248179 A1 WO2023248179 A1 WO 2023248179A1
Authority
WO
WIPO (PCT)
Prior art keywords
app
content
cms
request
action
Prior art date
Application number
PCT/IB2023/056468
Other languages
English (en)
Inventor
Manuel Spagnolo
Fabian Schultz
Paolo Negri
Ryan Scott
Original Assignee
Contentful GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US17/846,646 external-priority patent/US11886620B2/en
Application filed by Contentful GmbH filed Critical Contentful GmbH
Publication of WO2023248179A1 publication Critical patent/WO2023248179A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/629—Protecting access to data via a platform, e.g. using keys or access control rules to features or functions of an application
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102—Entity profiles
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices

Definitions

  • the present disclosure relates to inter-app action triggering in a content management system.
  • a content management system provides many benefits by allowing users to flexibly structure and manage content, independent of the presentation of such content through various contexts such as websites and mobile apps.
  • Content can be composed in a modular format, enabling an individual piece of content to be created once, and then reused across different presentation contexts. Further, the appearance of content can be adjusted to suit the presentation context at the time it is retrieved and presented to the consuming end user.
  • Implementations of the present disclosure include methods and systems relating to inter-app action triggering in a content management system.
  • a method implemented in a content management system for providing integration between APPS configured for use with an editor application of the CMS, including: installing a first APP and a second APP in a content project of the CMS, wherein installing the first and second APPs enables functionalities of the first and second APPs to be accessed for the content project through the editor application, wherein the editor application provides an interface for editing the content project; receiving from the first APP a request to invoke an action by the second APP; responsive to receiving the request, then validating contents of the request; responsive to successful validation of the request, then sending an acknowledgement to the first APP, and generating a call to the second APP to invoke the action by the second APP.
  • the method enables the first APP to trigger the action by the second APP without requiring the first APP to communicate with the second APP.
  • the request from the first APP to invoke the action by the second APP is received through an API of the CMS.
  • validating the contents of the request includes verifying whether the contents of the request adhere to predefined parameter requirements for invoking the action by the second APP.
  • authorizing the request includes verifying, based on a setting of the content project, that the first APP is authorized to request to invoke the action by the second APP.
  • installing the second APP exposes the action of the second APP for invocation through the CMS during editing of the content project.
  • installing the first APP includes configuring a permission setting of the content project to allow the first APP to invoke the action of the second APP.
  • the acknowledgement indicates the successful validation of the request.
  • the call to the second APP is configured to be asynchronous, such that the CMS does not wait for a result of the call to the second APP.
  • the content project includes a plurality of content types and a plurality of content entries, said content entries being structured in accordance with said content types, said content entries being configured to store content of the content project that is editable through the editor application.
  • the editor application is defined by a web application rendered through a client browser.
  • the request from the first APP is received in response to occurrence of a predefined event of the first APP, such that the method enables automated triggering of the action of the second APP in response to the occurrence of the predefined event of the first APP.
  • the call to the second APP is defined by an HTTP call to a URL of the second APP.
  • FIG. 1 conceptually illustrates a content management system (CMS) 100, and entities that interact with the CMS 100, in accordance with implementations of the disclosure.
  • CMS content management system
  • FIG. 2 conceptually illustrates a content project (also termed a space), in accordance with implementations of the disclosure.
  • Figure 3 A conceptually illustrates a system for providing app functionality to extend the content management capabilities of a content management system, in accordance with implementations of the disclosure.
  • Figure 3B conceptually illustrates an application framework for installation of APPs to interact with a CMS, in accordance with implementations of the disclosure.
  • FIG. 4 conceptually illustrates front-end and back-end components of an APP interacting with a CMS 100, in accordance with implementations of the disclosure.
  • FIG. 5 conceptually illustrates communications in a system in which an app of a CMS triggers an action by another app, in accordance with implementations of the disclosure.
  • Figure 6 conceptually illustrates installation and configuration of apps to enable app actions to be invoked between apps in a content project, in accordance with implementations of the disclosure.
  • FIG. 7 conceptually illustrates triggering of an app action by another app in a content project, in accordance with implementations of the disclosure.
  • Figure 8 illustrates a method for enabling actions to be triggered between apps installed in a content project of a CMS, in accordance with implementations of the disclosure.
  • Figure 9A illustrates an example of an interface for an app in a CMS, in accordance with implementations of the disclosure.
  • Figure 9B illustrates the interface for an app in a CMS, in accordance with the implementation of Figure 9A.
  • Figure 9C illustrates the interface for an app in a CMS, in accordance with the implementation of Figure 9B.
  • Figure 9D illustrates the interface for an app in a CMS, in accordance with the implementation of Figure 9C.
  • FIG. 10 illustrates an example of how a content management API (CMA) and a content preview API (CPA) can make calls to a content management system (CMS), in accordance with implementations of the disclosure.
  • CMA content management API
  • CPS content management system
  • implementations of the present disclosure provide systems and methods to enable apps to trigger each other’s functionality.
  • Mechanisms are provided that define how apps can invoke actions by other apps, and what protocols are defined to enable this while maintaining security of the CMS and the apps. This enables inter-app action triggering in a structured manner that is not open to potential exploitation or otherwise insecure.
  • apps do not communicate directly with each other, but rather the CMS acts as a proxy between apps. Triggering of actions between apps can be required to be explicitly allowed by the user. Further, the CMS ensures adherence to policies so that only allowed communications trigger invocations of actions by another app.
  • the provider of an app provides a schema defining parameters of an acceptable communication, and the consuming app that wishes to call this action communicates to the CMS.
  • the CMS validates the communication from the consuming app, and then asynchronously generates the appropriate call to the providing app.
  • the asynchronous setup is a “fire-and-forgef ’ setup so that inter-app invocations do not pose a security problem. If the CMS were to wait for the providing app to complete the requested action, then the CMS would be dependent on third parties. Thus, in some implementations, the consuming app receives an acknowledgement of its request from the CMS, but not necessarily any further confirmation of a specific result from the providing app whose action is being triggered. The CMS does not wait for the providing app to complete the action or otherwise respond.
  • a set of endpoints is provided allowing actors in the extended CMS platform to securely trigger actions exposed by apps installed in a given content project.
  • app backends are enabled to communicate with each other. This enables encapsulation and reusability of common pieces of logic, giving the app framework more flexibility and robustness.
  • FIG. 1 conceptually illustrates a content management system (CMS) 100, and entities that interact with the CMS 100, in accordance with implementations of the disclosure.
  • CMS content management system
  • CMS content management system
  • Contentful GmbH https://www.contentful.com
  • content can be distinguished from the context/channel in which such content is presented. That is, content is modularized and separated from its appearance in a given presentation context through which the content is presented and actually consumed by the end user. Examples of presentation contexts include websites, mobile apps, digital signage, in-store digital experiences, etc.
  • Content generally consists of content items which can be of various types. Examples of types of content items include text, images, audio, video, data values, etc. Content items are typically stored as data structures in the CMS (e.g. JSON data structures containing text, metadata, links, tags, etc.), and in some implementations, include raw text, media, or data files. Hence, content is stored and delivered in a generic format, and formatting is later applied in the end application that defines the presentation context. For example, appearance determinations such as fonts, colors, alignment, etc. are applied to text or media content items by a website or mobile app. Thus, the final appearance of content is not determined at its creation, but rather is dynamically determined by the context in which the content will appear.
  • CMS e.g. JSON data structures containing text, metadata, links, tags, etc.
  • Content items can be flexibly configured to enable specific content items for specific purposes to be defined.
  • the content items which comprise a typical rendering of a news article by a newspaper/publication may include the following: title of the newspaper/publication, place/location, date, copyright information, article title, subtitle, author, body, photo/image, photographer name, photo/image caption, etc.
  • Each of these content items can be separately stored and independently delivered as needed to suit different contexts of presentation. For example, a news article appearing on a news website will be configured to present the article in a different format/ style than when the same article appears in a social media feed, on a digital sign, or in another context.
  • the CMS 100 provides a content platform 102 to unify and structure content for improved content management and delivery. Access to and management of the content is provided through various application programming interfaces (API’s).
  • API application programming interfaces
  • creation, editing, federation and other management of content is mediated through a content management API 104.
  • the content management API 104 is a read-write API for managing content.
  • the content management API 104 requires authentication as a user of the CMS.
  • the content management API 104 enables one to programmatically create or update content items.
  • the content management API 104 can be used for a variety of purposes, including by way of example without limitation, creation and editing of content in the content platform, automatic imports from other content sources/repositories, integration with other backend systems (e.g. an e-commerce shop), building custom editing experiences, etc.
  • a web editor 112 is implemented to provide a web-based user interface for creating and editing content, the web editor accessing the content management API to generate new content items in the system, retrieve and edit existing content items, store changes to content items, etc.
  • content is localized in part by translation logic 114, which enables translation (in some implementations, causes translations) of the content into the local language of the delivery context.
  • translation logic 114 may access the content management API 104 to retrieve, generate, and store translations of content in the CMS 100, as well as configure such translations for presentation in the appropriate contexts.
  • the content platform 102 of the CMS 100 can be integrated with other systems via the content management API 104.
  • content can be sourced/mined/imported from, or synchronized with, an existing repository of content.
  • an existing product catalog 116 may be maintained including information about products such as product names, categorizations, descriptions, price information, related media, etc. and such a product catalog system can be configured to import or update content, or otherwise effect content management actions so as to integrate with the CMS 100 via the content management API 104.
  • a cloud storage system 118 can similarly integrate with the CMS 100 via the content management API 104.
  • a personalization system 120 is enabled to effect content personalization via the content management API 104.
  • Personalization information can be utilized to enable customization of content or downstream customization of content delivery. Examples of personalization information can include user demographic information (e.g. age, gender, ethnicity, etc.), geolocation, user content consumption history, user preference information, user purchase history, etc. Such personalization information can be utilized by the personalization system 120 to customize content via the content management API, and the selection and presentation of content through a given context.
  • content is separated from its presentation, so that the specific appearance of delivered content is determined by or otherwise based on the downstream context/channel through which the content is delivered (e.g. website, mobile app, digital signage, in-store experience, etc.).
  • various API’s are provided for enabling such presentation contexts/channels to access the CMS to obtain the appropriate content for presentation.
  • a content delivery API 106 is exposed to enable retrieval of content items and delivery of said content items to the presentation context.
  • the content delivery API 106 is configured as a read-only API for delivering content from the CMS 100 to apps, websites and other media.
  • content can be delivered as JSON data, and images, videos and other media as files.
  • the content delivery API 106 can be made available via a globally distributed content delivery network (CDN), so that the server closest to the user serves all content, both JSON and binary. This minimizes latency, which especially benefits potentially bandwidth-constrained delivery contexts, such as mobile apps. Hosting content in multiple global data centers also greatly improves the availability of content.
  • CDN globally distributed content delivery network
  • a content preview API 108 is provided, which is a variant of the content delivery API 106 for previewing content before delivering it to live customers.
  • the content preview API 108 can be used in combination with a preview deployment, e.g. preview deployment of a website or a preview build of a mobile app, that allows content managers and authors to view their work in-context, as if it were published, using a preview access token as though it were delivered by the content delivery API 106.
  • an images API 110 is provided, enabling image transformations/adjustments, such as resizing and cropping of images, changing their background color and converting them to different formats.
  • image transformations/adjustments such as resizing and cropping of images, changing their background color and converting them to different formats.
  • Using the images API 110 for these transformations allows users to upload high-quality assets, while delivering images suitable and optimized for the delivery channel, and leveraging the benefits of a caching content delivery network.
  • content can be delivered from the CMS 100 to any of various delivery channel s/contexts, such as a website 122, mobile app 124, digital signage 126, in-store experience 128, Internet-of-things (IOT) device 130, etc.
  • delivery channel s/contexts such as a website 122, mobile app 124, digital signage 126, in-store experience 128, Internet-of-things (IOT) device 130, etc.
  • the CMS 100 is configured to have the following main entity types: user, organization, space, and environment.
  • a user is an entity with an account in the CMS. Users can be invited to an existing organization, or sign up individually. If a user has signed up individually, a new organization is automatically created. An existing user can create additional organizations or be invited to other existing organizations. In some implementations, users have management authentication credentials attached to them, such as OAuth applications, OAuth tokens, and personal access tokens.
  • An organization is an entity that serves as a way to group users and group spaces (content projects).
  • the organization also links member users to a billing entity, so subscriptions and invoices are tied to the organization, rather than to a specific user.
  • the CMS implements a role-based access model. For example, users can be invited to join an organization and those users will have different levels of access based on their organizational role.
  • a space or a content project is a child of the organization, and serves as a container for the organization’s content and any settings related to that content. Spaces allow one to separate data according to the structure of projects or services.
  • API keys can be defined, so that in order to retrieve content through one of the CMS’s APIs, a key has to be provided for authentication.
  • an API key is required to be provided in order to access published content through the content delivery API or to access unpublished content through the preview API.
  • Webhooks can be configured to send requests (e.g. HTTP requests) triggered by changes to a content model, content, or media.
  • Content preview functionality is supported, providing a link within the entry editor to a pre-production environment that uses the preview API to access unpublished content.
  • environments are defined as entities within a space that allow one to create and maintain multiple versions of the space-specific data and configuration, and make changes to them in isolation.
  • each space has one environment by default, which may be termed a master environment.
  • multiple sandbox environments can be created. These sandbox environments allow one to modify the data in a space without affecting the data in the master environment.
  • an environment alias can be implemented to allow one to access and modify the data of a target environment, through a different static identifier.
  • a master alias ID can be implemented to reference or point to the environment that is deemed to be the current production version, and accordingly API calls using the master alias ID will access the referenced environment. It will be appreciated that the master alias ID can be easily switched to another environment as needed, conveniently facilitating rollout of a new version of content or rollback to a prior version.
  • environments include a content model, content, and media.
  • the content model is a collection of content types, which define the structure of the content.
  • the content is defined as a collection of entries.
  • Media is defined as a collection of assets.
  • a plurality of settings can apply to environments. For example, in some implementations, there are locales settings to manage and deliver content in multiple languages, or otherwise customize content delivery based on delivery geo-location. In some implementations, user interface (UI) extensions are supported, to enable building of customized editing experiences for the web editor. In some implementations, app installations are supported, extending and expanding the capabilities of the CMS web application.
  • UI user interface
  • FIG. 2 conceptually illustrates a content project (also termed a space), in accordance with implementations of the disclosure.
  • content is organized in content projects, such as an exemplary content project 200, that groups together all the related resources for a given project. This can include content entries, media assets, and settings for localizing content into different languages.
  • Each content project has a content model that represents and defines the content types one can create for the content project.
  • all content types have standard fields that contain basic information about the content type, its fields and meta data (e.g. system properties, name of the content type, description of the content type, listing of fields, ID of main field used for display, etc.).
  • Each content type is flexibly configurable, further consisting of user-defined fields, which in some implementations, correspond to a JSON type (e.g. string, number, object, boolean, array). Examples of user-defined fields include the following: text, number, date and time, location (coordinates), boolean, media (links to an asset), reference (links to an entry or object), array, JSON object.
  • array fields can contain multiple values which can include strings, links to other entries or assets, etc.
  • An array field may have an items property defining the allowed values in the array.
  • Individual fields can also contain metadata, such as validations and widget appearance.
  • entries e.g. entry 204
  • Items can also be assets (e.g. asset 210), which can include binary files (e.g. binary file 212), such as images, videos or documents, along with metadata.
  • assets have the following fields: the name, description and attached file.
  • a content project contains all the content that is functional to one project, and an environment is a way to express one version of one project.
  • An example use case for multiple environments as part of a given content project would be a scenario in which there is a current version of one’s website and a future holiday version of the website that is not in production yet, but being worked on.
  • content in a given environment of a content project consists of entries and assets, with each entry being of a user-defined type that specifies the fields of a given entry.
  • each entry is a unit of content in the system of a type that is flexibly defined by the user and capable of being adapted to suit a given purpose.
  • an example of a content model for a product catalogue might include content types for a category (identifying what product type), a brand (identifying who made the product), and a product (an item for sale that references a category and a brand).
  • the brand content type might consist of several fields, such as a company name, logo, description, electronic contact information (website, social media, email address), phone number, etc.
  • Entries can have link (or reference) fields which point to other entries or assets.
  • An example use case for a restaurant might include the following: a restaurant linking to its menu (singular relationship), a menu linking to its specific menu items (plural relationship), each menu item linking to a photo (attachment), a restaurant linking to multiple photos (attachments).
  • the content delivery API can be structured so that a single HTTP request retrieves the entire set of linked resources above, starting with the menu, in one request.
  • a CDN can cache these requests to further speed up future requests. This is useful for consuming apps (and especially mobile apps) as it reduces the need for multiple concurrent connections or servicing of serially dependent requests, and reduces the latency for results to return.
  • Links also provide additional advantages in that relationships are clearly defined and validated by specific content type fields. Entry links can be validated by content type (e.g. only allow Menu Items for fields. menuitems). Asset links can be validated by file type. (e.g. only allow Images for fields. photo). Links on the Content Delivery API are resolved using the published entries and assets, while links on the Content Preview API will resolve using the draft entries and assets.
  • Figure 3 A conceptually illustrates a system for providing app functionality to extend the content management capabilities of a content management system, in accordance with implementations of the disclosure.
  • an app is a program or extension that extends the content management functionality of the CMS.
  • APPs can provide non-native functionality enabling users to customize their editorial experience and management capabilities in the CMS.
  • APPs can provide a way to enable external systems to participate in the process of writing or defining the structure of the content, which can include functions such as adding content itself, adding meta information like SEO, tagging, optimization, translation of text, etc. and such can be contributed in the CMS through applications for the work tailored to a specific user of the CMS.
  • the CMS may have a stock content management application, such as web editor 112, and an application framework is provided to enable integration of APPs with the stock application.
  • the CMS provides content management tools, and provides an API that will be used to build the content delivery channel, such as a webpage.
  • the CMS may not host or create the page, but provide the API target for queries to the CMS requesting the content for the page, such as for downloading the text, media files, the structure for the page, etc.
  • the CMS may not host or create the page, but provide the API target for queries to the CMS requesting the content for the page, such as for downloading the text, media files, the structure for the page, etc.
  • the content retrieved will include the structure that was defined by the APP to manage the gallery, because the product of the APP’s usage is a structure in the CMS.
  • the application to build the page will obtain through this API call all the data structures that are needed for the page, and because the structure for the gallery has been described by the APP that was installed, this structure will also be downloaded.
  • the content for the webpage is authored in the CMS. But when a consumer user clicks on the webpage, there will be an application hosted in the website that is not the CMS, but this application for fetching the content will request content from the CMS. So the CMS acts like a database providing data for a website, but instead of a database, the CMS provides a much higher level API to deal with content for one’s webpage or other delivery channel.
  • APPs are installed or enabled for a given content project/space 300, or installed/enabled for an environment as a version of the content project. It will be appreciated that a given environment at any given moment in time has some version of content, and if an APP is installed in this environment, then it acts on this content.
  • a private APP can be built by a developer for a specific organization's needs to optimize the organization's editorial experience. Such a private APP is fully under control of the developer/organization and not accessible by other organizations. APPs are created within one’s organization and installed into one or more environments, each with the ability to be individually configured.
  • marketplace APPs there can be a marketplace 316 for APPs, with marketplace APPs being pre-built to connect the CMS with other systems, allowing CMS users to assemble the editorial stack of their choice.
  • Marketplace APPs can be free to install or paid.
  • APPs can be installed for the content project 300. More specifically, in some implementations, APPs are installed for, and configured to act upon, an environment 302 containing items for a version of the content project 300.
  • an APP can include a front-end component (or widget) and/or a back-end component.
  • the front-end component of an APP (or an APP declaring a front-end component and no back-end component) is referred to as a front-end APP
  • the back-end component of an APP (or an APP declaring a back-end component and no front-end component) is referred to as a back-end APP.
  • An APP declaring a front-end or widget 308, provides a visual component that is added to an editorial application 308 of the CMS (e.g. web editor 112).
  • the front-end component uses a front-end SDK that implements a custom transport between custom code running in the browser and the APIs 312 of the CMS.
  • Such front-end APPs can provide a visual addition/representation to the editorial interface, and act as editorial APPs, which can be accessed, operated, or viewed by editors 310 that utilize the editorial interface to manually edit the content of the content project 300.
  • APPs can also have a back-end component, which can be configured to run on its own by the vendor producing the APP.
  • back-end APPs 304 and 306 are installed for the content project 300, and more specifically for the environment 302.
  • back-end APPs can use a back-end SDK.
  • back-end APPs can also call APIs directly.
  • back-end APPs are hosted by 3rd party machines 314, and may make scripted API calls to the CMS.
  • front-end SDK In the case of front-end widgets, the use of the front-end SDK is required, because the web application editorial experiences are proprietary to the CMS. Thus, for allowance of the front-end to generate a rendering (e.g. table, window, dialogue, selector, etc.) inside of these CMS editorial applications, adherence to the transport is required.
  • the front-end SDK provides the implementation of the transport that makes it simpler and more secure to insert these widgets or visual injections into editorial applications of the CMS. Widgets are intended to be consumed by a user - e.g. click button, select/instruct something, etc.
  • Back-end APPs 304 and 306 can function as embedded actors acting on their own inside of the content project.
  • a back-end SDK can provide convenience features for APPs acting on their own, without supervision.
  • back-end APPs may act on their own, such as by reacting to some changes in the same or different systems, performing activities on a schedule, etc.
  • APPs are further defined as agents having identities in the system, and are thus content actors enabling integration of services and custom logic, such as artificial intelligence (Al), task automation, cloud services, migration, intranet integration, etc.
  • FIG. 3B conceptually illustrates an application framework for installation of APPs to interact with a CMS, in accordance with implementations of the disclosure.
  • the CMS 100 stores content projects 200 and enables management of these content projects via a content management API 104.
  • the web editor 112 is provided by the CMS 100, which accesses the content management API 104 to provide editorial capabilities to a user.
  • an APP framework 320 is provided, through which APPs 322 and 324 are enabled to interact with the CMS 100, including interacting with the web editor 112 and the content management API 104.
  • Figure 4 conceptually illustrates front-end and back-end components of an APP interacting with a CMS 100, in accordance with implementations of the disclosure.
  • the CMS includes a content project 404, which contains an environment 406 having content entries such as entry 408.
  • the CMS includes web editor code 410 that is deployed for execution in a client browser 418, that itself executes on a remote client device.
  • the execution of the web editor code in the browser 418 instantiates the web editor 420.
  • the web editor 420 presents a web editor user interface (UI) 422 to the user.
  • UI web editor user interface
  • the user is able to create, access, and edit content of the content project 404 using the web editor 420.
  • the web editor 420 makes API calls to the content management API 104 to effect editorial changes in the content project 404, such as to entry 408.
  • An APP 416 is hosted by an APPs host 414.
  • the APPs host 414 is part of the CMS 100. Whereas in other implementations the APPs host 414 is a 3rd party hosting location for one or more APPs.
  • the APP 416 is configured to extend the functionality of the web editor 420.
  • the APP 416 includes a front-end component 428 that is deployed to execute within an APP runtime environment 424.
  • the APP runtime environment 424 is instantiated by the web editor 420 and provides a controlled environment in which to deploy and run the front-end component 428.
  • a front-end SDK 426 is loaded with the front-end component 428, providing a custom transport to enable the front-end component 428 to access the content management API 104 to effect editorial changes to the content of the content project 404, such as editing entry 408.
  • the front-end component 428 may further communicate with (e.g. via HTTP calls) a 3rd party service 436, thereby enabling integration of functionality provided by the 3rd party service 436.
  • the 3rd party service 436 is a service included in the CMS 100.
  • the front-end SDK enables loose coupling of front-end APPs to the CMS editorial application, in this case the web editor 420.
  • the front-end component 428 can access all of the data structures that are maintained and stored in the environment 406.
  • the set of durable content and settings and media, grouped in the environment 406, is the target for the installation of APPs.
  • APPs built with the SDK can access all of the documents, media, and relevant entities within the environment. For example, an APP might react to some changes in content and perform further changes using the SDK. It will be appreciated that a developer can write an APP once, then make it available for installation across other environments or content projects.
  • the front-end SDK provides the mechanism to isolate the CMS editorial application, so that its code does not need to meld with another code base of an extension at runtime. Rather, the front-end SDK provides a means of encapsulation, protecting the CMS web editor from other small systems being embedded inside. It acts as a transport mechanism between the custom code and the platform on which the code runs.
  • a great variety of custom logic integration possibilities can be enabled (e.g. Al, migration, cloud connectors, etc.).
  • One can use any custom logic or connection and using the SDK can communicate with the content container which is the environment of the content project.
  • the installation configuration is such that an APP is packaged but is not a part of the CMS offering space. Rather, an APP is simply a package that is ready to be installed. And with a single API call, code is made available in a content project/environment, so that the process is completely automatic and APPs are very loosely coupled to the CMS. Non-native APPs can operate, but cannot influence the system too much and cannot break the system. And if one decides that they do not wish to use a particular APP, they can simply uninstall it.
  • the front-end SDK helps to achieve a loose coupling of front-end components of APPs to the CMS editorial application.
  • allowing for the installation of custom front end widgets in the web editor 420 running in the browser 418 environment can expose the web editor 420 to potentially harmful or malicious actions.
  • the front-end component 428 is run in a separate APP runtime environment 424, which creates a boundary between the front-end component 428 and the web editor 420.
  • the front-end SDK 426 thus provides a transport mechanism that can cross this boundary.
  • the front-end SDK 426 can be used to communicate between APP code which may not be fully trusted, and the CMS editorial application platform on which the APP code will run.
  • the front-end SDK 426 can also provide convenience methods for performing relevant API calls to perform content management activities.
  • the front-end SDK 426 can include convenience methods for visual actions or how to present information to users (e.g. opening a dialogue window from an editorial widget, etc.).
  • the front-end SDK 426 provides the custom transport by which the front-end component 428 communicates with the CMS 100.
  • the front-end SDK 426 also governs interaction of the front-end component 428 with the web editor 420, and any other installed APPs.
  • a second front-end component 434 of another APP is also deployed to run in its own APP runtime environment 430, also loaded with the front-end SDK 432.
  • the front-end component 428 accesses the front-end SDK 426 in order to communicate with the front-end component 434, and thus interactions between front-end components of APPs loaded in the web editor 420 are subject to control via the controlled APP runtime environments and the front-end SDK.
  • Front-end APPs can provide a customized user interface with controls or dashboards within the web editor UI 422.
  • APPs can also be configured to have back-end componentry that may perform asynchronous work on a server without any user interaction.
  • the APP 416 further includes a back-end component 440 that is run on a back-end server 438, which can be a 3rd party server or a server that is part of the CMS 100. In the case of 3rd party server execution, such back-end APPs can be fully under control by the 3rd part.
  • back-end APPs can interact with the content management API 104 with their own identity.
  • Back-end APPs can individually subscribe to events within their installed environment, in a manner similar to webhooks.
  • an advantage of backend APPs compared to using regular webhooks and content management API tokens is that APP identities are not user bound and therefore not restricted to a specific user account's permissions.
  • the frontend and backend configuration is provided as a bundle and can be automatically installed into an environment with a single click without manual setup of webhooks filters or updating backend code for new environments.
  • a back-end SDK 442 is provided, which can be utilized by the back-end component 440 to simplify calls to the content management API 104.
  • the back-end component 440 may also communicate with the 3rd party service 436.
  • a webpage 400 is configured to obtain content from the CMS 100.
  • the webpage 400 includes a content section 402 in which the entry 408 is presented, the entry 408 being obtained by accessing the content delivery API 106.
  • the changes to content entries, facilitated by APPs including front-end and back-end components, are reflected in content that is retrieved and eventually presented through a delivery channel such as the webpage 400.
  • FIG. 5 conceptually illustrates communications in a system in which an app of a CMS triggers an action by another app, in accordance with implementations of the disclosure.
  • a “consumer” app 502 is an app configured to trigger behaviors of another app, which is the “provider” app 504.
  • the provider app 504 exposes actions that other apps can trigger.
  • the consumer app 502 issues an invoke request 506 to the CMS, requesting to trigger an action that is exposed by the provider app 504.
  • the CMS 100 proceeds to authenticate/authorize the request (reference 508), ensuring that the consumer app 502 is authorized to make such a request.
  • the invoke request 506 is also validated (reference 510) by the CMS 100 to ensure that the contents of the invoke request 506 adhere to any requirements defined by the provider app 504 for making a valid request of an available action.
  • a successful acknowledge 512 is sent to the consumer app 502 indicating as such.
  • an asynchronous call 514 is generated from the CMS 100 to the provider app 504.
  • the asynchronous call 514 is generated to a predefined location endpoint as defined by the provider app 504.
  • the asynchronous call 514 is performed in a fire-and-forget manner such that the CMS 100 does not wait for an acknowledgement or response to the call. This provides a security benefit so that if there is a problem with the provider app 504 or its host system, then the CMS 100 will not be affected.
  • the provider app 504 may send a response 516 to the CMS, which may be logged by the CMS 518.
  • the response 516 may indicate successful receipt of the asynchronous call 514.
  • the consumer app 502 may retrieve or access the logged information to obtain the status of its request.
  • the result of the asynchronous call 514 is for the provider app 504 to perform some action which it has made available for triggering by the consumer app 502.
  • the action is performed by the provider app without feedback to the CMS.
  • the provider app 504 may perform an action resulting in, or including, a response 522 that is returned to the CMS, which may also be made available to the consumer app 502 via the CMS.
  • FIG. 6 conceptually illustrates installation and configuration of apps to enable app actions to be invoked between apps in a content project, in accordance with implementations of the disclosure.
  • an app store 600 is provided, from which apps can be selected for installation into a content project in order to extend the editing functionality provided for the content project.
  • the app store 600 includes representative apps 602, 604 and 606.
  • a user 618 accessing the CMS 100 using a client 620 is able to select apps 602 and 604 in the illustrated implementation, and install apps 602 and 604 into their space environment 622, which may define a version of their content project in the CMS 100.
  • An app provider (e.g. a developer of an app) that provides an app made available through the app store 600, may define actions of the app which are exposed for calling from other apps.
  • the app 606 is provided to the app store 600 by the app provider 616.
  • the app 606 further has an action definition 610, which defines an action of the app 606 that is available for calling by other apps as well as the requirements for calling the action.
  • a location 612 defines where a call should be placed in order to initiate the exposed action of the app.
  • the location may be defined by an address/endpoint such as a URL of an HTTP address/endpoint.
  • a parameters schema 614 defines what parameters are required or can be provided, and how (e.g syntax), when calling the action.
  • the parameters schema may provide a listing of allowed headers in the request for the action.
  • the action definition 610 includes a categorization/type, which can be configured to enable standardization of parameter requirements for the given app action being defined. That is, various categories can be predefined for use in the actions definition, with each category have a predefined parameters schema associated thereto. Thus, assignment of a particular category to an app action definition standardizes the parameters schema for that app action, in accordance with the predefined parameters schema that is associated to the assigned category.
  • installation of the app 602 into the space environment 622 defines an app installation 624 which identifies the app 602 as being enabled for use in the space environment 622.
  • installation of the app 604 into the space environment 622 defines an app installation 626 which identifies the app 604 as being enabled for use in the space environment 622.
  • the user 618 may configure the apps for triggering actions between each other, defining permissions regarding which app may trigger which action of another app.
  • a set of app actions permissions 628 are defined and configured for the space environment 622.
  • the app actions permissions 628 are configurable to set which of the app 604’ s available actions are permitted to be triggered by the app 602, and which of the app 602’ s available actions are permitted to be triggered by the app 604.
  • App actions can be configured to be not permitted by default. That is, when an app is installed, then it is only enabled to trigger an available action of another installed app if the user explicitly sets the permission to allow the app to trigger the action. Furthermore, it is noted that an installed app may only trigger actions of another installed app in the same content project, such as in the same space environment 622 in the illustrated implementation. Thus, within the context of the space environment 622 in the illustrated implementation, the app 602 can be configured to trigger an available action of the app 604, but not of the app 606 because the app 606 is not installed in the same space environment 622. Thus, the scope of triggering of app actions can be automatically limited to the same space environment.
  • Figure 7 conceptually illustrates triggering of an app action by another app in a content project, in accordance with implementations of the disclosure.
  • the functional application logic of the installed app may be remotely hosted by a 3rd party in some implementations, or may be hosted by the CMS in other implementations.
  • the app logic 702 can be the functional application logic of the app 602 described above with reference to Figure 6.
  • the app logic 702 as shown is hosted by an app host 700, which in some implementations may be a 3rd party host or a hosting system that is part of the CMS.
  • the app logic 722, hosted by an app host 720 can be the functional application logic of the app 604 described above.
  • triggering of an app action is conceptually shown. More specifically, the (provider) app 604 exposes an action callable to be performed by its corresponding (provider) app logic 722, and the (consumer) app 602 triggers this action via its corresponding (consumer) app logic 702.
  • the app logic 702 generates an invocation request 704, which in some implementations, is a call to an invocation endpoint 706 of an API of the CMS 100, such as the CMA 104.
  • the invocation request is authenticated, checked for authorization, and validated.
  • authentication logic 708 of the CMS authenticates the app logic 702 on the CMS. This can entail authenticating the consumer app logic 702 and its invocation request 704 based on a cryptographic authentication method, such as a token authentication method or shared secret based authentication method.
  • Authorization logic 709 checks the app actions permissions 628 for the space environment 622 to determine whether the app 602 is authorized to request the particular app action being requested. It will be appreciated that this authorization is user-defined for the particular space environment 622, so that even if the app 602 successfully authenticates to the CMS, the app 602 still cannot invoke an action by another app unless specifically authorized to do so in the context of the space environment 622. If the authentication or the authorization fails, then an error message can be surfaced to the user indicating the reason for the failure.
  • validation logic 710 of the CMS determines whether the parameters of the invocation request adhere to the requirements of the provider app for triggering the action. That is, the validation logic 710 checks parameters of the invocation request against the parameters schema defined for the app 604 in its actions definition as described above, and determines whether such parameters are consistent with the requirements therein defined. In some implementations, the validation process includes validating body and headers. If validation fails, then an error message can be surfaced to the user indicating the reason for the failure. It will be appreciated that by validating at the CMS level, early feedback can be provided to the consumer app when the request cannot be processed due to client-side errors, and this also frees the downstream provider app from having to deal with non-conforming requests for its actions.
  • asynchronous call generator 712 Upon successful authentication/authorization and validation of the invocation request 704, then asynchronous call generator 712 generates an asynchronous call 714 to a location endpoint 724 of the (provider) app logic 722, as specified by the app’s action definition.
  • the asynchronous call 714 includes parameters 716, which can include the CMS- related context of the call, such as the space, environment, and identity of the consumer app making the call, as well as other parameters relevant or required for the requested action.
  • the asynchronous call 714 is digitally signed with a digital signature 718 for security. Because requests are digitally signed by the CMS, the (provider) app logic 722 can verify the legitimacy of an incoming request.
  • the asynchronous call generator 712 operates a queue in which authenticated/authorized and validated invocation requests are queued for handling. And upon retrieval of a request from the queue, then the asynchronous call generator 712 generates the appropriate digitally signed call for the requested app action.
  • a response from the (provider) app logic 722 can be provided to the CMS, which can be logged by logging logic 732.
  • logging logic 732 To access the log of such responses, for example to ascertain the status of a prior request, a logging endpoint 730 of the CMA can be accessed, which may access the logging logic 732 to retrieve the relevant results.
  • the asynchronous call is made in a fire-and- forget manner, wherein the CMS does not wait for a response to the call from the provider app logic 722.
  • the CMS does not wait for a response to the call from the provider app logic 722.
  • the CMS is not affected.
  • the asynchronous nature of the app actions system thus provides for independence of the apps from one another, shielding them from potential harmful effects.
  • the validation of the initial request from the consumer app is performed by the CMS, and as the CMS is verifying the appropriateness of the request and then generating the call, the provider app should not be receiving any non-conforming or invalid calls.
  • Figure 8 illustrates a method for enabling actions to be triggered between apps installed in a content project of a CMS, in accordance with implementations of the disclosure.
  • a plurality of apps are installed in a content project, such as a content space, or more specifically a particular environment of a content space.
  • Installation of the apps enables the functionality of the apps to be used to extend the editing capabilities of an editing application when used to edit the content of the content project.
  • the plurality of apps include at least a first (provider) app that exposes an action that is available to be called, and a second (consumer) app which can be configured to call the exposed action.
  • app action permissions are configured, which define which apps can call which actions exposed by other apps. For a given app, available actions of other installed apps in the same content project can be presented through a user interface, and the user can thereby configure which actions to allow the app to invoke. In the present case, the app action permissions of the second app are configured to allow the second app to invoke the action exposed by the first app.
  • an invocation request is received from the second app at the CMS.
  • the invocation request from the second app is configured to request to invoke the action of the first app, and as such, the invocation request may include relevant parameters for invoking the action.
  • the CMS authenticates/authorizes the request, determining whether the second app is authorized to request the action of the first app. If not, then at method operation 808 an authentication/authorization error is returned and the method ends 820.
  • the CMS validates the request, determining whether parameters included in the request adhere to the requirements for the action sought to be invoked by the invocation request. If the validation fails, then at method operation 812 a validation error message is returned and the method ends 820.
  • an acknowledgement message is returned, indicating that the request was successfully validated or processed by the CMS.
  • the CMS generates an asynchronous call to the first app to activate the action exposed by the first app.
  • the asynchronous call is performed in fire-and-forget manner, so that the CMS does not wait for a response to the call, and the CMS is not affected if the first app encounters any issues or is unresponsive.
  • the CMS may receive and log a response received from the first app.
  • the CMS may expose the logged response to be retrieved/read by the first app.
  • an endpoint that they register and expose as an available app action will receive signed requests from the CMS. Because the requests from the CMS are signed and identifiable, other requests that may be received at the endpoint can be discarded, or separately handled as desired by the action provider. Further, to issue an app action, a request to an API of the CMS (e.g. CMA) needs to be performed, and such requests are subject to rate limiting implemented by the CMS. Accordingly, actors interfacing with the CMS cannot perform denial-of-service attacks on endpoints exposed as app actions. Also, because actors interfacing with the CMS are authenticated, unauthenticated actors cannot issue app actions.
  • an API of the CMS e.g. CMA
  • a shared secret based authentication scheme is employed by the CMS, and thus, 3rd party actors need only share secrets with the CMS, and there is no sharing of secrets between 3rd parties directly.
  • security is enhanced as the action provider can expose an action for calling by a consumer app, without needing to share a signing secret with the consumer app.
  • Figure 9A illustrates an example of an interface for an app in a CMS, in accordance with implementations of the disclosure.
  • an interface 900 for the “Workflows” app on the Contentful(R) CMS platform is shown.
  • the interface 900 is accessed from a web editor of the CMS, and extends the editing functionality of the system. More specifically, in the window 902 of the interface 900, interface elements are shown for editing a workflow state named “In Progress.” For example, in the field 904, the name of the workflow state is editable. In the field 906, a description of the workflow state is editable.
  • a button 908 is configured to enable addition of a rule or configuration for the workflow state.
  • a button 910 is configured to enable addition of an action to the workflow state. That is, when the workflow state is set for a particular content entry, then the defined action will be triggered.
  • Figure 9B illustrates the interface for an app in a CMS, in accordance with the implementation of Figure 9A.
  • selection of the button 910 reveals selectable options to add specific actions to be triggered by assignment of the workflow state (the “In Progress” workflow state as shown at Figure 9A).
  • a selectable option 912 enables sending a message via a “Slack” app
  • a selectable option 914 enables creating a task on a “Task” app.
  • Figure 9C illustrates the interface for an app in a CMS, in accordance with the implementation of Figure 9B.
  • a pop-up window 920 is provided in response to selection of the selectable option 914 shown at Figure 9B.
  • the pop-up window 920 enables editing of an action to be performed by the “Task” app, namely creation of a task item.
  • a field 922 is provided for editing the description of the task.
  • a field 924 enables selection of a user for assignment of the task.
  • a due date selector 926 enables selection of a due date time interval.
  • a button 928 enables addition of the “Task” app action to the workflow state, whereas a button 930 enables canceling the activity so that no action is added.
  • Figure 9D illustrates the interface for an app in a CMS, in accordance with the implementation of Figure 9C.
  • an action 940 to be performed by the “Task” app is now shown in the window 902 at Figure 9D.
  • the illustrated action 940 will be triggered and performed when the “In Progress” workflow state is set for a given content entry.
  • the “Workflows” app is configured to trigger an action by the “Task” app.
  • the selectable option 912 enables sending a message on Slack.
  • Selection of the selectable option 912 may thus cause opening of an interface to enable setting parameters of a message to be triggered through a “Slack” app, such as the recipient channel, message contents, etc.
  • the “Workflows” app can be configured to trigger an action by the “Slack” app.
  • Automations can be implemented by configuring one app to automatically trigger an action of another app upon the occurrence of some predefined condition. This can be useful for editors of content in a CMS to more seamlessly integrate different functions in relation to a given piece of content.
  • users can manually trigger actions exposed by apps.
  • a user may be provided with an interface enabling manual triggering of an action exposed by another app.
  • the content management system (CMS) of the described embodiments is a headless CMS.
  • a headless CMS functions as a “content” repository, where the content is separated or decoupled from the presentation layer head. Because of this decoupling, the content is not page-based.
  • aspects of the headless CMS described herein provide for editors that allow for efficient structuring of content. The structuring of content enables for efficient management of said content and access to said content using specialized application specific interface (API) calls.
  • API application specific interface
  • the content infrastructure includes APIs for content management (e.g., content management API), previewing (e.g., content preview API), images (e.g., images API), and display (e.g., content delivery API), to deliver content to any application, platform, form factor, device, IOT, and website.
  • content management e.g., content management API
  • previewing e.g., content preview API
  • images e.g., images API
  • display e.g., content delivery API
  • the content delivery API is a read-only API for delivering content from the CMA to apps, websites and other media.
  • content is delivered as JSON data, and images, videos and other media as files.
  • the CDA is available via a globally distributed content delivery network.
  • the server closest to the user serves all content, both JSON and binary. Serving from the closest server minimizes latency, which especially benefits mobile apps.
  • content of the CMS is hosted in multiple global data centers, which greatly improves the availability of content.
  • the content management API (CMA) is a read-write API for managing content. Unlike the content delivery API, the content management API requires the user to be authenticated.
  • the CMA may be used in several use cases, such as automatic imports from WordPressTM, JoomlaTM, and other apps.
  • the CMA may be integrated with other backend systems, such as an e-commerce shop.
  • the content preview API is a variant of the CDA for previewing your content before delivering it for use by consuming applications (i.e., for display).
  • the content preview API may be used in combination with a "preview" deployment of a website (or a "preview” build of a mobile app) that allows content managers and authors to view their work in-context, as if it were published, using a "preview” access token as though it were delivered by the CDA.
  • the images API allows for resizing and cropping of images, changing image background colors and/or converting images to different formats. In one embodiment, using the images API for these transformations allows for upload of high-quality assets, delivering exactly what an app needs.
  • FIG 10 illustrates an example of how the content management API (CMA) and the content preview API (CPA) can make calls to the content management system (CMS) 1420.
  • the CMS 1420 includes compute and storage resources for management of structured content.
  • a web editor provides a user interface (UI) that remote client device uses to access the CMS 1420.
  • UI user interface
  • the CMA or CPA are used to make API calls to the management 1410 compute and storage resources.
  • the compute and storage resources which run the CMS 1420 are run in a cloud-based environment.
  • the cloud-based environment may be provided by a cloud compute and storage servicing entity, e.g., such as Amazon Web Services (AWS)TM, GoogleTM Cloud, MicrosoftTM AzureTM, or other serving entity.
  • AWS Amazon Web Services
  • these servicing entities are referred to as hosting services, which provide the hardware and internet connectivity to execute applications, processes, and workflows using various types of hardware configurations.
  • private cloud systems may be run instead of using third-party hosting services.
  • the hardware configurations may include virtualized hardware and expandable storage to meet the processing needs of the CMS 1420.
  • the CMS 1420 is executed using cloud infrastructure, which includes the use of multiple interconnected data centers throughout the world.
  • the CMS 1420 also includes a delivery component 1412, which is configured to service processing operations from the content delivery API and the images API.
  • the delivery component 1412 is provisioned with internal cache 1414, which is optimized to interface with a global content delivery network (CDN), which in turn handles calls from the content delivery API and the images API.
  • CDN global content delivery network
  • the CDN in one embodiment, is a widely distributed service that enables rapid and efficient delivery of content to users throughout the world.
  • the delivery component 1412 is part of the CMS 1420, and is also executed on compute and storage of a cloud infrastructure.
  • structured content is prepared and/or edited using the management component 1410, before it is published for external consumption. By separating structured content in the cloud infrastructure, it is possible to prevent non-ready content to be accessed and delivered using the CD A.
  • Agents accessing the CMS 1420 including organizations, individual users, as well as APPs, are authenticated by an authentication and authorization system.
  • user authentication uses MySQL.
  • APP authentication uses JSON Web Tokens.
  • One or more embodiments can also be fabricated as computer-readable code on a non-transitory computer-readable storage medium.
  • the non-transitory computer- readable storage medium is any non-transitory data storage device that can store data, which can thereafter be read by a computer system. Examples of the non-transitory computer-readable storage medium include solid state drives (SSDs), hard drives, network attached storage (NAS), read-only memory, random-access memory, persistent memory, CD-ROMs, CD-Rs, CD-RWs, magnetic tapes and other optical and non-optical data storage devices.
  • SSDs solid state drives
  • NAS network attached storage
  • read-only memory random-access memory
  • persistent memory CD-ROMs, CD-Rs, CD-RWs, magnetic tapes and other optical and non-optical data storage devices.
  • the non-transitory computer-readable storage medium can include computer-readable storage medium distributed over a network-coupled computer system so that the computer-readable code is stored and executed in a distributed fashion.

Abstract

La présente invention concerne un procédé mis en œuvre dans un système de gestion de contenu (CMS), pour fournir une intégration entre des APPLIS configurées pour être utilisées avec une application d'éditeur du CMS, comprenant : l'installation d'une première application et d'une seconde application dans un projet de contenu du CMS, l'installation des première et seconde applications permettant d'accéder aux fonctionnalités des première et seconde applications pour le projet de contenu par l'intermédiaire de l'application d'éditeur, l'application d'éditeur fournissant une interface pour modifier le projet de contenu ; la réception, en provenance de la première application, d'une demande d'appel d'une action par la seconde application ; en réponse à la réception de la demande, la validation alors du contenu de la demande ; en réponse à la validation réussie de la demande, l'envoi d'un accusé de réception à la première application et la génération d'un appel à la seconde application pour invoquer l'action par la seconde application.
PCT/IB2023/056468 2022-06-22 2023-06-22 Actions d'application dans un système de gestion de contenu WO2023248179A1 (fr)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US17/846,646 2022-06-22
US17/846,927 2022-06-22
US17/846,646 US11886620B2 (en) 2022-06-22 2022-06-22 APP actions in a content management system
US17/846,927 US11880722B2 (en) 2022-06-22 2022-06-22 App actions in a content management system
US17/846,965 US11809918B1 (en) 2022-06-22 2022-06-22 App actions in a content management system
US17/846,965 2022-06-22

Publications (1)

Publication Number Publication Date
WO2023248179A1 true WO2023248179A1 (fr) 2023-12-28

Family

ID=87378117

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2023/056468 WO2023248179A1 (fr) 2022-06-22 2023-06-22 Actions d'application dans un système de gestion de contenu

Country Status (1)

Country Link
WO (1) WO2023248179A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20180066915A (ko) * 2016-12-09 2018-06-20 주식회사 게임빈 웹기반 어플리케이션 개발을 위한 오픈 소셜 기반의 융합 서버 플랫폼
US20200007335A1 (en) * 2017-09-28 2020-01-02 Huawei Technologies Co., Ltd. Network Function Service Invocation Method, Apparatus, and System
US11175972B1 (en) * 2021-02-24 2021-11-16 Contentful GmbH Application framework for integrating APPs for editing content of a content management system
US20220083335A1 (en) * 2020-09-14 2022-03-17 Box, Inc. Workflow execution state variables

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20180066915A (ko) * 2016-12-09 2018-06-20 주식회사 게임빈 웹기반 어플리케이션 개발을 위한 오픈 소셜 기반의 융합 서버 플랫폼
US20200007335A1 (en) * 2017-09-28 2020-01-02 Huawei Technologies Co., Ltd. Network Function Service Invocation Method, Apparatus, and System
US20220083335A1 (en) * 2020-09-14 2022-03-17 Box, Inc. Workflow execution state variables
US11175972B1 (en) * 2021-02-24 2021-11-16 Contentful GmbH Application framework for integrating APPs for editing content of a content management system

Similar Documents

Publication Publication Date Title
US10708252B2 (en) Configuring credentials to faciltate sharing data in a secure manner
US11435984B1 (en) Content management system using an application framework for integrating apps for editing content
US11436300B1 (en) Systems for launching content for publication
US11799841B2 (en) Providing intercommunication within a system that uses disparate authentication technologies
US9176720B1 (en) Installation of third-party web applications into a container
WO2021183976A1 (fr) Fédération d'identité de niveau de conteneur d'expérience d'utilisateur et sécurité de contenu
US11277266B1 (en) Systems for secure access to protected content in a content management system
US20120131469A1 (en) Runtime usage analysis for a distributed policy enforcement system
KR102073535B1 (ko) 생산성 애플리케이션 내의 서비스 피처 인에이블링 기법
US11599353B2 (en) Hosting event-based applications
US11886620B2 (en) APP actions in a content management system
US11514052B1 (en) Tags and permissions in a content management system
WO2023248179A1 (fr) Actions d'application dans un système de gestion de contenu
US11119736B1 (en) Content management system using an application framework for integrating apps for editing content
US11741184B2 (en) Systems for launching content for publication

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23742411

Country of ref document: EP

Kind code of ref document: A1