今天外出了一整天,沒有辦法花太多時間在撰寫和開發上,因此就趁著這零星的時間回看一下Firebase Auth這部份,主要還是跟著官方的文件走,以了解更多Firebase Auth的實際用法。先從Verify ID Tokens這文件開始
To do so securely, after a successful sign-in, send the user's ID token to your server using HTTPS. Then, on the server, verify the integrity and authenticity of the ID token and retrieve the uid from it. You can use the uid transmitted in this way to securely identify the currently signed-in user on your server.
在Unity環境下,利用user.TokenAsync(true)
的方式拿取到token,而這個以文字為構成元素的token就是JWT(Json Web Token)。而這個token要回傳到server端去進行驗證。用Firebase Auth Admin給的API,可以確認這個token是正確的或是錯誤的
token, err := client.VerifyIDToken(ctx, idToken)
If your backend is in a language not supported by the Firebase Admin SDK, you can still verify ID tokens.
如果Firebase的語言沒有支援到,則任何JWT認證機制都可以,也就是說Firebase給的JWT是通用規則,而不是特例。但這段自行認證後可以使用的field,就有些奇怪,把拿到的jwt直接放在網上,看到user_id(uid)和sub是一樣的,那不是直接用user_id就可以代表了?
If all the above verifications are successful, you can use the subject (sub) of the ID token as the uid of the corresponding user or device.
從官方的文件回看目前的架構,在service部份是分成一個個的微架構方式。好比說目前的戰鬥配對機制,在Match Game Front這,就需要將Firebase Admin放入,並於配對時拿取token,這樣才能夠引用到此使用者的更多的資料。不過,一但拿到了uid後,直接用其uid就可和其它服務進行資料的拿取。而原先的token就變得沒有太大的意義。
而開發時需要一些假帳號,但又是走正常流程的使用帳號,這時就需要用Auth Admin提供的API進行處理,官方給的範例
h := hash.HMACSHA256{
Key: []byte("secretKey"),
}
result, err := client.ImportUsers(ctx, users, auth.WithHash(h))
if err != nil {
log.Fatalln("Unrecoverable error prevented the operation from running", err)
}
不過這說明就不是很清楚
the hashing options are specified to help Firebase securely authenticate these users the next time they try to sign in with Firebase Authentication.
If no password hashing is needed (phone number, custom token user, OAuth user etc.), do not provide hashing options.
不了解的部份是如果今天不用password的方式就不使用password hashing,但如果使用了password,就一定要從它底下列出的各式各樣的hashing裡選擇一中種?還是就算是用password,也可以不用hashing的方式進行?
看樣子這些都是要花時間了解的,之後在做leaderboard資料時,就需要一些測試用帳號進行功能上的測試。
今天光是看文件就將所剩不多的時間用完了,又只能等到明天才能進行後續的整合了。