dz和uc在一起的，通信使用數(shù)據(jù)庫(kù)方式，效率高。
用戶(hù)登錄使用的UC的密碼，所以UC通知其他應(yīng)用失敗不影響登錄

mingkong 發(fā)表于 2023-7-17 19:05
最后密碼是否修改成功了呢。如果時(shí)間比較長(zhǎng)，比較像是有網(wǎng)絡(luò)問(wèn)題引起的。比如網(wǎng)絡(luò)防火墻。 ...

雖然后臺(tái)UC通知會(huì)報(bào)錯(cuò)，卡的時(shí)間長(zhǎng)了點(diǎn)，但是最后密碼還是修改成功了的。

就是卡的過(guò)程讓人很難受，用的寶塔面板，有一個(gè)免費(fèi)的Nginx免費(fèi)防火墻，但是未查詢(xún)到有攔截的記錄。

剛才還想到了個(gè)情況，如果你的服務(wù)器是windows，數(shù)據(jù)庫(kù)的連接設(shè)置，但凡是設(shè)置的localhost，都改成127.0.0.1
像這樣的

1. $_config['db']['1']['dbhost'] = '127.0.0.1';

復(fù)制代碼

龍二哥 發(fā)表于 2023-7-17 18:27
謝謝大蝦的解答。

我這邊用戶(hù)在前臺(tái)修改密碼和管理在后臺(tái)編輯用戶(hù)密碼時(shí)，都要卡一會(huì)，大概10秒以上

最后密碼是否修改成功了呢。如果時(shí)間比較長(zhǎng)，比較像是有網(wǎng)絡(luò)問(wèn)題引起的。比如網(wǎng)絡(luò)防火墻。

antsun 發(fā)表于 2023-7-17 18:35
修改密碼是會(huì)和uc通信的，你思考的是正確的。 如果你這里沒(méi)填寫(xiě)mysql那么它走api的方式修改密碼需要網(wǎng)絡(luò) ...

應(yīng)該是你解釋的這樣，目前UC相關(guān)配置文件檢查過(guò)了，未發(fā)現(xiàn)有異常，后臺(tái)UC通信也是成功的，不知道如何排查這個(gè)問(wèn)題了。

暫時(shí)走api的方式，用接口方式鏈接UC。

龍二哥 發(fā)表于 2023-7-17 18:27
謝謝大蝦的解答。

我這邊用戶(hù)在前臺(tái)修改密碼和管理在后臺(tái)編輯用戶(hù)密碼時(shí)，都要卡一會(huì)，大概10秒以上

修改密碼是會(huì)和uc通信的，你思考的是正確的。 如果你這里沒(méi)填寫(xiě)mysql那么它走api的方式修改密碼需要網(wǎng)絡(luò)通信、然后修改數(shù)據(jù)庫(kù)。 如果是mysql則直接修改數(shù)據(jù)庫(kù)，我是這樣理解的不知道是否正確哈

antsun 發(fā)表于 2023-7-17 18:18
這是uc配置文件里面的解釋
連接 UCenter 的方式: mysql/NULL, 默認(rèn)為空時(shí)為 fscoketopen(), mysql 是直接連 ...

謝謝大蝦的解答。

我這邊用戶(hù)在前臺(tái)修改密碼和管理在后臺(tái)編輯用戶(hù)密碼時(shí)，都要卡一會(huì)，大概10秒以上
感覺(jué)是和UC通信的問(wèn)題，但偏偏后臺(tái)UC通訊這里又顯示的成功狀態(tài)，不知道是哪的問(wèn)題了。

有區(qū)別，一個(gè)是定義了一個(gè)空值，一個(gè)是指定了必須是mysql。
如果定義一個(gè)空值，而且這個(gè)uc_connect使用的地方，沒(méi)有判斷過(guò)空值的時(shí)候怎么處理，程序就可能出錯(cuò)。
如果定義空值的時(shí)候沒(méi)有出錯(cuò)，大概率是這個(gè)uc_connect有一個(gè)默認(rèn)值。

這是uc配置文件里面的解釋
連接 UCenter 的方式: mysql/NULL, 默認(rèn)為空時(shí)為 fscoketopen(), mysql 是直接連接的數(shù)據(jù)庫(kù), 為了效率, 建議采用 mysql