Oipf standard translation (DAE) -- 4.3 Application Definition

4.3 Application Definition
This section defines what is meant by the concept of a 'Dae application'; which files and assets are considered to be part of a dae application and how this relates to Dae application security and lifecycle.
A Dae application is an associated collection of documents (typically JavaScript, CSS and HTML or SVG documents)
From the same fully-qualified domain, unless specified differently in section 5.1.1.3. It is accessed over TLS and
Authenticated with an X509 Certificate. access to privileged capabilities can be requested through extensions to the X509 Certificate (see section 10.1 ). whilst the document is loaded within the browser, an additional browser object (the oipfapplicationmanager object), defined in section 7.2.1 is present and accessible by the Dae application. the
Applicationmanager object provides access to the application class defined in Section 7.2.2 which provides
Javascript properties and methods that a dae application possesses that exceed those of traditional "Web pages ".
The difference between a dae application and a traditional web page is the context within which it is loaded and
Executes. For this reason, the definition and details of a dae application focuses on the Application Execution
Environment and the additional capabilities provided to Dae applications. The next subsections describe some of
Differences. Additional details about the Dae application lifecycle can be found in section 5.1

 

4.3 Application Definition

 

This section describes the concept of a "Dae application", what files and objects (assets item ?) Can be used as an integral part of the Dae application, as well as the relationship with the security and lifecycle of the Dae application.

 

A Dae application is a collection of related documents (typical JavaScript, CSS, HTML, or SVG documents, these documents come from the same fully qualified host (Web server:) (I guess it is in the documentation specification), which is probably equivalent to being authorized) remove the differences defined in 5.1.1.3. Its access is authenticated by TLS (Secure Transport Protocol) and X509 Certificate. The access privilege function uses an extended X509 Certificate (see section 10.1 ). As the browser loads the document, the Dae application can display and obtain the extension object (defined in section 7.2.1.) of the browser ). The applicationmanager object provides access to the application class (defined in Section 7.2.2). This class provides JavaScript attributes and methods for calling. The DAE application calls these interfaces on a general web page.

 

The difference between a dae application and a traditional page is that the content is loaded and executable. Therefore, the definition and details of the Dae application focus on the application execution environment and the scalability provided by the Dae application.

 

========================================================== ========================================================== =

 

Left: 0px "> 4.3.1 similarities between applications and traditional Web pages
Both applications and traditional web pages have an initial document, almost always written in HTML, which can include the contents of other documents. these encoded documents can have a variety of types, including Cascading Style Sheets (CSS), JavaScript, SVG, JPEG, PNG and GIF. A dynamic Dom, combined with XMLHttpRequest, permits Ajax-style changes to the current application or web page without necessarily replacing the entire document.

A dynamic Dom, combined with XMLHttpRequest, permits Ajax-style changes to the current application or web page without necessarily eplacing the entire document.

 

4.3.1 Dae application and traditional page Similarity

Both of them have a starting document (PAGE), which is almost all in HTML language and can contain the content of other types of documents. These include various types of documents, such as Cascading Style Sheets (CSS), JavaScript, SVG, JPEG, PNG, and GIF.

 

Combined with dynamic DOM technology and XMLHttpRequest, this Ajax-style method can dynamically modify the content of a page or (DAE) application without re-loading (replacing) the entire page.

 

 

========================================================== ========================================================== =

 

4.3.2 differences between applications and traditional Web pages

An application is created and terminated in a different manner to a Web page. For the case of application creation, it is

This difference that indicates to the browser that a new application is being started, rather than the loading of a (new) Web

Page. For the case of application destruction, the difference indicates the termination of an application, as opposed to

Loading of new contents within the context of the current application.

 

The application context should des information about the state of an application from the platform's perspective-

Permissions, priority (importance: Which to terminate first in the event of insufficient resources, for example) and similar

Information that spans all privileges ents within an application during the life time of that application.

An oitf shall support the execution of more than one application simultaneously. Applications may share the same

Screen estate in a defined and controlled fashion. This differs from multiple web pages, which are typically handled

Through different browser "windows" or "tabs" and may not share the same screen estate concurrently (although

Details of this behaviour are often browser-dependent). This also differs from the use of frames, which, apart from

Iframes, do not support overlapping screen estate. Both foreground and background applications shall be supported

