text:
WO2016122623A1 - Secure api communication - Google Patents
Secure api communication Download PDF
WO2016122623A1 PCT/US2015/013864 US2015013864W WO2016122623A1 WO 2016122623 A1 WO2016122623 A1 WO 2016122623A1 US 2015013864 W US2015013864 W US 2015013864W WO 2016122623 A1 WO2016122623 A1 WO 2016122623A1
PCT/US2015/013864
Yeon WHANG
Hewlett Packard Enterprise Development Lp
2015-01-30 Application filed by Hewlett Packard Enterprise Development Lp filed Critical Hewlett Packard Enterprise Development Lp
2015-01-30 Priority to PCT/US2015/013864 priority Critical patent/WO2016122623A1/en
238000004891 communication Methods 0 abstract claims description title 181
230000004044 response Effects 0 abstract claims description 76
239000002609 media Substances 0 claims description 47
230000037361 pathway Effects 0 description 1
230000001902 propagating Effects 0 description 1
G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
G06F21/31—User authentication
G06F21/33—User authentication using certificates
G06F21/335—User authentication using certificates for accessing specific resources, e.g. using Kerberos tickets
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/2103—Challenge-response
An example computing device provides secure Application Programming Interface (API) communication. The example computing device may comprise an API communication engine to communicate with an application executing on a second computing device. The API communication engine may communicate with the application by sending an API call to the second device, the API call comprising a dynamic device access token and first meter information, the first meter information related to first usage of the application. The API communication engine may then receive, from the second computing device, an API response comprising a dynamic first device access token and second meter information, the second meter information related to second usage of the application. The API communication engine may determine whether the communication between the first device and the second device is secure based on a comparison of the API call and the API response.
SECURE API COMMUNICATION
[0001 ] Devices communicate with applications using Application Programming Interfaces ("APIs"). An API for an application may comprise a set of API calls that a device may use to interact with the application. Each API call may be associated with a set of functionality and/or other API calls. Use of an API call may specify how an application should act responsive to receiving the call. A conversation between a device and an application (e.g., an application executing on a separate device) may comprise a plurality of API calls sent by the device to the application and a corresponding plurality of API responses sent by the application to the device,
BREF DESCRIPTION OF THE DRAWS GS
[0002] The following detailed description references the drawings, wherein:
[0003] FIG. 1 is a block diagram of an example device engaging in secure API communication;
[0004] FIG. 2 is a block diagram of an example consumer device and provider device engaging in secure API communication;
[0005] FIG. 3A is a flow diagram of an example method for execution by an example consumer device and provider device engaging in secure API communication;
[0006] FIG. 3B is a flow diagram of an example method for execution by an example consumer device and provider device engaging in secure API communication;
[0007] FIG. 4 is a flowchart of an example method for execution by an example consumer device and provider device engaging in secure API communication;
[0008] FIG. 4A is a flowchart of an example method for execution by an example consumer device and provider device engaging in secure API communication;
[0009] FIG. 5 is a block diagram of an example device engaging in secure API communication; and [0010] FIG. 8 is a block diagram of an example device engaging in secure API communication.
DETAILED DESC IPTSON
[001 1 ] The following detailed description refers to the accompanying drawings. Wherever possible, the same reference numbers are used in the drawings and the following description to refer to the same or similar parts, it is to be expressly understood, however, that the drawings are for the purpose of illustration and description only. While several examples are described in this document, modifications, adaptations, and other implementations are possible. Accordingly, the following detailed description does not limit the disclosed examples, instead, the proper scope of the disclosed examples may be defined by the appended claims.
[0012] Devices communicate with applications using Application Programming Interfaces ("APIs"). An API for an application may comprise a set of API calls that a device may use to interact with the application. Each API call may be associated with a set of functionality and/or other API calls. Use of an API call may specify how an application should act responsive to receiving the call. A conversation between a device and an application (e.g., an application executing on a separate device) may comprise a plurality of API calls sent by the device to the application and a corresponding plurality of API responses sent by the application to the device.
[0013] A provider device may provide the application for access by a user via a consumer device. As such API communication may occur between the provider device and the consumer device. A technical challenge may exist in this API communication, as the consumer device may have no knowledge of whether a security breach occurs in the communication, and may be reliant on the provider device to detect breaches and notify the user of the consumer device. Further, the only authentication provided by a user of the consumer device may comprise, for example, authentication via user name and password, authentication tokens, and/or other similar discrete authentication methods.
[0014] Examples disclosed herein provide technical solutions to these technical challenges. An example computing device provides secure Application Programming interface (API) communication. The example computing device may comprise an API communication engine that communicates with an application executing on a second computing device. The API communication engine may communicate with the application by sending an API call to the second device, the API call comprising a dynamic device access token and first meter information, the first meter information related to first usage of the application. The API communication engine may then receive, from the second computing device, an API response comprising a dynamic first device access token and second meter information, the second meter information related to second usage of the application. The API communication engine may determine whether the communication between the first device and the second device is secure based on a comparison of the API call and the API response.
[0015] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. The term "plurality," as used herein, is defined as two or more than two. The term "another," as used herein, is defined as at least a second or more. The term "coupled," as used herein, is defined as connected, whether directly without any intervening elements or indirectly with at least one intervening elements, unless otherwise indicated. Two elements can be coupled mechanically, electrically, or communicatively linked through a communication channel, pathway, network, or system. The term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items, it will also be understood that, although the terms first, second, third, etc. may be used herein to describe various elements, these elements should not be limited by these terms, as these terms are only used to distinguish one element from another unless stated otherwise or the context indicates otherwise. As used herein, the term "includes" means includes but not limited to, the term "including" means including but not limited to. The term "based on" means based at least in part on.
[0016] FIG. 1 is an example first computing device 100 that provides secure API communication. The first computing device 100 may be any type of computing device providing a user interface through which a user can interact with a software application and communicate with a second computing device. For example, first computing device 100 may include a laptop computing device, a desktop computing device, an all-in-one computing device, a tablet computing device, a mobile phone, an electronic book reader, a network-enabled appliance such as a "Smart" television, a server, and/or other electronic device suitable for processing user interactions with an application.
[0017] The various components (e.g., components 110 and 120) depicted in FIG. 1 may be coupled to at least one other component via a network. According to various implementations, the API communication engine 120 and the various components described herein may be implemented in hardware and/or a combination of hardware and programming that configures hardware. The term "engine", as used herein, refers to a combination of hardware and programming that performs a designated function. The hardware of each engine, for example, may include one or both of a processor (e.g., processor 110) and a machine-readable storage medium, while the programming is instructions or code stored on the machine-readable storage medium and executable by the processor to perform the designated function. Furthermore, in FIG. 1 and other Figures described herein, different numbers of components, engines, or entities than depicted may be used.
[0018] API communication engine 120 may facilitate secure communication between the first device 100 and a second device. For example, the API communication engine 120 may facilitate secure communication between the first device 100 and an application executing on the second device. The API communication engine 120 may facilitate authentication and initial communication between the first device 100 and the second device, and may then provide for continued secure communication between the first device 100 and the second device. The API communication engine 120 may provide for secure communication by determining whether a security breach has occurred at the first device 100 and/or at the second device.
[0019] The API communication engine 120 may comprise a set of handlers that may interrupt communication from the first device 100 to the second device. The API communication engine 120 may use the set of handlers to interrupt the communication to insert an API call and/or an API response into the communication, to determine whether a security breach exists based on communication between the first device 100 and the second device, and/or otherwise facilitate provision of secure communication between the first device 100 and the second device. As such, functionality performed by the API communication engine 120 as described herein may be performed responsive to the set of handlers interrupting the communication between the first device and the second device.
[0020] API communication engine 120 may facilitate authentication and initial communication between the first device 100 and the second device. For example, the API communication engine 120 may require an initial authentication of a user using the first device 100 based on a usemame and password, an authentication token, biometric authentication, any combination thereof, and/or other authentication techniques.
[0021 ] Responsive to the initial authentication being verified, the API communication engine 120 may send an initial API call from the first device 100 to the second device. Each API call (including an initial API call and subsequent API calls) may comprise, for example, a first dynamic access token related to the first device, metering information related to usage of the application, a second dynamic access token related to the second device, and a security label indicating a security status of the first device.
[0022] The initial API call may comprise a first dynamic access token generated by the first device 100, a security label indicating that the communication is new, and/or other information. The initial API call may have null or empty values for the metering information and the second dynamic access token. In some examples, the initial API call may also comprise a user authentication credential. The API communication engine 120 may store the first dynamic access token for later verification of an incoming initial API response from the second device.
[0023] The second device may authenticate the user (e.g., based on the user authentication credential).
[0024] Responsive to the second device not authenticating the user (e.g., based on the user authentication credential not being authorized), the second device may indicate that a breach has occurred. For example, the second device may indicate that a breach has occurred by facilitating provision of an alert to the user to notify the user of a security breach and/or force the user to perform authentication again. The alert may be provided to the user via a communication method separate from the communication method between the first device 100 and the second device (e.g., via email, text, and/or other separate communication method). In some examples, the alert may be provided to a separate device of the user. The alert may provide information which may be needed for the authentication of the user. For example, the alert may comprise a token, information, and/or other data that may need to be entered at the first device 100 and verified by the first device 100 and/or the second device in order for the authentication to be validated. Responsive to the authentication being validated, the API communication engine 120 may again facilitate the initial communications between the first device 100 and the second device.
[0025] Responsive to authenticating the user, the second device may respond to the initial API call by saving the first dynamic access token received in the initial API call and by sending the first device an initial API response. Each API response (including an initial API response and subsequent API response) may comprise, for example, a first dynamic access token related to the first device, metering information related to usage of the application, a second dynamic access token related to the second device, and a security label indicating a security status of the second device. The initial API response may comprise first metering information, a second dynamic access token, and a security label. The initial API response may comprise a null or empty value for the first dynamic access token. The second device may store the second dynamic access token for later verification of an incoming API call from the first device.
[0028] Responsive to receiving the initial API response, the API communication engine 120 of the first device 100 may store the metering information, the second dynamic access token, and/or other information from the initial API response.
[0027] Responsive to receiving the initial API response and storing the relevant information, the API communication engine 120 may engage in continued communication with the second device. The API communication engine 120 may generate a first API call and send the first API call to the second device. As mentioned above, each API call may comprise a plurality of fields including, for example, a first dynamic access token related to the first device, metering information related to usage of the application, a second dynamic access token related to the second device, and a security label indicating a security status of the first device.
[0028] An API call used in communication after the initial communication between the first device 100 and the second device may comprise values for each field of the API call. The API communication engine 120 may generate the first dynamic access token for the API call. The API communication engine 120 may generate the first dynamic access token using a random generator, based on information associated with the first device 100, a combination thereof, and/or by other token generation methods.
[0029] The API communication engine 120 may determine metering information related to usage of the application based on metering information received from a previous API response (e.g., from the initial API response or the immediately previously received API response). The metering information of the API call may comprise, for example, information related to a total amount of data communicated between the first device 100 and the second device, an amount of data communicated during the immediately prior API call and API response, a total amount of communications between the first device 100 and the second device, and/or any other measurement of the usage of the application. In some examples, the API communication engine 120 may also determine the metering information based on metering information stored from one or more previously received API responses.
[0030] The API communication engine 120 may select the previous second dynamic access token from the immediately previously received API response as the second dynamic access token for the API call.
[0031 ] The API communication engine 120 may determine a security label for the API call based on a determination of whether a security breach occurred with the immediately previously received API response. Examples of security labels include "new," "no breach," "breach,", and/or other security labels that indicate a security status of the first device 100.
[0032] Responsive to receiving the API call from the first device 100, the second device may determine whether a security breach occurred regarding the received API call. The second device may determine whether a security breach occurred by comparing the second dynamic access token of the received APi call with the second dynamic access token generated for the previously sent API response from the second device. In some examples, the second device may store a set of second dynamic access tokens generated for a set of previously sent API responses. The second device may determine whether the security breach occurred by comparing the second dynamic access token of the received API call with the set of second dynamic access tokens. The set of second dynamic access tokens may comprise a predetermined number of second dynamic access tokens. The predetermined number of second dynamic access tokens may depend upon a latency of communication between the first device 100 and the second device.
[0033] Responsive to the received second dynamic access token not matching the previously generated second dynamic access token (or any of the set of second dynamic access tokens), the second device may generate an alert indicating that a security breach has occurred and/or may force authentication of the user of the first device 100. The alert may be generated and used in a manner the same as or similar to the alert generated responsive to failed authentication at the first device. Authentication may be forced in a manner the same as or similar to that described above as well.
[0034] Responsive to the received second dynamic access token matching the previously generated second dynamic access token (or any of the set of second dynamic access tokens), the second device may determine whether the metering information received in the API call corresponds to metering information of the second device (e.g., metering information stored at the second device, metering information included in the immediately previously sent APi response, metering information related to current usage of the application executing on the second device, and/or some other measurement of usage of the application). The received metering information may correspond to the metering information of the second device based on calculations performed based on the received metering information and the metering information of the second device. For example, the second device may determine that the metering information corresponds responsive to an addition of an amount of usage of the application since the immediately previously sent API response and the received metering information equal the current amount of usage of the application.
[0035] Responsive to the received metering information not corresponding to the metering information of the second device, the second device may generate an alert indicating that a security breach has occurred and/or may force authentication of the user of the first device 100. Again, the alert may be generated used in a manner the same as or similar to the alert generated responsive to failed authentication at the first device and authentication may be forced in a manner the same as or similar to that described above.
[0036] Responsive to the received metering information corresponding to the metering information of the second device, the second device may determine that no security breach has occurred.
[0037] Responsive to determining that no security breach has occurred, the second device may then generate and send a first API response to the first device 100. The second device may also store the first dynamic access token of the API call. As mentioned above, each API response may comprise, for example, a first dynamic access token related to the first device, metering information related to usage of the application, a second dynamic access token related to the second device, and a security label indicating a security status of the first device.
[0038] An API response used in communication after the initial communication between the first device 100 and the second device may comprise values for each field of the API response. The second device may select the previous first dynamic access token from the immediately previously received API call as the first dynamic access token for the API response.
[0039] The second device may determine metering information related to usage of the application based on metering information received from a previous API response (e.g., from the initial API response or the immediately previously received API response), metering information stored at the second device, and/or may otherwise determine metering information. The metering information of the API response may comprise, for example, information related to a total amount of data communicated between the first device 100 and the second device, an amount of data communicated during the immediately prior API call and API response, a total amount of communications between the first device 100 and the second device, and/or any other measurement of the usage of the application.
[0040] The second device may generate the second dynamic access token for the API response. The second device may generate the second dynamic access token using a random generator, based on information associated with the second device, a combination thereof, and/or by other token generation methods.
[0041 ] The second device may determine a security label for the API response based on a determination of whether a security breach occurred with the immediately previously received API call. Examples of security labels include "new," "no breach," "breach,", and/or other security labels that indicate a security status of the second device.
[0042] The second device may send the generated API response to the first device 100. Responsive to receiving the generated API response from the second device, the API communication engine 120 of the first device 100 may determine whether a security breach occurred regarding the received API response. The API communication engine 120 may determine whether a security breach occurred by comparing the first dynamic access token of the received API response with the first dynamic access token generated for the previously sent API call from the first device 100. In some examples, the API communication engine 120 may store a set of first dynamic access tokens generated for a set of previously sent API calls. The API communication engine 120 may determine whether the security breach occurred by comparing the first dynamic access token of the received API call with the set of first dynamic access tokens. The set of first dynamic access tokens may comprise a predetermined number of first dynamic access tokens. The predetermined number of first dynamic access tokens may depend upon a latency of communication between the first device 100 and the second device.
[0043] Responsive to the received first dynamic access token not matching the previously generated first dynamic access token (or any of the set of first dynamic access tokens), the API communication engine 120 may generate an alert indicating that a security breach has occurred and/or may force authentication of the user of the first device 100. The alert may be generated and used in a manner the same as or similar to the alert generated responsive to failed authentication at the first device 100, Authentication may be forced in a manner the same as or similar to that described above as well.
[0044] Responsive to the received first dynamic access token matching the previously generated first dynamic access token (or any of the set of first dynamic access tokens), the API communication engine 120 may determine whether the metering information received in the API response corresponds to metering information of the first device 100 (e.g., metering information stored at the first device 100, metering information included in the immediately previously sent API call, metering information related to current usage of the application executing on the second device, and/or some other measurement of usage of the application). The received metering information may correspond to the metering information of the first device 100 based on calculations performed based on the received metering information and the metering information of the first device 100. For example, the API communication engine 120 may determine that the metering information corresponds responsive to an addition of an amount of usage of the application since the immediately previously sent API call and the received metering information equal the current amount of usage of the application.
[0045] Responsive to the received metering information not corresponding to the metering information of the first device 100, the API communication engine 120 may generate an alert indicating that a security breach has occurred and/or may force authentication of the user of the first device 100. Again, the alert may be generated and used in a manner the same as or similar to the alert generated responsive to failed authentication at the first device and authentication may be forced in a manner the same as or similar to that described above as well.
[0046] Responsive to the received metering information corresponding to the metering information of the first device 100, the API communication engine 120 may determine that no security breach has occurred.
[0047] The first device 100 and the second device may continue to engage in secured API communication in the manner described above.
[0048] In performing their respective functions, engine 120 may access data stored in a non-transitory machine-readable storage medium of first device 100. The non-transitory machine-readable storage medium of first device 100 may represent any memory accessible to first device 100 that can be used to store and retrieve data. The non-transitory machine-readable storage medium of first device 100 and/or other database may comprise random access memory (RAM), read-only memory (ROM), electrically-erasable programmable read-only memory (EEPROM), cache memory, floppy disks, hard disks, optical disks, tapes, solid state drives, flash drives, portable compact disks, and/or other storage media for storing computer-executable instructions and/or data. In some examples, the first device 100 may access non-transitory machine- readable storage medium locally or remotely via a network.
[0049] The non-transitory machine-readable storage medium of first device 100 may include a database to organize and store data. The non-transitory machine-readable storage medium of first device 100 may be, include, or interface to, for example, a relational database. The database may reside in a single or multiple physical device(s) and in a single or multiple physical location(s). The database may store a plurality of types of data and/or files and associated data or file description, administrative information, or any other data.
[0050] In some examples, the non-transitory machine-readable storage medium of first device 100 may be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. In some implementations, the non-transitory machine-readable storage medium of first device 100 may be a non-transitory storage medium, where the term "non- transitory" does not encompass transitory propagating signals. The non- transitory machine-readable storage medium of first device 100 may be implemented in a single device or distributed across devices. Likewise, processor 1 10 may represent any number of processors capable of executing instructions stored by the machine-readable storage medium. The processor 110 may be integrated in a single device or distributed across devices. Further, the machine-readable storage medium may be fully or partially integrated in the same device as the processor 1 10, or it may be separate but accessible to that device and the processor 110.
[0051 ] In one example, the machine-readable storage medium may comprise instructions that may be part of an installation package that when installed can be executed by processor 1 10 to implement the functionality described herein. For example, the machine-readable storage medium may be a portable medium such as a floppy disk, CD, DVD, or flash drive or a memory maintained by a server from which the installation package can be downloaded and installed. In another example, the program instructions may be part of an application or applications already installed. Here, the machine-readable storage medium may include a hard disk, optical disk, tapes, solid state drives, RAM, ROM, EEPROM, or the like.
[0052] The processor 1 10 may be at least one centra! processing unit (CPU), microprocessor, and/or other hardware device suitable for retrieval and execution of instructions stored in the machine-readable storage medium. The processor 1 10 may fetch, decode, and execute program instructions. As an alternative or in addition to retrieving and executing instructions, the processor 110 may include at least one electronic circuit comprising a number of electronic components for performing the functionality of at least one of instructions.
[0053] FIG. 2 is an example first computing device 100 and a second computing device 200 that each provide secure API communication. In this example, the first computing device 100 may comprise a consumer device that accesses an application executing on second computing device 200, which may act as a provider device. The first computing device 100 may be the same as or similar to the first device 100 of FIG. 1. The second computing device 200 may comprise an API communication engine 220 that performs functionality the same as or similar to the functionality performed by the second device described in FIG. 1.
[0054] The first computing device 100 may communicate with second computing device 200 over a network 50. in some examples, the first computing device 100 may be any type of computing device providing a user interface through which a user can interact with a software application and communicate with a second device. For example, first computing device 100 may include a laptop computing device, a desktop computing device, an all-in- one computing device, a tablet computing device, a mobile phone, an electronic book reader, a network-enabled appliance such as a "Smart" television, and/or other electronic device suitable for processing user interactions with the second device 200.
[0055] The second computing device 200 may similarly comprise a laptop computing device, a desktop computing device, an all-in-one computing device, a tablet computing device, a mobile phone, an electronic book reader, a network-enabled appliance such as a "Smart" television, server, and/or other electronic device suitable for processing user interactions with the second device 200. While second computing device 200 is depicted as a single computing device, second computing device 200 may include any number of integrated or distributed computing devices serving at least one software application for consumption by first computing device 100.
[0058] Similar to the components of first device 100, the various components (e.g., components 210 and 220) depicted in second device 200 of FIG. 2 may be coupled to at least one other component via a network (e.g., network 50). According to various implementations, the API communication engine 220 and the various components described herein may be implemented in hardware and/or a combination of hardware and programming that configures hardware. As mentioned above, the term "engine", as used herein, refers to a combination of hardware and programming that performs a designated function. The hardware of each engine, for example, may include one or both of a processor (e.g., processor 210) and a machine-readable storage medium, while the programming is instructions or code stored on the machine-readable storage medium and executable by the processor to perform the designated function. The processor 210 and the machine-readable storage medium of second device 200 may comprise components and functionality the same as or similar to the respective processor 1 10 and machine-readable storage of the respective processor 110 and machine-readable storage medium of the first device 100.
[0057] API communication engine 220 may facilitate secure communication between the first device 100 and a second device. For example, the API communication engine 220 may facilitate secure communication between the first device 100 and an application executing on the second device 200. The API communication engine 220 may facilitate authentication and initial communication between the first device 100 and the second device 200, and may then provide for continued secure communication between the first device 100 and the second device 200. The API communication engine 220 may provide for secure communication by determining whether a security breach has occurred at the first device 100 and/or at the second device. [0058] FIGS. 3A and 3B are flow diagrams of an example method for execution by an example consumer device and provider device engaging in secure API communication. Although execution of the methods described below are with reference to system described in FIG. 2, other suitable devices for execution of this method may be employed to practice the present techniques. The flow diagram described in FIG. 3A and other figures may be implemented in the form of executable instructions stored on a machine- readable storage medium, such as the storage medium of the hypervisor, by one or more components described herein, and/or in the form of electronic circuitry.
[0059] The various processing blocks and/or data flows depicted in FIG. 3A (and in the other drawing figures such as FIG. 4) are described in greater detail herein. The described processing blocks may be accomplished using some or all of the system components described in detail above and, in some implementations, various processing blocks may be performed in different sequences and various processing blocks may be omitted. Additional processing blocks may be performed along with some or ail of the processing blocks shown in the depicted flow diagrams. Some processing blocks may be performed simultaneously. Accordingly, the operations depicted in the flow diagram as illustrated (and described in greater detail below) are meant be an example and, as such, should not be viewed as limiting.
[0080] In an operation 300, the first device may send a first API call to the second device. For example, the first device 100 (and/or the API communication engine 120, or other resource of the first device 100) may send the first API call. The first device may send the first API call in a manner similar or the same as that described above in relation to the execution of the API communication engine 120, and/or other resource of the first device 100. The first API call may be depicted as the request of the first API call in FIG. 3B. in some examples, and as depicted in FIG. 3B, an initial communication may occur between the first device and the second device prior to the first device sending a first API call to the second device. The initial communication, as depicted in FIG. 3B, may include initialization with a user name and password and/or other type of authentication from the user. [0081] In an operation 310, the second device may send a first APi response to the first device. For example, the second device 100 (and/or the API communication engine 220, or other resource of the second device 100) may send the first API response. The second device may send the first API response in a manner similar or the same as that described above in relation to the execution of the APi communication engine 220, and/or other resource of the second device 100. The first API response may be depicted as the response of the first API call in FIG. 3B.
[0082] In an operation 320, the first device may determine whether communication between the first device and the second device is secure. For example, the first device 100 (and/or the API communication engine 120, or other resource of the first device 100) may determine whether communication between the first device and the second device is secure. The first device may whether communication between the first device and the second device is secure in a manner similar or the same as that described above in relation to the execution of the APi communication engine 120, and/or other resource of the first device 100.
[0083] In an operation 330, the first device may send a second API call to the second device. For example, the first device 100 (and/or the API communication engine 120, or other resource of the first device 100) may send the second API call. The first device may send the second API call in a manner similar or the same as that described above in relation to the execution of the APi communication engine 120, and/or other resource of the first device 100. The second API call may be depicted as the request of the second APi call in FIG. 3B.
[0084] In an operation 340, the second device may determine whether communication between the first device and the second device is secure. For example, the second device 200 (and/or the APi communication engine 220, or other resource of the second device 200) may determine whether communication between the first device and the second device is secure. The second device may whether communication between the first device and the second device is secure in a manner similar or the same as that described above in relation to the execution of API communication engine 220, and/or other resource of the second device 200. [0085] FIG. 4 Is a flowchart of an example method for execution by an example consumer device and provider device engaging In secure API communication.
[0086] In an operation 400, the first device may send an APi call to the second device. For example, the first device 100 (and/or the API communication engine 120, or other resource of the first device 100) may send the first API call. The first device may send the first APi call in a manner similar or the same as that described above in relation to the execution of API communication engine 120, and/or other resource of the first device 100.
[0087] In an operation 410, the first device may receive, from the second device, a first API response to the first device. For example, the first device 100 (and/or the APi communication engine 120, or other resource of the second device 100) may receive the APi response. The first device may receive the API response in a manner similar or the same as that described above in relation to the execution of APi communication engine 220, and/or other resource of the first device 100.
[0088] In an operation 420, the first device may determine whether communication between the first device and the second device is secure. For example, the first device 100 (and/or the API communication engine 120, or other resource of the first device 100) may determine whether communication between the first device and the second device is secure. The first device may whether communication between the first device and the second device is secure in a manner similar or the same as that described above in relation to the execution of APi communication engine 120, and/or other resource of the first device 100.
[0089] In some examples, the determination of whether communication between the first device and the second device is secure may be performed in various manners. FIG. 4A is a flowchart of an example method for execution by an example consumer device and provider device engaging in secure API communication.
[0070] In an operation 421 , the first device may determine whether the first dynamic device access token of the API call matches the first dynamic access token of the APi response. For example, the first device 100 (and/or the API communication engine 120, or other resource of the first device 100) may determine whether the first dynamic device access token of the API caii matches the first dynamic access token of the API response. The first device may determine whether the first dynamic device access token of the API call matches the first dynamic access token of the API response in a manner similar or the same as that described above in relation to the execution of API communication engine 120, and/or other resource of the first device 100,
[0071 ] Responsive to the tokens not matching, in an operation 422, the first device may indicate that a security breach has occurred. For example, the first device (and/or the API communication engine 120, or other resource of the second device 100) may indicate that a breach has occurred by providing an alert. The first device may indicate that a breach has occurred by providing an alert in a manner similar or the same as that described above in relation to the execution of API communication engine 120, and/or other resource of the first device 100.
[0072] Responsive to the tokens not matching, in an operation 423, the first device may require authentication of the user. For example, the first device 100 (and/or the API communication engine 120, or other resource of the first device 100) may require authentication. The first device may require authentication in a manner similar or the same as that described above in relation to the execution of API communication engine 120, and/or other resource of the first device 100.
[0073] Responsive to the tokens matching, in an operation 424, the first device may determine whether the first meter information of the API call corresponds to the second meter information of the API response. For example, the first device 100 (and/or the API communication engine 120, or other resource of the first device 100) may determine whether the first meter information corresponds to the second meter information. The first device may determine whether the first meter information corresponds to the second meter information in a manner similar or the same as that described above in relation to the execution of API communication engine 120, and/or other resource of the first device 100.
[0074] Responsive to the first meter information not corresponding to the second meter information, in an operation 425, the first device may indicate that a security breach has occurred. For example, the first device (and/or the API communication engine 120, or other resource of the second device 100) may indicate that a breach has occurred by providing an alert. The first device may indicate that a breach has occurred by providing an alert in a manner similar or the same as that described above in relation to the execution of API communication engine 120, and/or other resource of the first device 100.
[0075] Responsive to the first meter information not corresponding to the second meter information, in an operation 426, the first device may require authentication of the user. For example, the first device 100 (and/or the API communication engine 120, or other resource of the first device 100) may require authentication. The first device may require authentication in a manner similar or the same as that described above in relation to the execution of API communication engine 120, and/or other resource of the first device 100.
[0076] Responsive to the first meter information corresponding to the second meter information, in an operation 427, communication between the first device and the second device may continue. For example, the first device 100 (and/or the API communication engine 120, or other resource of the first device 100) may continue communicating with the second device 200 (and/or the API communication engine 220 or other resource of the second device 200). The first device may communicate with the second device in a manner similar or the same as that described above in relation to the execution of API communication engine 120, API communication engine 220, another resource of the first device 200 and/or other resource of the second device 200.
[0077] FIG. 5 is a block diagram of an example device engaging in secure API communication. In the example depicted in FIG. 5, first device 500 includes a non-transitory machine-readable storage medium 520 and a processor 510.
[0078] Processor 510 may be one or more central processing units (CPUs), microprocessors, and/or other hardware devices suitable for retrieval and execution of instructions stored in machine-readable storage medium 520.
[0079] Processor 510 may fetch, decode, and execute program instructions 521 , and/or other instructions to provide secure API communication, as described below. As an alternative or in addition to retrieving and executing instructions, processor 510 may include one or more electronic circuits comprising a number of electronic components for performing the functionality of one or more of program instructions 521 , and/or other instructions. [0080] In one example, the program instructions can be part of an installation package that can be executed by processor 510 to implement the functionality described herein. In this case, machine-readable storage medium 520 may be a portable medium such as a CD, DVD, or flash drive or a memory maintained by another backup storage device from which the installation package can be downloaded and installed. In another example, the program instructions may be part of an application or applications already installed on backup storage device 500.
[0081 ] Machine-readable storage medium 520 may be any hardware storage device for maintaining data accessible to first device 500. For example, machine-readable storage medium 520 may include one or more hard disk drives, solid state drives, tape drives, and/or any other storage devices. The storage devices may be located in first device 500 and/or in another device in communication with first device 500. For example, machine-readable storage medium 520 may be any electronic, magnetic, optical, or other physical storage device that stores executable instructions. Thus, machine-readable storage medium 520 may be, for example, Random Access Memory (RAM), an Electrically-Erasable Programmable Read-Only Memory (EEPROM), a storage drive, an optical disc, and the like. As detailed below, storage medium 520 may maintain and/or store the data and information described herein.
[0082] Machine-readable storage medium 520 may also be encoded with executable instructions for enabling execution of the functionality described herein. For example, machine-readable storage medium 520 may store API communication instructions 521 , and/or other instructions that may be used to carry out the functionality of the herein disclosed present techniques.
[0083] API communication instructions 521 , when executed by processor 510, may communicate with an application executing on a second device. For example, API communication instructions 521 may comprise instructions to send an API call to the second device, the API call comprising a dynamic device access token, first meter information related to first usage of the application, and a second device dynamic access token. API communication instructions 521 may also comprise instructions to receive, from the second computing device, an API response comprising a dynamic first device access token, second meter information related to second usage of the application, and a second dynamic access token, API communication instructions 521 may further comprise instructions to determine whether the communication between the first device and the second device is secure based on a comparison of the dynamic device access token of the API call and the dynamic first device access token of the API response. In some examples, the functionality performed by the API communication instructions 521 , when executed by processor 510, may be the same as or similar to functionality performed by API communication engine 120 of first device 100.
[0084] FIG. 6 is a block diagram of an example device engaging in secure API communication. In the example depicted in FIG. 6, second device 600 includes a non-transitory machine-readable storage medium 620 and a processor 810. Processor 610, similar to processor 510, may be one or more central processing units (CPUs), microprocessors, and/or other hardware devices suitable for retrieval and execution of instructions stored in machine- readable storage medium 820. Machine-readable storage medium 620 may comprise hardware, functionality, and data stored thereon that is the same as or similar to machine-readable storage medium 620. Machine-readable storage medium 620 may also be encoded with executable instructions for enabling execution of the functionality described herein. For example, machine-readable storage medium 620 may store API communication instructions 621 , and/or other instructions that may be used to carry out the functionality of the herein disclosed present techniques. Machine-readable storage medium 620 may also store metering information 622. Metering information 622 may comprise the metering information stored at second device 200 as discussed above.
[0085] API communication instructions 621 , when executed by processor 610, may communicate with a first device. For example, API communication instructions 621 may comprise instructions to send an API response to the first device. API communication instructions 621 may also comprise instructions to receive, from the second computing device, an API call. API communication instructions 621 may further comprise instructions to determine whether the communication between the first device and the second device is secure based on a comparison of the API call and the API response. In some examples, the functionality performed by the API communication instructions 821 , when executed by processor 810, may be the same as or similar to functionality performed by API communication engine 220 of first device 200.
[0086] The foregoing disclosure describes a number of examples for providing secure API communication. The disclosed examples may include systems, devices, computer-readable storage media, and methods for providing secure API communication. For purposes of explanation, certain examples are described with reference to the components illustrated in FIGS. 1-8. The functionality of the illustrated components may overlap, however, and may be present in a fewer or greater number of elements and components. Further, all or part of the functionality of illustrated elements may co-exist or be distributed among several geographically dispersed locations. Further, the disclosed examples may be implemented in various environments and are not limited to the illustrated examples.
[0087] Further, the sequence of operations described in connection with FIGS. 1-6 are examples and are not intended to be limiting. Additional or fewer operations or combinations of operations may be used or may vary without departing from the scope of the disclosed examples. Furthermore, implementations consistent with the disclosed examples need not perform the sequence of operations in any particular order. Thus, the present disclosure merely sets forth possible examples of implementations, and many variations and modifications may be made to the described examples.
CLAIMS We claim:
1. A first computing device to provide secure Application Programming interface (API) communication, the first computing device comprising:
an API communication engine to communicate with an application executing on a second computing device, wherein the API communication engine to communicate with the application that includes to:
send an API call to the second device, the API call comprising a dynamic device access token and first meter information, the first meter information related to first usage of the application;
receive, from the second computing device, an API response comprising a dynamic first device access token and second meter information, the second meter information related to second usage of the application; and
determine whether the communication between the first device and the second device is secure based on a comparison of the API call and the API response.
2. The first computing device of claim 1 , wherein the API communication engine to determine whether the communication is secure that includes to:
determine whether the dynamic device access token of the API call matches the dynamic first device access token of the API response;
responsive to the dynamic device access token not matching the dynamic first device access token, indicate that a security breach has occurred.
3. The first computing device of claim 2, wherein the API communication engine further to determine whether the communication is secure that includes to:
responsive to the dynamic device access token matching the dynamic first device access token, determine whether the first meter information corresponds to the second meter information; responsive to the first meter information not corresponding to the second meter information, indicate that a security breach has occurred.
4. The first computing device of claim 1 , wherein the API communication engine to:
generate a new dynamic device access token subsequent to receiving the API response;
generate a second API call by replacing the dynamic device access token with the new dynamic device access token; and
send the second API call to the second computing device.
5. The first computing device of claim 4, wherein the API communication engine to generate the new dynamic device access token using a random generator.
6. The first computing device of claim 4, wherein the API communication engine to generate the second API call further includes to:
determine updated first meter information; and
replace the first meter information with the determined updated first meter information.
7. A method that provides secure Application Programming Interface (API) communication between a first device and a second device, the method comprising:
sending an API call from the first device to the second device, the API call comprising a dynamic device access token and first meter information, the first meter information related to first usage of an application executing on the second device;
receiving, by the first device and from the second computing device, an API response, the API response comprising a dynamic first device access token, second meter information, and a dynamic second device access token, the second meter information related to second usage of the application; and determining, by the first device, whether the communication between the first device and the second device is secure based on a comparison of the AP! call and the API response.
8. The method of ciaim 7, wherein determining whether the
communication is secure comprises:
determining, by the first device, whether the dynamic device access token of the API call matches the dynamic first device access token of the API response;
responsive to the dynamic device access token not matching the dynamic first device access token, indicating, by the first device, that a security breach has occurred.
responsive to the dynamic device access token matching the dynamic first device access token, determining, by the first device, whether the first meter information corresponds to the second meter information;
responsive to the first meter information not corresponding to the second meter information, indicating, by the first device, that a security breach has occurred.
10. The method of claim 8, further comprising:
responsive to determining that the security breach has occurred, performing authentication of a user of the first device, wherein performing authentication comprises:
sending, to a user device separate from the first device, user authentication information;
receiving, at the first device, authentication information from the user; determining, by the first device, whether the received authentication information matches the user authentication information;
enabling, by the first device, communication between the first device and the second device responsive to the received authentication information matching the user authentication information.
1 1. The method of claim 7, further comprising:
generating, by the first device, a new dynamic device access token subsequent to receiving the API response;
generating, by the first device, a second API call by replacing the dynamic device access token with the new dynamic device access token, wherein the second API call comprises the new dynamic device access token, updated first meter information, and the dynamic second device access token; and
sending, by the first device, the second API call to the second computing device.
12. The method of claim 1 1 , further comprising:
receiving, by the second device, the second API call;
determining, by the second device, whether the dynamic second device access token of the API call matches the dynamic second device access token of the API response;
responsive to the dynamic second device access token of the second API call not matching the dynamic second device access token of the API response, indicating, by the second device, that a security breach has occurred.
responsive to the dynamic second device access token of the second API call matching the dynamic second device access token of the API response, determining, by the second device, whether the updated first meter information corresponds to meter information stored at the second device; responsive to the updated first meter information not corresponding to the stored meter information, indicating, by the second device, that a security breach has occurred.
14. The method of claim 1 1 ,
wherein the API call comprises a first security label, the first security label indicating a first security status of the first device, and wherein the API response comprises a second security label, the second security label indicating a second security status of the second device.
15. A non-transitory machine-readable storage medium comprising instructions executable by a processor of a computing device to provide secure Application Programming Interface (API) communication, the machine- readable storage medium comprising instructions when executed by the processor to:
communicate with an application executing on a second computing device,
wherein the instructions to communicate with the application comprise instructions to:
send an API call to the second device, the API call comprising a dynamic device access token, first meter information related to first usage of the application, and a second device dynamic access token; receive, from the second computing device, an API response comprising a dynamic first device access token, second meter information related to second usage of the application, and a second dynamic access token; and
determine whether the communication between the first device and the second device is secure based on a comparison of the dynamic device access token of the API call and the dynamic first device access token of the API response.
PCT/US2015/013864 2015-01-30 2015-01-30 Secure api communication WO2016122623A1 (en)
PCT/US2015/013864 WO2016122623A1 (en) 2015-01-30 2015-01-30 Secure api communication
US20050289072A1 (en) * 2004-06-29 2005-12-29 Vinay Sabharwal System for automatic, secure and large scale software license management over any computer network
US7016965B2 (en) * 2001-11-13 2006-03-21 International Business Machines Corporation System and method for asynchronously reading data across secure sockets layer sessions
US20100031308A1 (en) * 2008-02-16 2010-02-04 Khalid Atm Shafiqul Safe and secure program execution framework
US20110191593A1 (en) * 2009-10-12 2011-08-04 Safenet, Inc. Software License Embedded In Shell Code
US20140304771A1 (en) * 2010-12-27 2014-10-09 Microsoft Corporation Application execution in a restricted application execution environment
Chin et al. 2012 Measuring user confidence in smartphone security and privacy
US9571509B1 (en) 2017-02-14 Systems and methods for identifying variants of samples based on similarity analysis
TWI277904B (en) 2007-04-01 Method, recording medium and system for protecting information
US20190188394A1 (en) 2019-06-20 Security engine for a secure operating environment
US9882912B2 (en) 2018-01-30 System and method for providing authentication service for internet of things security
JP5624620B2 (en) 2014-11-12 Plug-in authority control method and system
US8352679B2 (en) 2013-01-08 Selectively securing data and/or erasing secure data caches responsive to security compromising conditions
WO2012064171A1 (en) 2012-05-18 A method for enabling a trusted platform in a computing system
WO2014124023A1 (en) 2014-08-14 Integrated circuit identification and dependability verification using ring oscillator based physical unclonable function and age detection circuitry
US8904507B2 (en) 2014-12-02 System and method for controlling user access to a service processor
US9619654B2 (en) 2017-04-11 Application monitoring through collective record and replay
US8245053B2 (en) 2012-08-14 Methods and systems for binding a removable trusted platform module to an information handling system
EP2672420A2 (en) 2013-12-11 System and method for remotely initiating lost mode on a computing device
TWI330769B (en) 2010-09-21 Apparatus method and system for feature activation
TWI549013B (en) 2016-09-11 Providing a persona-based application experience
US9520998B2 (en) 2016-12-13 System and method for recovery key management
WO2013123829A1 (en) 2013-08-29 Software installation method, device and system
US9529990B2 (en) 2016-12-27 Systems and methods for validating login attempts based on user location
CN102301641A (en) 2011-12-28 Software application verification
CN103329095B (en) 2017-03-22 Authenticate a hypervisor with encoded information
US8086838B2 (en) 2011-12-27 Methods and systems for providing manufacturing mode detection and functionality in a UEFI BIOS
US20130312088A1 (en) 2013-11-21 Electronic device and method for managing accounts and passwords of application systems
US9401925B1 (en) 2016-07-26 Systems and methods for detecting security threats based on user profiles
US8904503B2 (en) 2014-12-02 Systems and methods for providing access to data accounts within user profiles via cloud-based storage services
JP2015525932A (en) 2015-09-07 Login verification method, client, server, and system
2016-09-14 121 Ep: the epo has been informed by wipo that ep was designated in this application
2017-08-01 NENP Non-entry into the national phase in:
2018-02-21 122 Ep: pct application non-entry in european phase


