什么是簽名？服務(wù)器和APP之間的API接口和數(shù)據(jù)怎么保證安全

apk簽名相當(dāng)于程序的身份識(shí)別代碼。

網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)！專注于網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開(kāi)發(fā)、微信小程序定制開(kāi)發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了深圳免費(fèi)建站歡迎大家使用！

apk簽名用于程序編譯打包之后，手機(jī)在運(yùn)行程序之前會(huì)先去驗(yàn)證程序的簽名（可以看作類似于我們電腦上常說(shuō)的md5）是否合法，只有通過(guò)了驗(yàn)證的文件才會(huì)被運(yùn)行，所以簽名軟件的作用的讓文件通過(guò)手機(jī)的驗(yàn)證為合法，不同的手機(jī)、系統(tǒng)是對(duì)應(yīng)不同的簽名的。

進(jìn)行加密通訊防止API外部調(diào)用

服務(wù)器端與客戶端各自會(huì)存儲(chǔ)一個(gè)TOKEN,這個(gè)TOKEN我們?yōu)榱朔乐狗淳幾g是用C語(yǔ)言來(lái)寫(xiě)的一個(gè)文件并做了加殼和混淆處理。

在客戶端訪問(wèn)服務(wù)器API任何一個(gè)接口的時(shí)候，客戶端需要帶上一個(gè)特殊字段，這個(gè)字段就是簽名signature，簽名的生成方式為：

訪問(wèn)的接口名+時(shí)間戳+加密TOKEN 進(jìn)行整體MD5,并且客戶端將本地的時(shí)間戳作為明文參數(shù)提交到服務(wù)器

服務(wù)器首先會(huì)驗(yàn)證這兩個(gè)參數(shù)：驗(yàn)證時(shí)間戳，如果時(shí)間誤差與服務(wù)器超過(guò)正負(fù)一分鐘，服務(wù)器會(huì)拒絕訪問(wèn)(防止被抓包重復(fù)請(qǐng)求服務(wù)器，正負(fù)一分鐘是防止時(shí)間誤差，參數(shù)可調(diào)整)，

然后服務(wù)器會(huì)根據(jù)請(qǐng)求的API地址和提交過(guò)來(lái)的時(shí)間戳再加上本地存儲(chǔ)的token按照MD5重新生成一個(gè)簽名，并比對(duì)簽名，簽名一致才會(huì)通過(guò)服務(wù)器的驗(yàn)證，進(jìn)入到下一步的API邏輯

怎么保證APP和服務(wù)器端通信的安全性

用HTTPS通信，另外APP往服務(wù)器接口發(fā)送的參數(shù)帶token，還要加上簽名，服務(wù)器端驗(yàn)簽名（以防參數(shù)被篡改），校驗(yàn)token；同時(shí)加上時(shí)間戳，防止重放。（簽名算法、密鑰的分配安全存儲(chǔ)要設(shè)計(jì)好）

對(duì)服務(wù)器接口要有監(jiān)控，監(jiān)控到異常情況要有處理方案。

redis怎么解決app與服務(wù)器通信

簡(jiǎn)介

幾乎所有的主流編程語(yǔ)言都有Redis的客戶端，不考慮Redis非常流行的原因，如果站在技術(shù)的角度看原因還有兩個(gè)：

客戶端與服務(wù)端之間的通信協(xié)議是在?TCP 協(xié)議之上構(gòu)建的。

客戶端和服務(wù)器通過(guò) TCP 連接來(lái)進(jìn)行數(shù)據(jù)交互， 服務(wù)器默認(rèn)的端口號(hào)為 6379 。

客戶端和服務(wù)器發(fā)送的命令或數(shù)據(jù)一律以 \r\n （CRLF）結(jié)尾。

Redis制定了 RESP（REdis Serialization Protocol，Redis序列化協(xié)議）實(shí)現(xiàn)客戶端與服務(wù)端的正常交互，這種協(xié)議簡(jiǎn)單高效，既能夠被機(jī)器解析，又容易被人類識(shí)別。

