Combination description of uni-push2.0, uni-id, uni statistics

Included opendb tables

Data Table Name	Operation (Add/Update) Timing	Content/Action
opendb-tempdata	When the old token expires	The token that initiates the request to the push server
opendb-device	Device startup, login	push_clientid and detailed device information
uni-id-device	Login	It is mainly used to store the mapping relationship between user_id and device_id, complete fields: user_id, device_id, token_expired, push_clientid, appid

Details:

1. uni statistics module, call getPushClientId to get push_clientid immediately when the device starts up, if the acquisition is successful ( If the application does not enable uni-push2.0 in the manifest, the acquisition will fail), then call the report method of the uni-stat-receiver cloud object (parameter: push_clientid), and the server will write to the opendb-device table Push or update (when present): device info and push_clientid.

2. The uni-id-pages plugin, call uniCloud.onRefreshToken to monitor token changes (ie: user login and When the token is renewed), call the setPushCid method of the uni-id-co cloud object (parameter: push_clientid). The server operates the uni-id-device table and records the mapping relationship between device_id and user_id ; The full field contains user_id, device_id, token_expired, push_clientid, appid. At the same time, write or update to the opendb-device table (if it exists): device info and push_clientid.

To sum up: push_clientid is stored in two tables, uni-id-device and opendb-device, the former is used to store the mapping relationship between device_id and user_id, and the corresponding data is only available after the user logs in successfully ; The latter is used to store complete device information, and users who are not logged in also have corresponding data.

Notice: When the user is not logged in, we can push a message to the user based on device_id, but there is a risk of being eavesdropped (marketing messages don't care too much about this). Because of the device information stored in the opendb-device table, the underlying technical principle is to obtain the information automatically reported by the client, and theoretically it may be tampered with. For example: Zhang San uses Li Si's device_id + Zhang San's push_clientid. Report the data; the server will think that Li Si's push_clientid has been updated, so that the mapping relationship between Li Si's device_id and push_clientid points to Zhang San's push_clientid; Zhang San then eavesdropped on it, and others sent it to Li Four news. The push message based on user_id or user_tag is based on the uni-id-device table. When adding/updating operations: the user_id of the current user will be verified and will not be tampered by other users, that is, no Risk of being eavesdropped on by others.

device info

Source this.getClientInfo method in the uniCloud cloud object, complete field list reference: [uni.getSystemInfo](https 😕/uniapp.dcloud.net.cn/api/system/info.html#getsysteminfo)

Push API to check library details:

• The push target basis is: push_clientid directly executes the push.
• The push target is based on: device_id, check the opendb-device table, get the push_clientid to execute the push
• The push target basis is: users_id check the uni-id-device table (if you need to verify the platform, check the opendb-device table), get the push_clientid to execute the push
• The push target basis is: user_tag check uni-id-users table, get users_id check uni-id-device table (if you need to verify the platform, check opendb-device table jointly), get push_clientid performs push