Dongguan BOFA Lighting Co., Ltd is among the largest and best indoor or outdoor string lights manufacturers. We are offering the best quality LED string lights to assist your decorative personality. The S14 string lights on our platform are absolutely best for decorating a room or any event set to take place in your backyard. These patio string lights are the perfect article to give your event an exceptionally outstanding ambiance. Their vintage style exposed filament LED bulbs provide a retro look, at the same time delivering a radiant glow, which creates an ideal and quintessential environment.
At Bofa we understand the power concerns of general public and thus our manufactured lights are power efficient and require merely 2 watts per bulb to function, using much less power than halogen or incandescent bulbs they are made to have a longer lifespan. To keep these decorative string lights easy on the budget we have now also introduced solar panel equipped lights, eliminating the use of electricity totally.
We have the massive collection of waterproof LED commercial outdoor string lights. These lights provide endless opportunities to transform your backyard or any other outdoor space into something magical. Our LED lights will add a touch of elegance to any outdoor space and are great for all occasions, including but not limited to weddings, barbecues, birthday parties, and family reunions. Our commercial string lights are infused with the latest weathertite technology, adding a sturdiness and durability which allows them to be left up all year round, through rain or shine.
The lights available on BOFA are bright enough to light up any space but they also offer a possibility to be dimmed as per your requisition. Available in plenty of colors and shapes, the opportunities with our decorative lights are endless and you can get creative with them to compliment your overall decoration.
We Dongguan Bofa Lighting factory is a leading manufacturer professionally producing all kinds of decorative led bulbs, Vintage Led Bulbs, Soft flexible led bulbs, Dip led bulbs, CopperWire Led bulbs, Crown Mirror Reflecting lamp, Frosted lamp, Opal White led lamps, Oven lamps and Etc. We have more than 2000 different models.