發(fā)送命令

RESP 在 Redis 1.2 版本中引入， 并最終在 Redis 2.0 版本成為 Redis 服務(wù)器通信的標(biāo)準(zhǔn)方式。

在這個(gè)協(xié)議中， 所有發(fā)送至 Redis 服務(wù)器的參數(shù)都是二進(jìn)制安全（binary safe）的。

RESP 的規(guī)定一條命令的格式如下：

*參數(shù)數(shù)量 CR LF

$參數(shù) 1 的字節(jié)數(shù)量 CR LF

參數(shù) 1 的數(shù)據(jù) CR LF

...

$參數(shù) N 的字節(jié)數(shù)量 CR LF

參數(shù) N 的數(shù)據(jù) CR LF

命令本身也作為協(xié)議的其中一個(gè)參數(shù)來(lái)發(fā)送。

例如我們經(jīng)常執(zhí)行的 SET 命令，在命令行中我們輸入如下：

SET key value

使用 RESP 協(xié)議規(guī)定的格式：

*3

$3

SET

$3 # 這里 key 一共三個(gè)字節(jié)

key

$5 # 這里 value 一共五個(gè)字節(jié)

value

這個(gè)命令的實(shí)際協(xié)議值如下：

"*3\r\n$3\r\nSET\r\n$3\r\nkey\r\n$5\r\nvalue\r\n"

回復(fù)

Redis 命令會(huì)返回多種不同類型的回復(fù)。

通過(guò)檢查服務(wù)器發(fā)回?cái)?shù)據(jù)的第一個(gè)字節(jié)， 可以確定這個(gè)回復(fù)是什么類型：

狀態(tài)回復(fù)（status reply）的第一個(gè)字節(jié)是 "+"

錯(cuò)誤回復(fù)（error reply）的第一個(gè)字節(jié)是 "-"

整數(shù)回復(fù)（integer reply）的第一個(gè)字節(jié)是 ":"

批量回復(fù)（bulk reply）的第一個(gè)字節(jié)是 "$"

多條批量回復(fù)（multi bulk reply）的第一個(gè)字節(jié)是 "*"

我們知道redis-cli只能看到最終的執(zhí)行結(jié)果，那是因?yàn)閞edis-cli本身就按照RESP進(jìn)行結(jié)果解析的，所以看不到中間結(jié)果，redis-cli.c 源碼對(duì)命令結(jié)果的解析結(jié)構(gòu)如下：

static sds cliFormatReplyTTY(redisReply *r, char *prefix) {

sds out = sdsempty();

switch (r-type) {

? ? ? ? ? // 處理錯(cuò)誤回復(fù)

case REDIS_REPLY_ERROR:

out = sdscatprintf(out,"(error) %s\n", r-str);

break;

// 處理狀態(tài)回復(fù)

case REDIS_REPLY_STATUS:

out = sdscat(out,r-str);

out = sdscat(out,"\n");

break;

// 處理整數(shù)回復(fù)

case REDIS_REPLY_INTEGER:

out = sdscatprintf(out,"(integer) %lld\n",r-integer);

break;

// 處理字符串回復(fù)

case REDIS_REPLY_STRING:

/* If you are producing output for the standard output we want

* a more interesting output with quoted characters and so forth */

out = sdscatrepr(out,r-str,r-len);

out = sdscat(out,"\n");

break;

// 處理 nil

case REDIS_REPLY_NIL:

out = sdscat(out,"(nil)\n");

break;

// 處理多回復(fù)

case REDIS_REPLY_ARRAY:

if (r-elements == 0) {

out = sdscat(out,"(empty list or set)\n");

} else {

unsigned int i, idxlen = 0;

char _prefixlen[16];

char _prefixfmt[16];

sds _prefix;

sds tmp;

/* Calculate chars needed to represent the largest index */

i = r-elements;

do {

idxlen++;

i /= 10;

} while(i);

/* Prefix for nested multi bulks should grow with idxlen+2 spaces */

memset(_prefixlen,' ',idxlen+2);

_prefixlen[idxlen+2] = '\0';

_prefix = sdscat(sdsnew(prefix),_prefixlen);

/* Setup prefix format for every entry */

snprintf(_prefixfmt,sizeof(_prefixfmt),"%%s%%%ud) ",idxlen);

for (i = 0; i r-elements; i++) {

/* Don't use the prefix for the first element, as the parent

* caller already prepended the index number. */

out = sdscatprintf(out,_prefixfmt,i == 0 ? "" : prefix,i+1);

/* Format the multi bulk entry */

? ? ? ? ? ? ? ? ? tmp = cliFormatReplyTTY(r-element[i],_prefix);

out = sdscatlen(out,tmp,sdslen(tmp));

sdsfree(tmp);

}

sdsfree(_prefix);

}

break;

default:

fprintf(stderr,"Unknown reply type: %d\n", r-type);

exit(1);

}

return out;

}

