Merge pull request #281 from wultra/develop

Prepare release 0.23.0

.travis.yml

@@ -1,24 +1,24 @@
 language: java
 jdk:
-  - oraclejdk8
+  - openjdk11
+script: mvn -DskipTests=true clean package
 branches:
   only:
     - master
+    - coverity_scan
 env:
   global:
-  - secure: "HdkS3LONKdXYlW83TLwobYK+YIZBujkG8JuEyfSlueFEwYZ2Pk0GmQZP4Q5b50w4VqE1tnAvHmSg4q/ShP+NreH0EzBdnwFaUV+pts0mdwqk50g6JqQE8dbj2AU4wPrkungW9E1xWH6iuxQJbQnJCtgqGMfXHPpML5/0XLJtie7/T+1rTJE9zDTct+IRk1s4aYjEMWm5Bkm4A+BDYAEwfoeesgQ1Qj46+FSLVFnO28x0RkSy/Ucq1SBolTCxw6X4Q9cMCpmkQ5kQj3cdSf968WQJazECzzY0Ev9sv1NfZCYhV5nb9zlIt0CMbcbogUA+rBAg0Vw/TdMz3y8UM5b7CU9TG90WvB8psA++d26XOVRz42oBkXwh6rO/yUdAaDEzTRzgjE1ESOBJSpcr3pjSGWb6DJgW2lNW6JjmBGmOqSsmBHVa3VGAXlxvS/aUHU/LH/oC7YkNf2jhjl+M1fZwt+mQO5QhFBhS2BB+VnFPMPFpyJcwdZJI6DJzXPSj7LFdYtjI7F68+s2a7lgzVtSL3vXVq2cD+qQP4AjR7Ekd05+1SBHLvaCsktrZJ6lcmKQUwyTGYel7uzmL6et9vZ1eS5b3u5YSeKNmxwcJ0XPBduh1n+NQX1vtpNSgJX4dSplmFn3grO4ujDptyFoyC4Qc8OGQWTAav+m14+OcKPPUZCI="
+    - secure: "hUmHJZJmFBXV8j8SCVOEWGTcRlqAcllfWDwXz+owY5cWIOtDRvMrZXOvgupRsAHzRL7BUAsKo8k7/eqeZVfjO+zSlYLr3/06krCv5T/8GQTwHv3nTNq3r03GLZpYypuUapfUFCCVQchafWvYuNs7O5IsL1YHcRB5MjwbobARw1AezkEs+0n9kIeEofTFDZntILKXYuEO4Xa44KOzOEenxHieBeKgUpa43JFH/Qoh96qumqt3US+F4raHTwDG8KgNKc7bEzMdGxZ8MrfwljZP0teuc6B6/mPsIh8ZNdWTnsxq04M6Qe3fvCrkyUOyHZsAVA0xoSK2pTuMkAQOF0c9tLYcs1aOg4gM/tOsbgQa8iS5loC+zxPo5UgixIwGg/QxnQTHZLrOTCpsQqGbtqK5qTP/2v6FXKOUQ8tnvth8DQpsyI/FUKe0KEZYs5WSen5anXIkWE7fITlVUXaUvNAILIzM2nAdaYnhdnyUaVNfjvIVIwiciEzBL7FiuZnVRcfGaX2HTqp9embnFW43kpkSypvDUwaBFhsLDLVgr6xyurYwdWD6Ot+gwN6BMT8ajPnqSRTtiesdYGOu+uQ5AnwkRpeD87r6C1yHTAeyMlPVpVoslpw6cocEWlBNOR4oMwHoqcV9/ygjHdHBnZeWO7oEoJtds1oY6WmFzZM2TuToPbk="
 
 before_install:
-  - echo -n | openssl s_client -connect scan.coverity.com:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | sudo tee -a /etc/ssl/certs/ca-
-
-script: mvn clean package -DskipTests=true
+  - echo -n | openssl s_client -connect https://scan.coverity.com:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | sudo tee -a /etc/ssl/certs/ca-
 
 addons:
   coverity_scan:
     project:
-      name: lime-company/powerauth-push-server
-      description: Build submitted via Travis CI
-    notification_email: petr@wultra.com
-    build_command_prepend: mvn clean
-    build_command: mvn compile -DskipTests=true
-    branch_pattern: master
+      name: "wultra/powerauth-push-server"
+      description: "Build submitted via Travis CI"
+    notification_email: roman.strobl@wultra.com
+    build_command_prepend: "mvn clean"
+    build_command: "mvn -DskipTests=true compile"
+    branch_pattern: coverity_scan