text:
Q: Custom font on Wordpress not working I'm trying to figure out why my custom font is not loading on WordPress (MAMP, Mac, localhost).
The fonts are stored in wp-content/themes/twentysixteen/fonts/
Then in wp-content/themes/twentysixteen/style.css I have the following CSS:
@font-face {
  font-family: "Averta-Regular";
  src: font-url("./fonts/31907B_A_0.eot");
  src: font-url("./fonts/31907B_A_0.eot?#iefix") format('embedded-opentype'), font-url("./fonts/31907B_A_0.woff2") format('woff2'), font-url("./fonts/31907B_A_0.woff") format('woff'), font-url("./fonts/31907B_A_0.ttf") format('truetype');
}

html {
  font-family: "Averta-Regular", "Helvetica Neue", sans-serif;
  -webkit-text-size-adjust: 100%;
  -ms-text-size-adjust: 100%;
}

body {
  margin: 0;
  font-family: "Averta-Regular", "Helvetica Neue", sans-serif;
}

Chrome shows me this:

It only works if I have the font installed on my operating system.

A: Try changing font-url to url on lines 3 and 4 of your CSS. It looks like it just isn't recognizing the source of the custom fonts you're trying to load.

A: You have to link that font in functions.php
Like this
wp_enqueue_style( 'custom', get_template_directory_uri() . 'https://fonts.googleapis.com/css?family=Roboto' );

