5 回答

TA貢獻(xiàn)1821條經(jīng)驗(yàn) 獲得超6個(gè)贊
此問(wèn)題似乎是與基本查詢(xún)字符串相關(guān)的問(wèn)題。您的問(wèn)題中沒(méi)有關(guān)于樣本期望值和樣本實(shí)際值的指針。因此,我無(wú)法在這里為您提供確切的答案。但下面兩個(gè)是指針,它們肯定會(huì)解決這個(gè)問(wèn)題。
可能存在兩個(gè)問(wèn)題:
問(wèn)題 1:在 HtmlDecode/UrlDecode 之后,原始 Base-64 無(wú)法恢復(fù)
這些令牌被編碼為 base 64 字符串,其中可能包含“+”等字符。
它們被發(fā)送到服務(wù)器。
然后服務(wù)器嘗試對(duì)此字符串執(zhí)行 HtmlDecode 操作,以刪除原始 base 64 令牌中實(shí)際存在的字符。
例如,“+”被空字符串取代。
因此,在 WebUtility.HtmlDecode 之后生成的令牌無(wú)效。這就是您收到無(wú)效令牌錯(cuò)誤的原因
How to check this ?
您可以進(jìn)行調(diào)試,并查看 HtmlDecode 后面的值和預(yù)期值。如果它們不同,那么這就是根本原因。
問(wèn)題 2:查詢(xún)字符串格式不正確
查詢(xún)字符串中的多個(gè)鍵值對(duì)使用“&”字符連接。例如,key1=value1&key2=value2
但有時(shí),它的編碼版本不是在查詢(xún)字符串中出現(xiàn)的。
例如,key1=value1&key2=value2&
&
如果是這種情況,.Net 服務(wù)器將無(wú)法正確分析查詢(xún)字符串。
How to check this ?
您可以使用從 HttpContext 直接讀取原始查詢(xún)字符串,也可以使用 QueryString 屬性的 HttpRequest,并檢查是否屬于這種情況。如果是這樣,那么您可以更改客戶(hù)端以發(fā)送適當(dāng)?shù)牟樵?xún)字符串(更具邏輯性和可維護(hù)性),或者編寫(xiě)一些代碼以在服務(wù)器端進(jìn)行更正。
這些指針應(yīng)該可以幫助您解決問(wèn)題。

TA貢獻(xiàn)1900條經(jīng)驗(yàn) 獲得超5個(gè)贊
您對(duì)電子郵件配置的請(qǐng)求將為您提供 userId 和您的私鑰的響應(yīng),但您的令牌方法應(yīng)該是不同的函數(shù),如令牌刷新,您需要添加一些條件,例如如果令牌已過(guò)期,則刷新令牌

TA貢獻(xiàn)1799條經(jīng)驗(yàn) 獲得超6個(gè)贊
如果編碼的代碼末尾包含“==”。即在urlencode或base64編碼之后,如果代碼像這樣出現(xiàn)“cm9vdA==”。
對(duì)此進(jìn)行解碼不會(huì)為您提供確切的編碼字符串,并將導(dǎo)致無(wú)效代碼。
因此,在生成令牌時(shí),請(qǐng)檢查編碼值是否以“==”結(jié)尾。如果它確實(shí)生成了另一個(gè)令牌,則問(wèn)題將得到解決。

TA貢獻(xiàn)1946條經(jīng)驗(yàn) 獲得超3個(gè)贊
您不需要使用標(biāo)識(shí)服務(wù)器來(lái)解決此問(wèn)題。
當(dāng)用戶(hù)注冊(cè)時(shí),請(qǐng)?jiān)谟脩?hù)表中添加兩列。一個(gè)用于驗(yàn)證,另一個(gè)用于 IsVerified。在驗(yàn)證令牌列中添加一個(gè) Guid。然后使用此 Guid 生成鏈接。當(dāng)用戶(hù)單擊此鏈接時(shí),您將在控制器中獲取 Guid。然后使用此列獲取此用戶(hù),然后將“已驗(yàn)證”列設(shè)置為 true 并刪除 Guid 列。您的用戶(hù)現(xiàn)在已成功驗(yàn)證。

TA貢獻(xiàn)1876條經(jīng)驗(yàn) 獲得超5個(gè)贊
在將確認(rèn)代碼傳遞到方法中之前,應(yīng)對(duì)其進(jìn)行解碼。_userManager.ConfirmEmailAsync(user, code).ConfigureAwait(false)
您已經(jīng)對(duì)您在 callBackUrl 中使用的確認(rèn)代碼進(jìn)行了 URL 編碼;您應(yīng)該在嘗試使用它之前對(duì)其進(jìn)行解碼。WebUtility.UrlDecode(code)
- 5 回答
- 0 關(guān)注
- 408 瀏覽
添加回答
舉報(bào)