docs/Deploying-Push-Server.md

@@ -60,6 +60,14 @@ You can enable storing of sent messages in database using following property:
 powerauth.push.service.message.storage.enabled=true
 ```
 
+### Enabling Multiple Associated Activations in Device Registration 
+
+You can enable registration of multiple associated activations for a push token using following property:
+
+```
+powerauth.push.service.registration.multipleActivations.enabled=true
+```
+
 ### APNS Environment Configuration
 
 In order to separate development and production environment on APNS, you may want to set following property:

docs/Migration-Instructions.md

@@ -4,3 +4,4 @@ This page contains PowerAuth Push Server migration instructions.
 
 - [PowerAuth Push Server 0.21.0](./PowerAuth-Push-Server-0.21.0.md)
 - [PowerAuth Push Server 0.22.0](./PowerAuth-Push-Server-0.22.0.md)
+- [PowerAuth Push Server 0.23.0](./PowerAuth-Push-Server-0.23.0.md)

docs/PowerAuth-Push-Server-0.23.0.md

@@ -0,0 +1,45 @@
+# Migration from 0.22.0 to 0.23.0
+
+## Database changes
+
+Following DB changes occurred between version 0.22.0 and 0.23.0:
+- Added unique index (`activationId`, `push_token`) in table `push_device_registration`
+- The existing `push_device_activation` index in table `push_device_registration` was changed to unique
+
+The DDL script for Oracle:
+```sql
+CREATE UNIQUE INDEX PUSH_DEVICE_ACTIVATION_TOKEN ON PUSH_DEVICE_REGISTRATION(ACTIVATION_ID, PUSH_TOKEN);
+
+DROP INDEX PUSH_DEVICE_ACTIVATION;
+CREATE UNIQUE INDEX PUSH_DEVICE_ACTIVATION ON PUSH_DEVICE_REGISTRATION(ACTIVATION_ID);
+```
+
+The DDL script for MySQL:
+```sql
+CREATE UNIQUE INDEX `push_device_activation_token` ON `push_device_registration`(`activation_id`, `push_token`);
+
+DROP INDEX `push_device_activation` ON `push_device_registration`;
+CREATE UNIQUE INDEX `push_device_activation` ON `push_device_registration`(`activation_id`);
+```
+
+In case either of the index updates fails, delete existing duplicate rows. Rows with newest timestamp_last_registered should be preserved.
+
+## Device Registration Changes
+
+Following changes of device registration have been applied in release `0.23.0`:
+- A device can no longer be registered with the same `activationId` and multiple related `pushtoken` values. 
+This change was introduced because Google and Apple do not always expire existing push tokens. When the device
+receives a new push token, the device registration endpoint updates the `pushtoken` value for an existing activation instead of
+creating a new device registration. Thus the old push token is removed from database.
+- It is no longer possible to register a device without associated activation. The `activationId` parameter must be
+always sent with device registration request.
+- It is possible to re-register a device with same `activationId` and `pushtoken`. The registration timestamp is updated in this case. 
+- It is possible to register a device with multiple `activationIds` associated with a single `pushtoken`. Such 
+device registration must be initiated using the new endpoint created for this use case: 
+[Create Device for Multiple Associated Activations](./Push-Server-API.md#create-device-for-multiple-associated-activations).
+Multiple activations are used in master-child activation schemes. The functionality needs to be enabled
+using a configuration property [for enabling multiple activations](./Deploying-Push-Server.md#enabling-multiple-associated-activations-in-device-registration),
+because it is less secure than the case when a single associated activation is allowed for a push token.
+- Database indexes are now applied to enforce database consistency for device registrations:
+  - The (`activationId`) value must be unique in the device registration table. Each `activationId` must have exactly one associated `pushtoken`. 
+  - The (`activationId`, `pushtoken`) combination must be unique in the device registration table.

docs/Push-Server-API.md

@@ -8,7 +8,7 @@ Push Server provides a simple to use RESTful API for the 3rd party integration p
 - [Campaign](#campaign)
 - [Administration](#administration)
 
-Following endpoints are published in PowerAuth 2.0 Push Server RESTful API:
+Following endpoints are published in PowerAuth Push Server RESTful API:
 
 ## Methods
 
@@ -26,6 +26,7 @@ Following endpoints are published in PowerAuth 2.0 Push Server RESTful API:
 #### Device Management
 
 - `POST` [/push/device/create](#create-device) - Create new device registration
+- `POST` [/push/device/create/multi](#create-device-for-multiple-associated-activations) - Create new device registration for multiple activations
 - `POST` [/push/device/delete](#delete-device) - Remove registered device
 - `POST` [/push/device/status/update](#update-device-status) - Update the status of the activation so that when activation associated with given device is not active, no notifications are sent to the device.
 
@@ -66,15 +67,15 @@ Following endpoints are published in PowerAuth 2.0 Push Server RESTful API:
 
 ### Error Handling
 
-PowerAuth 2.0 Push Server uses following format for error response body, accompanied with an appropriate HTTP status code. Besides the HTTP error codes that application server may return regardless of server application (such as 404 when resource is not found or 503 when server is down), following status codes may be returned:
+PowerAuth Push Server uses following format for error response body, accompanied with an appropriate HTTP status code. Besides the HTTP error codes that application server may return regardless of server application (such as 404 when resource is not found or 503 when server is down), following status codes may be returned:
 
 |`status`|`HTTP code`       |Description|
 |---     |---          |---|
 |OK      |200          |No issue|
 |ERROR   |400          |Issue with a request format, or issue of the business logic|
 |ERROR   |401          | Unauthorized, invalid security token configuration|
 
-All error responses that are produced by the PowerAuth 2.0 Push Server have following body:
+All error responses that are produced by the PowerAuth Push Server have following body:
 
 ```json
 