A: Download a ttf font, one available for commercial use, visit https://1001fonts.com/free-fonts-for-commercial-use.html?page=1&items=10 paste a copy into your theme and use @font-face just as you've done above. Everything should work just fine. While I was developing on my local server, everything was working fine. On publishing into public_html, the font refused to load. Had to change to a ttf, you can also try other web fonts format but the ttf works just fine. Better still you can use the google fonts.

A: I encountered something similar when I was using this wordpress uncode child theme and uploading custom fonts.
I realised it was because I didn't end the second src attribute with a ;
@font-face{
  font-family: 'Lato';
  src: url('fonts/Lato.eot');
  src: url('fonts/Lato.eot?#iefix') format('embedded-opentype'),
  url('fonts/Lato.woff') format('woff'),
  url('fonts/Lato.ttf') format('truetype'),
  url('fonts/Lato.otf') format('opentype'),
}

Once I replaced it, the fonts worked. Stupid mistake but hard to spot after you work for a couple of hours.
@font-face{
  font-family: 'Lato';
  src: url('fonts/Lato.eot');
  src: url('fonts/Lato.eot?#iefix') format('embedded-opentype'),
  url('fonts/Lato.woff') format('woff'),
  url('fonts/Lato.ttf') format('truetype'),
  url('fonts/Lato.otf') format('opentype');
}