在 發(fā)送命令 一節(jié)中使用的格式除了用作命令請(qǐng)求協(xié)議之外， 也用在命令的回復(fù)協(xié)議中： 這種只有一個(gè)參數(shù)的回復(fù)格式被稱為批量回復(fù)（Bulk Reply）。

統(tǒng)一協(xié)議請(qǐng)求原本是用在回復(fù)協(xié)議中， 用于將列表的多個(gè)項(xiàng)返回給客戶端的， 這種回復(fù)格式被稱為多條批量回復(fù)（Multi Bulk Reply）。

一個(gè)多條批量回復(fù)以 *argc\r\n 為前綴， 后跟多條不同的批量回復(fù)， 其中 argc 為這些批量回復(fù)的數(shù)量。

狀態(tài)回復(fù)

一個(gè)狀態(tài)回復(fù)（或者單行回復(fù)，single line reply）是一段以 "+" 開(kāi)始、 "\r\n" 結(jié)尾的單行字符串。

以下是一個(gè)狀態(tài)回復(fù)的例子：

+OK

客戶端庫(kù)應(yīng)該返回 "+" 號(hào)之后的所有內(nèi)容。 比如在在上面的這個(gè)例子中， 客戶端就應(yīng)該返回字符串 "OK" 。

狀態(tài)回復(fù)通常由那些不需要返回?cái)?shù)據(jù)的命令返回，這種回復(fù)不是二進(jìn)制安全的，它也不能包含新行。

狀態(tài)回復(fù)的額外開(kāi)銷非常少，只需要三個(gè)字節(jié)（開(kāi)頭的 "+" 和結(jié)尾的 CRLF）。

錯(cuò)誤回復(fù)

錯(cuò)誤回復(fù)和狀態(tài)回復(fù)非常相似， 它們之間的唯一區(qū)別是， 錯(cuò)誤回復(fù)的第一個(gè)字節(jié)是 "-" ， 而狀態(tài)回復(fù)的第一個(gè)字節(jié)是 "+" 。

錯(cuò)誤回復(fù)只在某些地方出現(xiàn)問(wèn)題時(shí)發(fā)送： 比如說(shuō)， 當(dāng)用戶對(duì)不正確的數(shù)據(jù)類型執(zhí)行命令， 或者執(zhí)行一個(gè)不存在的命令， 等等。

一個(gè)客戶端庫(kù)應(yīng)該在收到錯(cuò)誤回復(fù)時(shí)產(chǎn)生一個(gè)異常。

以下是兩個(gè)錯(cuò)誤回復(fù)的例子：

-ERR unknown command 'foobar'

? ? ? ? ? ? ? ? ?-WRONGTYPE Operation against a key holding the wrong kind of value

在 "-" 之后，直到遇到第一個(gè)空格或新行為止，這中間的內(nèi)容表示所返回錯(cuò)誤的類型。

ERR 是一個(gè)通用錯(cuò)誤，而 WRONGTYPE 則是一個(gè)更特定的錯(cuò)誤。 一個(gè)客戶端實(shí)現(xiàn)可以為不同類型的錯(cuò)誤產(chǎn)生不同類型的異常， 或者提供一種通用的方式， 讓調(diào)用者可以通過(guò)提供字符串形式的錯(cuò)誤名來(lái)捕捉（trap）不同的錯(cuò)誤。