Simultaneously.

 

Applications shall be recorded within a hierarchy of applications. Each object representing an application possesses

An interface that provides access to methods and attributes that are uniquely available to applications. For example,

Facilities to create and destroy applications can be accessed through such methods

 

 

4.3.2 differences between applications and traditional pages

 

The creation and termination of an application are different from those on a web page. For application creation, this difference is reflected in the browser's opinion that it is the start of an application, rather than the loading of a (new) page ). the difference between destroying an application lies in the termination of an application. It is totally different from loading new content to replace the content in the current application.

The content of an application contains the status information of the application, which is derived from the permissions of the platform and has a priority (importance: determines which one is terminated first when resources are insufficient, for example, note) and similar information that exists throughout the entire lifecycle of the application. Oitf should support running more than one application simultaneously. All applications running at the same time share the same screen space and have a unified definition and control method ). This is different from multiple web pages. Multiple web pages are usually implemented through different browser windows or tags (Multi-tag pages, the screen space is not shared at the same time (but its details depend on the behavior of different browsers ). Similarly, this method is different from the frame (frames). Apart from IFRAME, this method does not support front and back overlaps of screen space. Both foreground and background applications should be supported at the same time. All applications are recorded and constitute a hierarchy (Note: applications can be indexed or listed, but I don't know much about translation ). Each object can represent an application. These objects have an interface that provides attributes and methods for accessing the application set. For example, this method can be used to create or deregister an application. [Note: I guess there is a list of applications. An object can be used to point to each application, and corresponding methods and attribute calls can be executed for it ].

 

========================================================== ========================================================== =

4.3.3 The application tree applications are organised into a tree structure. using the createapplication () method as defined in section 7.2.2.2, applications can be either be started as child nodes of the application or as a sibling of the application (added as a subtree of the parent of this application ). the root node of an application tree is created upon loading an initial application URI or Creating a sibling of an application tree's root node. an oitf may keep track of multiple application trees. each of these individual application trees are connected to a hidden system root node maintained by the oitf that is not accessible by other applications. applications created while the Dae environment is running (e.g. as a result of an external notification) that are not created through C Reateapplication () shall be created as children of the hidden system root node. 4.4.3 all applications in the application tree are organized into a tree structure. Using the createapplication () method (defined in section 7.2.2.2), an application can be created as a subnode or sibling node (more often, as a subtree of the current application ). The root node of an application is created when an application is loaded through Uri, or when a brother node of an application root node is created. An oitf can contain multiple application trees that are connected to an implicit (hidden) Root Node provided (maintained) by oitf, rather than maintained by other applications. An application has been created when it is running in the Dae environment (for example, because of an external notification), it is not called through createapplication, instead, a child node that hides the root node is created.

========================================================== ========================================================== =

Try to see an image:

========================================================== ========================================================== =

4.3.4 The application display model multiple applications shall be displayed on the oitf in one of the application visualization modes as defined in section 4.4.6. the mode used shall be determined prior to initialisation of the Dae execution environment and shall persist until termination or re-initialization of the Dae execution environment. the means by which this mode is chosen is outside the S Attributes of this specification. each application has an associated Dom window object and a DOM Document Object that represents the document that is currently loaded for that application. even "windowless" applications that are never made visible have an associated Dom window object. 4.3.4 The actual model of an application the display of multiple applications on oitf should conform to one of the application display modes defined in section 4.4.6. During the mode application, make sure that the Dae execution environment has been initialized and that the Dae environment has not been exited or re-initialized. The display method is beyond the scope of this specification. Each application has an associated Dom form object and Dom Document Object to represent the application in the currently loaded document (page. Even applications that never show "no form" have a corresponding Dom form object.

========================================================== ========================================================== =

4.3.4.1 manipulating an application's Dom window object each application has an associated Dom window object and a DOM Document Object that represents the document that is currently loaded for that application. even "windowless" applications that are never made visible have an associated Dom window object. standard Dom window methods are used to resize, scroll, position and access the application d Ocument (see section 4.4.6 ). revoke browsers restrict the size or location of windows; these restrictions shall not be enforced for Windows associated with applications within the browser area. any area of the display available to Dae applications may be used by any application. thus, 'widget '-style applications can create a small window that contains only the application without needing to be conce Rned with any minimum size restrictions enforced by browsers. 4.3.4.1 control (manipulating) the DOM form object of the Application each application has an associated Dom form object and Dom Document Object, used in the currently loaded document (page) the application itself. Even applications that never show "no form" have a corresponding Dom form object. The standard DOM form method can change the size, scroll control, positioning (coordinates) control, and access document applications (see section 4.4.6 ). Many browsers limit the size and location of the Form. These restrictions should not force the associated form of the application to be located within the browser area. Any display area provided by the Dae application should be available to any application. From this point of view, "widgets" (called a small floating application, first introduced by Yahoo)-style applications can create a small form, it only contains applications without considering the minimum size limit of the browser. ========================================================== ========================================================== ===== 4.3.5 The Security Model each application has a set of permissions to perform varous privileged operations within the oitf. the permissions that are granted to an application are defined by the intersection of three permission sets: 1. the permissions requested by the application, using the mechanic defined in SE Ction 10. 2. the permissions supported by the oitf. some permissions may not be supported due to capability restrictions (e.g. the permission_pvr permission will never be granted on a holding er that does not support PVR capability ). 3. the permissions that may be granted, as determined by user settings or configuration settings specified by the operator (e.g. blacklists or whitelists; see section 1 0 for more information ). this is a subset of (2), and may be different for different users. 4.3.5 the permissions of each application in the security model are set to allow various privileged operations within oitf. The permissions of an application depend on the intersection of the following three permissions: 1. the permissions required by the application follow the Mechanism defined in section 10th; 2. permissions supported and defined by oitf. Some permissions may not be supported due to capacity restrictions (for example, a device that does not support the PVR function will never support a permission definition related to PVR); 3. for less important permissions, you can rely on the operator's settings or configuration decisions (for example, blacklist or whitelist, see section 10 ). The subset of the second item, which may vary with the user; ========================================================== ========================================================== ===== 4.3.6 Inheritance of permissions Applications created by other applications (e.g. using the methods described in sections 5.1.1.2 or 5.1.1.3) shall not inherit the permissions issued to the parent application. the permissions granted to the new application will be defined by the mechanic specif IED in section 10. when an application uses cross-document messaging as defined in [HTML5] to communicate with another application, any action carried out in response to the message shall take place in the security context of the application to which the message was sent. applications shocould take care to ensure that privileged actions are only taken in response to messages from an appropriate sour Ce. 4.3.6 permission inheritance one application is created by another (using methods defined in 5.1.1.2 and 5.1.1.3), but it should not inherit the permission definition of its parent node (creator. The permission definition mechanism for newly created programs is defined in section 10th. Every time an application uses a cross-document message defined in HTML5 to communicate with another application, the response information of any action should carry the security content of the application and be sent to the command sender. Applications should note that commands carrying privileged operations come from an appropriate (authorized) sender (source ). ========================================================== ========================================================== ===== 4.3.7 privileged application APIs the privilege model implemented with applications is based upon requiring access to the application object representing an application in order to access the privileged functionality related to application lifecycle management and management inter-Application Communication. only web pages run Ning as Dae applications (e.g. from a known provider and loaded via TLS) have access to an application object (via the application/oipfapplicationmanager object ). 4.3.7 application confidentiality (Security)-related API applications implement authorization security models based on Application Object Access (control), indicating that the application accesses a privileged function (function call) coordinates with the application lifecycle manager and cross-program communication. I think it cannot be translated !) Only when the web page is running as a dae application (for example, loading from a known provider through TLS) Can you access an Application Object (through the application/oipfapplicationmanager object ). ========================================================== ========================================================== ===== 4.3.7.1 compromising the security since applications have access to application objects, it is possible for applications to compromise the security of the framework by passing these objects to untrusted code. for example, an application cocould raise an event on an untrusted document and pass a reference to its appli Cation object in the message. any callto methods on an application object from pages not running as part of an application from the same provider shall throw an error as defined in section 10.1.1. 4.3.7.1 Security Mechanism threats because the application must access the application object, it may cause the application to pass in Untrusted code to the application object, thus compromising the security model (framework ). For example, an application can issue an event in an untrusted document (PAGE) and send a message to it by referencing an application object. The call on any application object from the page cannot run as part of the application (the same provider), but should throw an error (defined in 10.1.1 ). ========================================================== ========================================================== =====