redpajama_set_name: RedPajamaStackExchange


text:
package com.facebook.buck.android;

import static org.junit.Assert.assertNotEquals;
import static org.junit.Assert.assertThat;

import com.facebook.buck.io.ProjectFilesystem;
import com.facebook.buck.model.BuildTargetFactory;
import com.facebook.buck.model.BuildTargets;
import com.facebook.buck.rules.BuildInfo;
import com.facebook.buck.testutil.integration.ProjectWorkspace;
import com.facebook.buck.testutil.integration.TemporaryPaths;
import com.facebook.buck.testutil.integration.TestDataHelper;
import com.facebook.buck.util.sha1.Sha1HashCode;
import com.facebook.buck.zip.ZipConstants;

import org.apache.commons.compress.archivers.zip.ZipUtil;
import org.hamcrest.Matchers;
import org.junit.Before;
import org.junit.Rule;
import org.junit.Test;

import java.io.FileInputStream;
import java.io.IOException;
import java.nio.file.Path;
import java.util.Date;
import java.util.zip.ZipEntry;
import java.util.zip.ZipInputStream;

public class AaptPackageResourcesIntegrationTest {
  @Rule
  public TemporaryPaths tmpFolder = new TemporaryPaths();

  private ProjectWorkspace workspace;
  private ProjectFilesystem filesystem;