不過(guò)這些特性用得并不多， 所以并不是特別重要， 一個(gè)受限的（limited）客戶端可以通過(guò)簡(jiǎn)單地返回一個(gè)邏輯假（false）來(lái)表示一個(gè)通用的錯(cuò)誤條件。

整數(shù)回復(fù)

整數(shù)回復(fù)就是一個(gè)以 ":" 開(kāi)頭， CRLF 結(jié)尾的字符串表示的整數(shù)。

比如說(shuō)， ":0\r\n" 和 ":1000\r\n" 都是整數(shù)回復(fù)。

返回整數(shù)回復(fù)的其中兩個(gè)命令是 INCR 和 LASTSAVE 。 被返回的整數(shù)沒(méi)有什么特殊的含義， INCR 返回鍵的一個(gè)自增后的整數(shù)值， 而 LASTSAVE 則返回一個(gè) UNIX 時(shí)間戳， 返回值的唯一限制是這些數(shù)必須能夠用 64 位有符號(hào)整數(shù)表示。

整數(shù)回復(fù)也被廣泛地用于表示邏輯真和邏輯假： 比如 EXISTS 和 SISMEMBER 都用返回值 1 表示真， 0 表示假。

其他一些命令， 比如 SADD 、 SREM 和 SETNX ， 只在操作真正被執(zhí)行了的時(shí)候， 才返回 1 ， 否則返回 0 。

以下命令都返回整數(shù)回復(fù)： SETNX 、 DEL 、 EXISTS 、 INCR 、 INCRBY 、 DECR 、 DECRBY 、 DBSIZE 、 LASTSAVE 、RENAMENX 、 MOVE 、 LLEN 、 SADD 、 SREM 、 SISMEMBER 、 SCARD 。

批量回復(fù)

服務(wù)器使用批量回復(fù)來(lái)返回二進(jìn)制安全的字符串，字符串的最大長(zhǎng)度為 512 MB 。

客戶端：GET mykey

服務(wù)器：foobar

服務(wù)器發(fā)送的內(nèi)容中：

第一字節(jié)為 "$" 符號(hào)

?- 接下來(lái)跟著的是表示實(shí)際回復(fù)長(zhǎng)度的數(shù)字值

- 之后跟著一個(gè) CRLF

- 再后面跟著的是實(shí)際回復(fù)數(shù)據(jù)

- 最末尾是另一個(gè) CRLF

對(duì)于前面的 GET 命令，服務(wù)器實(shí)際發(fā)送的內(nèi)容為：

"$6\r\nfoobar\r\n"

如果被請(qǐng)求的值不存在， 那么批量回復(fù)會(huì)將特殊值 -1 用作回復(fù)的長(zhǎng)度值， 就像這樣：

客戶端：GET non-existing-key

服務(wù)器：$-1

這種回復(fù)稱為空批量回復(fù)（NULL Bulk Reply）。

當(dāng)請(qǐng)求對(duì)象不存在時(shí)，客戶端應(yīng)該返回空對(duì)象，而不是空字符串： 比如 Ruby 庫(kù)應(yīng)該返回 nil ， 而 C 庫(kù)應(yīng)該返回NULL （或者在回復(fù)對(duì)象中設(shè)置一個(gè)特殊標(biāo)志）， 諸如此類。

多條批量回復(fù)

像 LRANGE 這樣的命令需要返回多個(gè)值， 這一目標(biāo)可以通過(guò)多條批量回復(fù)來(lái)完成。

多條批量回復(fù)是由多個(gè)回復(fù)組成的數(shù)組， 數(shù)組中的每個(gè)元素都可以是任意類型的回復(fù)， 包括多條批量回復(fù)本身。