@@ -118,7 +119,7 @@ Send a system status response, with basic information about the running applicat
     "status": "OK",
     "responseObject": {
         "applicationName": "powerauth-push",
-        "applicationDisplayName": "PowerAuth 2.0 Push Server",
+        "applicationDisplayName": "PowerAuth Push Server",
         "applicationEnvironment": "",
         "version": "0.21.0",
         "buildTime": "2019-01-22T14:59:14.954+0000",
@@ -141,9 +142,9 @@ Then it has to forward the push token to the push server end-point. After that p
 
 ### Create Device
 
-Create a new device push token (platform specific). Optionally, the call may include also `activationId`, so that the token is associated with given user in the PowerAuth 2.0 Server.
+Create a new device push token (platform specific). The call must include `activationId`, so that the token is associated with given user in the PowerAuth Server.
 
-_Note: Since this endpoint is usually called by the back-end service, it is not secured in any way. It's the service that calls this endpoint responsibility to assure that the device is somehow authenticated before the push token is assigned with given activationId value, so that there are no incorrect bindings._
+_Note: Since this endpoint is usually called by the back-end service, it is not secured in any way. It's the service that calls this endpoint responsibility to assure that the device is somehow authenticated before the push token is assigned with given activation ID, so that there are no incorrect bindings._
 
 <table>
 <tr>
@@ -174,7 +175,51 @@ _Note: Since this endpoint is usually called by the back-end service, it is not
 - `platform` - "_ios_ | _android_"
 - `activationId` - Activation identifier
 
-_Note: Activation ID is optional._
+#### **Response**
+
+```json
+{
+    "status": "OK"
+}
+```
+
+### Create Device for Multiple Associated Activations
+
+Create a new device push token (platform specific). The call must include `activationIds` which contains list of activations to be associated with the registered device.
+
+_Note: Since this endpoint is usually called by the back-end service, it is not secured in any way. It's the service that calls this endpoint responsibility to assure that the device is somehow authenticated before the push token is assigned with given activation IDs, so that there are no incorrect bindings._
+
+<table>
+<tr>
+<td>Method</td>
+<td><code>POST</code></td>
+</tr>
+<tr>
+<td>Resource URI</td>
+<td>/push/device/create/multi</td>
+</tr>
+</table>
+
+#### **Request**
+
+```json
+{
+    "requestObject": {
+        "appId": 2,
+        "token": "1234567890987654321234567890",
+        "platform": "ios",
+        "activationIds": [
+          "49414e31-f3df-4cea-87e6-f214ca3b8412",
+          "26c94bf8-f594-4bd8-9c51-93449926b644"
+        ]
+    }
+}
+```
+
+- `appId` - Application that device is using.
+- `token` - Identifier for device.
+- `platform` - "_ios_ | _android_"
+- `activationIds` - Associated activation identifiers
 
 #### **Response**
 

docs/Push-Server-Database.md

@@ -14,27 +14,26 @@ You can download DDL scripts for supported databases:
 - [Push messages](#push-messages-table)
 - [Push campaigns](#push-campaigns-table)
 - [Push campaign users](#push-campaign-users-table)
-- [Push campaign devices](#push-campaign-devices-table)
 
 ### Push Devices Table
 
 
-**Table name**: `push_device`
+**Table name**: `push_device_registration`
 
 **Purpose**: Stores push tokens specific for a given device.
 
 **Columns**:
 
 | Name | Type | Info | Note |
 |---|---|---|---|
-| id | BIGINT(20) | primary key, index, autoincrement | Unique device registration ID. |
-| activation_id | VARCHAR(37) | index | Application name, for example "Mobile Banking". |
-| user_id | BIGINT(20) | index | Associated user ID |
-| app_id | BIGINT(20) | index | Associated application ID |
-| platform | VARCHAR(30) | - | Mobile OS Platform ("ios", "android") |
-| push_token | VARCHAR(255) | - | Push token associated with a given device. Type of the token is determined by the `platform` column. |
-| timestamp_created | TIMESTAMP | - | Timestamp of the last device registration. |
-| is_active | INT(11) | - | PowerAuth 2.0 activation status (boolean), used as an activation status cache so that communication with PowerAuth 2.0 Server can be minimal. |
+| `id` | BIGINT(20) | primary key, index, autoincrement | Unique device registration ID. |
+| `activation_id` | VARCHAR(37) | index | Activation ID associated with given push token record. |
+| `user_id` | BIGINT(20) | index | Associated user ID. |
+| `app_id` | BIGINT(20) | index | Associated application ID. |
+| `platform` | VARCHAR(30) | - | Mobile OS Platform ("ios", "android"). |
+| `push_token` | VARCHAR(255) | - | Push token associated with a given device. Type of the token is determined by the `platform` column. |
+| `timestamp_last_registered` | TIMESTAMP | - | Timestamp of the last device registration. |
+| `is_active` | INT(11) | - | PowerAuth activation status (boolean), used as an activation status cache so that communication with PowerAuth Server can be minimal. |
 
 ### Push Service Credentials Table
 
@@ -47,7 +46,7 @@ You can download DDL scripts for supported databases:
 | Name | Type | Info | Note |
 |---|---|---|---|
 | id | BIGINT(20) | primary key, index, autoincrement | Unique credential record ID. |
-| app_id | BIGINT(20) | index | Associated application ID |
+| app_id | BIGINT(20) | index | Associated application ID. |
 | ios_key_id | VARCHAR(255) | - | Key ID used for identifying a private key in APNs service. |
 | ios_private_key | BLOB | - | Binary representation of P8 file with private key used for Apple's APNs service. |
 | ios_team_id | VARCHAR(255) | - | Team ID used for sending push notifications. |
@@ -68,12 +67,12 @@ You can download DDL scripts for supported databases:
 | id | BIGINT(20) | primary key, index, autoincrement | Unique message record ID. |
 | device_registration_id | INT | index | Associated device registration (device that is used to receive the message), for the purpose of resend on fail operation. |
 | user_id | BIGINT(20) | index | Associated user ID. |
-| activation_id | VARCHAR(37) | index | PowerAuth 2.0 activation ID. |
-| silent | INT | - | Flag indicating if the message was "silent" (0 = NO, 1 = YES) |
-| personal | INT | - | Flag indicating if the message was "personal" - sent only on active devices (0 = NO, 1 = YES) |
+| activation_id | VARCHAR(37) | index | PowerAuth activation ID. |
+| is_silent | INT | - | Flag indicating if the message was "silent" (0 = NO, 1 = YES). |
+| is_personal | INT | - | Flag indicating if the message was "personal" - sent only on active devices (0 = NO, 1 = YES). |
 | message_body | TEXT | - | Payload of the message in a unified server format. This format is later translated in a platform specific payload. |
 | timestamp_created | TIMESTAMP | - | Date and time when the record was created. |
-| status | INT | - | Value indicating message send status. (-1 = FAILED, 0 = PENDING, 1 = SENT) |
+| status | INT | - | Value indicating message send status. (-1 = FAILED, 0 = PENDING, 1 = SENT). |
 
 ### Push Campaigns Table
 
@@ -86,11 +85,12 @@ You can download DDL scripts for supported databases:
 | Name | Type | Info | Note |
 |---|---|---|---|
 | id | BIGINT(20) | primary key, index, autoincrement | Unique campaign record ID. |
-| appid | BIGINT(20) | index | Associated Application identifier |
-| message | TEXT | - | Certain notification that is written in unified format |
-| sent| INT(1) | - | Flag indicating if campaign was successfully sent |
-| timestamp_created | TIMESTAMP | - | Timestamp of campaign creation |
-| timestamp_sent | TIMESTAMP | - | Timestamp of campaign successful sending |
+| appid | BIGINT(20) | index | Associated Application identifier. |
+| message | TEXT | - | Certain notification that is written in unified format. |
+| sent| INT(1) | - | Flag indicating if campaign was successfully sent. |
+| timestamp_created | TIMESTAMP | - | Timestamp of campaign creation. |
+| timestamp_sent | TIMESTAMP | - | Timestamp of campaign sending initiation. |
+| timestamp_completed | TIMESTAMP | - | Timestamp of campaign successful sending (all messages sent). |
 
 ### Push Campaign Users Table
 
@@ -102,24 +102,7 @@ You can download DDL scripts for supported databases:
 
 | Name | Type | Info | Note |
 |---|---|---|---|
-| id | BIGINT(20) | primary key, index, autoincrement | Unique user ID |
-| campaign_id | BIGINT(20) | index | Identifier of campaign that is user related to |
-| user_id | BIGINT(20) | index | Identifier of user, can occur multiple times in different campaigns |
-| timestamp_created | TIMESTAMP | - | Timestamp of user creation |
-
-### Push Campaign Devices Table
-
-**Table name**: `push_campaign_device`
-
-**Purpose**: Stores devices related to certain campaign to ensure that each device will receive only one message
-
-**Columns**:
-
-| Name | Type | Info | Note |
-|---|---|---|---|
-| id | BIGINT(20) | primary key, index, autoincrement | Unique device ID |
-| campaign_id | BIGINT(20) | index | Identifier of campaign that is device related to |
-| platform | VARCHAR(20) | - | Platform that is device running on |
-| token | VARCHAR(255) | - | Push token associated with a given device |
-| status | INT(11) | - | Status used in concurrent sending. States: sent, sending, failed |
-| timestamp_created | TIMESTAMP | - | Timestamp of device creation |
+| id | BIGINT(20) | primary key, index, autoincrement | Unique user ID. |
+| campaign_id | BIGINT(20) | index | Identifier of campaign that is user related to. |
+| user_id | BIGINT(20) | index | Identifier of user, can occur multiple times in different campaigns. |
+| timestamp_created | TIMESTAMP | - | Timestamp of user creation (assignment to the campaign). |

docs/sql/mysql/create_push_server_schema.sql

@@ -62,7 +62,8 @@ CREATE UNIQUE INDEX `push_app_cred_app` ON `push_app_credentials`(`app_id`);
 
 CREATE INDEX `push_device_app_token` ON `push_device_registration`(`app_id`, `push_token`);
 CREATE INDEX `push_device_user_app` ON `push_device_registration`(`user_id`, `app_id`);
-CREATE INDEX `push_device_activation` ON `push_device_registration`(`activation_id`);
+CREATE UNIQUE INDEX `push_device_activation` ON `push_device_registration`(`activation_id`);
+CREATE UNIQUE INDEX `push_device_activation_token` ON `push_device_registration`(`activation_id`, `push_token`);
 
 CREATE INDEX `push_message_status` ON `push_message`(`status`);
 

docs/sql/oracle/create_push_server_schema.sql

@@ -66,7 +66,8 @@ CREATE UNIQUE INDEX PUSH_APP_CRED_APP ON PUSH_APP_CREDENTIALS(APP_ID);
 
 CREATE INDEX PUSH_DEVICE_APP_TOKEN ON PUSH_DEVICE_REGISTRATION(APP_ID, PUSH_TOKEN);
 CREATE INDEX PUSH_DEVICE_USER_APP ON PUSH_DEVICE_REGISTRATION(USER_ID, APP_ID);
-CREATE INDEX PUSH_DEVICE_ACTIVATION ON PUSH_DEVICE_REGISTRATION(ACTIVATION_ID);
+CREATE UNIQUE INDEX PUSH_DEVICE_ACTIVATION ON PUSH_DEVICE_REGISTRATION(ACTIVATION_ID);
+CREATE UNIQUE INDEX PUSH_DEVICE_ACTIVATION_TOKEN ON PUSH_DEVICE_REGISTRATION(ACTIVATION_ID, PUSH_TOKEN);
 
 CREATE INDEX PUSH_MESSAGE_STATUS ON PUSH_MESSAGE(STATUS);