  private static final String MAIN_BUILD_TARGET = "//apps/sample:app";
  private static final String PATH_TO_LAYOUT_XML = "res/com/sample/top/res/layout/top_layout.xml";

  @Before
  public void setUp() throws IOException {
    workspace = TestDataHelper.createProjectWorkspaceForScenario(
        this, "android_project", tmpFolder);
    workspace.setUp();
    filesystem = new ProjectFilesystem(workspace.getDestPath());
  }

  @Test
  public void testEditingLayoutChangesPackageHash() throws IOException {
    AssumeAndroidPlatform.assumeSdkIsAvailable();
    workspace.runBuckBuild(MAIN_BUILD_TARGET).assertSuccess();

    // This is too low-level of a test.  Ideally, we'd be able to save the rule graph generated
    // by the build and query it directly, but runBuckCommand doesn't support that, so just
    // test the files directly for now.
    Path pathRelativeToProjectRoot = BuildInfo
        .getPathToMetadataDirectory(
            BuildTargetFactory.newInstance("//apps/sample:app#aapt_package"),
            new ProjectFilesystem(workspace.getDestPath()))
        .resolve(AaptPackageResources.RESOURCE_PACKAGE_HASH_KEY);
    String firstHash = workspace.getFileContents(pathRelativeToProjectRoot);

    workspace.replaceFileContents(PATH_TO_LAYOUT_XML, "white", "black");

    workspace.runBuckBuild(MAIN_BUILD_TARGET).assertSuccess();

    String secondHash = workspace.getFileContents(pathRelativeToProjectRoot);

    Sha1HashCode firstHashCode = Sha1HashCode.of(firstHash);
    Sha1HashCode secondHashCode = Sha1HashCode.of(secondHash);
    assertNotEquals(firstHashCode, secondHashCode);
  }

  @Test
  public void testIgnoredFileIsIgnoredByAapt() throws IOException {
    AssumeAndroidPlatform.assumeSdkIsAvailable();
    workspace.runBuckBuild("//apps/sample:app_deps_resource_with_ignored_file").assertSuccess();
  }

  @Test
  public void testAaptPackageIsScrubbed() throws IOException {
    AssumeAndroidPlatform.assumeSdkIsAvailable();
    workspace.runBuckBuild(MAIN_BUILD_TARGET).assertSuccess();
    Path aaptOutput = workspace.getPath(
        BuildTargets.getGenPath(
            filesystem,
            BuildTargetFactory.newInstance(MAIN_BUILD_TARGET)
                .withFlavors(AndroidBinaryResourcesGraphEnhancer.AAPT_PACKAGE_FLAVOR),
            AaptPackageResources.RESOURCE_APK_PATH_FORMAT));
    Date dosEpoch = new Date(ZipUtil.dosToJavaTime(ZipConstants.DOS_FAKE_TIME));
    try (ZipInputStream is = new ZipInputStream(new FileInputStream(aaptOutput.toFile()))) {
      for (ZipEntry entry = is.getNextEntry(); entry != null; entry = is.getNextEntry()) {
        assertThat(entry.getName(), new Date(entry.getTime()), Matchers.equalTo(dosEpoch));
      }
    }
  }
}

redpajama_set_name: RedPajamaGithub


When you first discover that your child has to have eyeglasses, there is a good chance it will be when they are in their adolescent years. This is related to the fact that the eyeballs are growing and changing at a rapid rate in teens, which can cause nearsightedness to make its presence known. As a parent of a teenager, it can be quite a challenge to encourage your child to wear their new eyeglasses in spite of the fact that they can see better. Here are a few of the most frequent parental concerns and answers about adolescents and their glasses.
If your teen will not wear their glasses, will their eyesight get worse?
Eyesight can worsen to a degree if a developing child does not wear their prescribed glasses. Therefore, if your teen is refusing to wear their glasses, it is a good idea to point out that not doing so could actually lead to worse issues with vision that may require even stronger lenses and lead to many other issues, such as not being able to learn to drive.
Is it a good idea to have your child fitted for contact lenses instead?
In most cases, contact lenses are a perfectly safe solution for teens and adolescents. In fact, some optometrists claim that contact lenses are easier for younger adults because they have eyes that are naturally more lubricated. Furthermore, some teenagers will do just about anything to avoid having to have glasses, and therefore, will gladly take contact lenses instead.
How often should your child's eyes be rechecked to see if anything has changed?
The answer to this can depend on several factors, such as the type of eye problems your child has and their age. However, it is a good idea for your teen to have their eyes checked at least once every year to assess any changes that may have occurred. It is not uncommon for some issues, such as myopia, to go away on their own as the child develops and matures. So it is always a good idea to have the eyes checked out for better or worse vision.
Even though your teenager may hate the idea of having to wear glasses, it is best to encourage them as much as you can to take care of their eyes. Adolescents can be difficult people to deal with at times, but they are also growing old enough to understand the importance of their own health. For more information, talk to the professionals at Cohen's Fashion Optical.


We are a leading architecture and interior design firm in Noida with more than 8 Years of specialized experience. The primary expertise of the Architects and Interior Designers working at the firm lies in High-End House Designs, Villa designs and Bungalows. Chaukor is an award winning design firm and has delivered 10+ recognized and internationally acclaimed projects.
Houses designed at Chaukor are User-Centric and Eco-Friendly; in other words - REGENERATIVE !
The primary expertise of the Architects and Interior Designers working at the firm lies in High-End House Designs, Villa designs and Bungalows. Houses designed at Chaukor are User-Centric and Eco-Friendly.