多條批量回復(fù)的第一個(gè)字節(jié)為 "*" ， 后跟一個(gè)字符串表示的整數(shù)值， 這個(gè)值記錄了多條批量回復(fù)所包含的回復(fù)數(shù)量， 再后面是一個(gè) CRLF 。

客戶端： LRANGE mylist 0 3

服務(wù)器： *4

服務(wù)器： $3

服務(wù)器： foo

服務(wù)器： $3

服務(wù)器： bar

服務(wù)器： $5

服務(wù)器： Hello

服務(wù)器： $5

服務(wù)器： World

在上面的示例中，服務(wù)器發(fā)送的所有字符串都由 CRLF 結(jié)尾。

正如你所見(jiàn)到的那樣， 多條批量回復(fù)所使用的格式， 和客戶端發(fā)送命令時(shí)使用的統(tǒng)一請(qǐng)求協(xié)議的格式一模一樣。 它們之間的唯一區(qū)別是：

統(tǒng)一請(qǐng)求協(xié)議只發(fā)送批量回復(fù)。

而服務(wù)器應(yīng)答命令時(shí)所發(fā)送的多條批量回復(fù)，則可以包含任意類型的回復(fù)。

以下例子展示了一個(gè)多條批量回復(fù)， 回復(fù)中包含四個(gè)整數(shù)值， 以及一個(gè)二進(jìn)制安全字符串：

*5\r\n

:1\r\n

:2\r\n

:3\r\n

:4\r\n

$6\r\n

foobar\r\n

在回復(fù)的第一行， 服務(wù)器發(fā)送 *5\r\n ， 表示這個(gè)多條批量回復(fù)包含 5 條回復(fù)， 再后面跟著的則是 5 條回復(fù)的正文。

多條批量回復(fù)也可以是空白的（empty）， 就像這樣：

客戶端： LRANGE nokey 0 1

服務(wù)器： *0\r\n

無(wú)內(nèi)容的多條批量回復(fù)（null multi bulk reply）也是存在的， 比如當(dāng) BLPOP 命令的阻塞時(shí)間超過(guò)最大時(shí)限時(shí)， 它就返回一個(gè)無(wú)內(nèi)容的多條批量回復(fù)， 這個(gè)回復(fù)的計(jì)數(shù)值為 -1 ：

客戶端： BLPOP key 1

服務(wù)器： *-1\r\n

客戶端庫(kù)應(yīng)該區(qū)別對(duì)待空白多條回復(fù)和無(wú)內(nèi)容多條回復(fù)： 當(dāng) Redis 返回一個(gè)無(wú)內(nèi)容多條回復(fù)時(shí)， 客戶端庫(kù)應(yīng)該返回一個(gè) null 對(duì)象， 而不是一個(gè)空數(shù)組。

多條批量回復(fù)中的空元素

多條批量回復(fù)中的元素可以將自身的長(zhǎng)度設(shè)置為 -1 ， 從而表示該元素不存在， 并且也不是一個(gè)空白字符串（empty string）。

當(dāng) SORT 命令使用 GET pattern 選項(xiàng)對(duì)一個(gè)不存在的鍵進(jìn)行操作時(shí)， 就會(huì)發(fā)生多條批量回復(fù)中帶有空白元素的情況。

以下例子展示了一個(gè)包含空元素的多重批量回復(fù)：

服務(wù)器： *3

服務(wù)器： $3

服務(wù)器： foo

服務(wù)器： $-1

服務(wù)器： $3

服務(wù)器： bar

其中， 回復(fù)中的第二個(gè)元素為空。

對(duì)于這個(gè)回復(fù)， 客戶端庫(kù)應(yīng)該返回類似于這樣的回復(fù)：

["foo", nil, "bar"]

網(wǎng)站題目：服務(wù)器與app安全通信 服務(wù)器和app
文章轉(zhuǎn)載：http://vcdvsql.cn/article6/ddihdog.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供外貿(mào)網(wǎng)站建設(shè)、搜索引擎優(yōu)化、營(yíng)銷型網(wǎng)站建設(shè)、微信公眾號(hào)、網(wǎng)站內(nèi)鏈、ChatGPT

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)