text:
DRIVEN: Hyundai Staria ushers in a completely new look and feel in the MPV segment
By Willem van de Putte Nov 8, 2021
Launch review: Hyundai Staria
Johannesburg - Hyundai is are known for their value for money offering and when they introduced the Palisade earlier this year and broke the R1-million barrier it raised a few eyebrows but on closer inspection it still provides bang for your buck.
Now with the introduction of the Staria MPV and specifically the top of the range Luxury model they have two vehicles just over that mark, with the Staria Elite squeaking in under six figures. The other two versions are the Executive nine-seater and also an 11-seater Executive model.
The Staria replaces the well-liked H1 which has been around for 11 years and over that time sold 22 377 units.
The two could not be more different in every aspect. The Staria certainly has an eye-catching design and I'd say it's now the best looking offering in the category.
2021 Mercedes-Benz Vito facelift offers value-adding enhancements
ROAD TRIP: 800km coastal drive in the new Volkswagen T6.1 Kombi
Here's why you might be able to smoke a joint in the 2025 'Hippie Kombi'
Hyundai wanted a space-age look for their new halo product and they certainly got that right with an eye-catching grille, vertical lights, alloy wheels and tall vertical rear light cluster.
My first impression when I saw it in the metal was that it looked like the kind of vehicle that could easily pass for an EV if you didn't know better.
It doesn't have a battery but rather Hyundai's 2.2-litre VGT turbo-diesel that's good for 130kW and 430Nm and paired to a sublime eight-speed automatic transmission.
There's something about sitting behind the wheel in a captain's chair in a bus like this. The upright driving position, low door frame, lots of glass and digital instrument cluster makes you want to take a busman's holiday.
The interior is fitted with quality materials, soft-touch surfaces, easy to reach buttons and dials and in the Luxury version more standard equipment than you could throw a stick at which is one of the things that sets it apart from the competition.
In fact if you had to add what the Staria comes with as standard to the VW, Mercedes-Benz and Toyota offerings it would be well over the R1-million mark.
Even with 11 seats, with USB ports and cup holders in every row, there's a lot of leg space and if you aren't using the rear seats they fold down to give you ample luggage space for a family holiday.
In a vehicle that size you would think that noise, vibration and harshness (NVH) levels would be relatively high especially at speed, but they have done a brilliant sound dampening job including some nifty aerodynamic devices which also aids consumption.
The steering wheel is rake and reach adjustable and once you've positioned yourself comfortably behind the wheel the big bus moves along with ease with the gears shifting silently while it gets up to speed.
There's virtually no turbo lag on take off and when you stomp the throttle to pass slower traffic it rewards you with decent get up and go.
It handles corners remarkably well for its size given that its intention was never to take on the twisties at speed.
And while it's loaded with connectivity, including a wireless charger, tech and safety features we found an unexpected bonus when putting on the indicators. Cameras mounted on the side mirrors feed a picture to the instrument cluster giving you a view of what's happening behind you. So when you pass a car you don't have to look at the mirror, the camera indicates exactly where you and the slower car are before you return to your lane.
As the replacement for the H1, the Staria ushers in a completely new look and feel in the segment and I reckon Hyundai have a winner here.
It comes with a seven year/200 000km manufacturer warranty, a seven year/105 000km service plan for the Luxury model and a six year/90 000km service plan for the Executive & Elite versions, and all have a seven year/150 000km roadside assistance plan.
Hyundai Staria Pricing
R2.2 Executive 9-seater auto - R789 900
R2.2 Executive 11-seater auto - R799 900
R2.2 Elite 9-seater auto - R959 900
R2.2 Luxury 9-seater auto - R1 099 900
Car ReviewsHyundaiLuxury Cars
Highs, lows and sweet victory for Toyota Gazoo Racing at 2022 Dakar

redpajama_set_name: RedPajamaCommonCrawl


text:
Early Weeks at College Critical to Student Safety
Parents You Can Still Make A Difference
College students will arrive or commute to campus this fall to learn, experience new friendships, and make memories that will last a lifetime. Unfortunately, it can also be a time of harmful and underage drinking and dealing with its aftermath. Among college students who drank during the past year, 32.0% did something they later regretted, 26.9% forgot where they were or what they did, 20.4% had unprotected sex, and 12.1% injured themselves (American College Health Association, National College Health Assessment, Fall 2017).
The first six (6) weeks of freshman year are a vulnerable time for harmful and underage college drinking and its consequences because of student expectations and social pressures at the start of the academic year. Research shows that students who abstain from drinking often do so because their parents discussed alcohol use and its adverse consequences with them. Massapequa Takes Action Coalition reminds parents to stay involved during these crucial early weeks:
· Talk with your young adult about the dangers of harmful and underage college drinking—such as the penalties for underage drinking, and how alcohol use can lead to sexual and other violence, as well as academic failure and other adverse consequences;
· Reach out periodically and keep the lines of communication open and stay alert for possible alcohol-related problems;
· Remind your child to feel free to reach out to you and share information about their daily activities, and to ask for help if needed;
· Learn about the school's alcohol prevention and emergency intervention efforts; and
· Make sure students know the signs of alcohol overdose or an alcohol-related problem, and how to help.
The most recent statistics from the National Institute on Alcohol Abuse and Alcoholism (NIAAA) indicate that drinking by college students ages 18 to 24 contributes to an estimated 1,519 student deaths each year. In addition, there are an estimated 696,000 assaults by another student who has been drinking and 97,000 cases of sexual assault or date rape each year.
For parents who want to discuss the consequences of college drinking with their sons and daughters, resources are available at www.CollegeDrinkingPrevention.gov. Additional parent communication and prevention tips can be found at mtacoalition.com or Like MTAC on Facebook!
For more information about MTAC's strategies to reduce underage drinking and youth substance misuse and how to be a part of the solution, contact Cathy Samuels, MTAC Project Director at (516) 799-3000 x 131 or email at info@mtacoalition.com.
You can also like MTAC on Facebook!


Historic Antioch A.M.E. Church, in partnership with Georgia Humanities, the Center for Public History at the University of West Georgia, and Agnes Scott College, will offer a History Day for the general public in an effort to collect and preserve the history of the church, a cultural icon. The event will take place on Saturday, July 16, 2016, from 8:30 a.m. to 2 p.m. at Antioch A.M.E. in Stone Mountain.
Established in 1868, Antioch was the first church founded by African Americans in Decatur, Georgia, following the Civil War. Despite the church's importance to the history of Decatur and Stone Mountain, where it now operates, its history has not been fully preserved. The History Day, made possible by a grant from Georgia Humanities, is an important step in collecting and saving the church's past. The day's programming will also offer an opportunity to learn how to research and preserve history for anyone interested.
All events of the day are open to the public. Programming will begin with breakfast served at 8:30 a.m. Participants are then invited to attend expert-led workshops at 9 a.m. on African American genealogy and at 10:30 a.m. on preserving family photographs, documents, and heirlooms. In addition, a "History Harvest" will run from 9 a.m. to 1 p.m., in which members and others with a connection to the church are encouraged to bring personal photographs and documents related to Antioch to be scanned. These items will be used to build a digital archive of church history, hosted by the Center for Public History at the University of West Georgia. Lunch will be served at 11:30 a.m., and UWG Professor Larry Rivers will end the day with a talk at 1 p.m. on the history of the A.M.E. Church, with a focus on the local history of Antioch.
The A.M.E. Church is located at 765 South Hairston Road, Stone Mountain, Georgia, 30088. More information is available at http://antiochamehistory.org. The History Day is free and open to the public, but space is limited. Therefore, the public is encouraged, but not required, to RSVP by July 10 via Eventbrite--http://antiochhistoryday.eventbrite.com--or by calling 678-893-6141.


CRC has an office behind the AICC Hospital, on a road opposite the Kibo Palace Hotel. Click here for the map to the office.
CRC is registered as a non-profit organization in Tanzania and in the United States. We rely on contributions from our members as well as in-kind and cash donations from supporting individuals and organizations both locally and internationally.
Stay up to date with us by liking our Facebook page here!
Tanzania presents some excellent opportunities for research in many fields. It is important to understand all the procedures required to obtain permission to live and work in Tanzania – have a look at our overview of research application procedures.
The Centre offers a place to work for members (including Internet and printing facilities), hosts training programmes, and assists researchers in applying for their research permits.
'How-to' information on administrative issues in Tanzania.
Online journal access and searching.
Karibu to Tanzania Conservation Resource Centre.
Hi Richard – this made me realise we don't have our contact details on the webpage! Putting them up now and look forward to hearing from you.
…and it's just to meet up at the offices. Or you could send Dassa an email beforehand and have her arrange for a taxi to pick you up (at your expense 🙂 ). You are of course also welcome to write an email with mroe details on your project so that we can give you more focused advices.


text:
Q: Pattern attribute for Email validation is not working in html5 Using Html5 I've a view which contains an email input field.
So to validate the correct email address I am using pattern attribute for validation.
But that is not working correctly, the problem I am facing here is though I enter invalid email address as abc@gmail the validation is not working.
i tested the same regex pattern in fiddler, it is working fine there, but coming to my application it is not working correctly. Please help me out with this.
Here is my view:

<form>

  <input type="email"
    class="form-control"
    data-val="true"
    data-val-required="please enter an email address"
    pattern="[a-z0-9._%+-]+@[a-z0-9.-]+.[a-z]{2,4}$"
    required>

  <input type="submit" />
</form>

A: Regex should be

[a-z0-9._%+-]+@[a-z0-9.-]+.[a-z]{2,}$
instead of

[a-z0-9._%+-]+@[a-z0-9.-]+.[a-z]{2,4}$
So the html input would be:
<input type="email"
   class="form-control"
   data-val="true"
   data-val-required="please enter an email address"
   pattern="[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$"
   required>

NOTE: difference in regex is {2,} and {2,4}


text:
100 Heroes
100 Heroes: Harmen van den Bogaert
The gay man who helped establish New York City.
It was about 1832 when Harmen van den Bogaert arrived in the settlement that was then known as New Amsterdam. He was 18 at the time.
At this time, New Amsterdam was a trading outpost of the Dutch empire. Beaver pelts were the main product of the Hudson River region, traded with the people of the Mohawk nation.
According to the limited information about the life of van den Bogaert, he'd arrived into New Amsterdam on the ship the Unity — on the ship's passenger manifest he was listed as a barber-surgeon.
Van den Bogaert held a farm on the island of Manhattan. He served as supply master to the Dutch West India Company - the trading firm that ran New Amsterdam at that time.
As well as beaver pelts, one of the most valuable commodities traded by the Dutch West India Company was slaves — transported from Africa to New Amsterdam and the other colonies of North America. Harmen van den Bogaert owned a slave — his name was Tobias.
In 1634, van den Bogaert was somehow discovered having sex with Tobias. At this time, homosexuality was illegal throughout the Dutch empire — the punishment was death.
Escaping prosecution and certain death, van den Bogaert and Tobias fled New Amsterdam and travelled into lands controlled by the Mohawk nation. They were pursued by a bounty hunter from New Amsterdam, Hans Vos. Vos tracked van den Bogaert and Tobias down in a village of the Mohawk people, took them prisoner, and took them back to Fort Orange — the fortified trading post on the Hudson River.
Ahead of their impending trial, van den Bogaert and Tobias escaped from their cell in Fort Orange and made a bid for freedom by crossing the frozen Hudson River. While they were attempting to cross, van den Bogaert fell through the ice and drowned, Tobias was recaptured. The fate of Tobias is unknown, although it's likely that he was killed.
It's sometimes misleading to view historical events through a contemporary lens. There may have been other factors at play that led to van den Bogaert falling foul of the Dutch West India Company — for instance, there are some suggestions that van den Bogaert had links to privateers in the Caribbean. But, from the information we have available, it seems that the authorities of New Amsterdam successfully used van den Bogaert's homosexuality against him — persecuting him and his lover to their death as a punishment for being gay men.
New York City would not be the city that we know today if not for adventurers, entrepreneurs, and lovers like Harmen van den Bogaert and Tobias - gay men who helped shape history.
Follow Gareth Johnson on Twitter


text:
Claris Update Webinar 2023, January 25, 2023
Claris Corporate Announcements
RosemaryTietge January 12, 2023, 8:10pm #1
Hear our developer-focused strategy for growth.
Join Brad Freitag, Claris CEO, and other Claris leaders who will share Claris' vision and upcoming release plans for the platform as well as developer-focused strategy for growth. Leave this webinar knowing how Claris will support your business and career for the decades to come.
In this webinar:
Learn Claris vision, developer-centric strategy, and platform priorities.
Understand why we've made platform investments and how you'll benefit from them.
Stay in the know as we share our progress and get set for the future.
Plan your journey with the new Claris platform.
Wednesday, January 25, 2023 (45-minute presentation)
9:00 a.m. PT, 12:00 p.m. ET, 5:00 p.m. GMT
Register >
4:00 p.m. PT (7:00 p.m. ET) January 26, 11:00 a.m. AEDT
We will record this webinar and share it after the events.


The Lite bookkeeping Package is perfect for start ups and/or small business owners who do not require a payroll service and who like to lodge their own Business Activity Statements.
Get started now! $352/mth Subscribe securely with PayPal.
Welcome Pack – everything you need to get started with us including a detailed description of our services and all contact details (and a special gift).
Set up your data file (electronic accounting file) including a new Chart of Accounts (or use one prepared by your accountant). You choose your preferred software from Xero, Saasu, QuickBooks Online, Reckon and/or MYOB.
We send you a "Data We Need" list before we process your accounts (either monthly or quarterly) to keep you organised. You'll always know what you need to collect for us – just one way we can make things easier for you!
All data entry to your accounting file is included – bank statement data, credit card statement data, cash receipts, payroll data (previously prepared by you), sales receipts, supplier receipts and anything else you need. Best of all, we will enter data to up to 4 different bank accounts. If you have more than 4 bank accounts, get in touch to discuss and we'll advise of any extra costs.
Once your data is entered to your accounting file, then we will reconcile your accounts. This means that we will make sure that your data matches your bank statements and make sure there aren't any errors.
After the reconciliation process is complete, we will process management reports for your company. These reports include a detailed profit and loss and balance sheet and a trial balance for your accountant. You will also receive accounts payable and receivable reports so you will always know how much your customers owe you and how much you need to pay to your suppliers.
Monthly or quarterly accounts meeting – at e-BAS Accounts we believe it is extremely important to meet with our clients regularly so that all issues relating to their bookkeeping can be discussed. This ensures that nothing falls through the cracks – we can bring issues to your attention and you can ask about anything you don't understand or ask for changes to be made etc. We like to keep the lines of communication open! Meetings can be held in person (if practicable) but are usually held electronically via video conferencing platforms.
Year End Reports – your data file is given an annual health check and all required reports are raised and sent to your accountant. The type or number of reports raised will be totally dependant on your accountant's needs. You will be provided with copies of all year-end reports also.
Liaising with your accountant – at e-BAS Accounts we believe that not only is it important to communicate with you regularly but that it is also important to communicate with your accountant or tax agent. We will "meet" with your accountant as often as required on your behalf via face-to-face meeting (if possible), email, telephone, written correspondence or via video conferencing. You will always be involved in all communications with your accountant and will be asked for permission to do so before any contact is made.
Back Ups – in this day and age of "everything electronic", nothing is more important than backing up data. There is nothing worse than losing data due to hard drive failure, computers being compromised by viruses, computers being stolen, files being deleted accidentally, files becoming corrupted etc. There is something worse actually – not having a back up of your data! At e-BAS Accounts we back up your data on a daily basis. You don't have to worry – we've got your data covered!
Freebies! We all love free stuff don't we? Well here at e-BAS Accounts you get stuff for free – yes it's true! You will never be charged for telephone support, emails, printing or postage – that's cool! It doesn't stop there; you will also receive a free bi-monthly newsletter which is full of useful information you can use to help your run your business.


Reliance Jio is all set to disrupt the Indian feature phone market with its JioPhone Monsoon Hungama offer. Announced at the Reliance Industries Annual General Meeting on July 5, the 'JioPhone Monsoon Hungama' offer is an attractive one for the feature phone users as they get the good old JioPhone at just Rs 501 by exchanging their current feature phone. With this offer, Jio wants to turn its JioPhone user base to 100 million from the current 25 million, and it could become a reality in the coming days. "With as many as 500 million Indians still using feature phones with no access to the Internet, the doors of Digital Life are closed to them mainly because of the problem of affordability," said Jio while revealing the details of the offer.
Here are the five must know things about the JioPhone Monsoon Hungama offer which is slated to start at 5:01 PM on July 20, 2018.
To make things interesting, Jio will be starting the offer on July 20, 2018, and that too at 5:01 PM, which coincides the Rs 501 price tag of the JioPhone after the exchange. "Starting, 5:01 PM July 20, 2018, customers will be able to exchange any old feature phone (of any brand) for a brand new JioPhone (existing model) at an effective entry cost of only Rs 501," said Jio in a press statement.
There has been a lot of confusion amongst users regarding which feature phone will Jio offer them after exchanging their existing feature phone. Jio will be providing the user with the first generation JioPhone and not the newly launched JioPhone 2. The Reliance JioPhone 2 will be sold sometime later in August.
After exchanging the feature phone for the new JioPhone, users can either choose the Rs 49 or Rs 153 JioPhone recharge plan to enjoy the 4G services on Jio network. The Rs 49 plan is the most affordable plan right now as it gives a user 1GB of 4G data and unlimited voice calling for 28 days. The Rs 153 tariff plan, on the other hand, offers 1.5GB data benefit per day, unlimited voice and 100 SMS per day for 28 days.
Reliance Jio also announced that the three major applications WhatsApp, Facebook, and YouTube are coming to JioPhone and JioPhone 2 only on August 15. Existing users can download the apps from the KaiOS Store which comes preloaded on JioPhones. If you're assuming that you can use WhatsApp on JioPhone right after the purchase, then you're wrong.