AWS CLIのサインイン方法についてググると、アクセスキーとシークレットキーをCSVでDLして設定する方法が出てくる。
しかし、アクセスキーは永続的に利用できる認証情報であり、AWS上でも発行しようとするたびに「多くの場合、期限のない長期のアクセスキー (IAM ユーザーのアクセスキーなど) は必要ありません」と忠告してくる
なので、IAM Identity Centerでユーザーを払い出した後に、
aws configure sso
して
SSO start URLにIAM Identity Center→設定→アイデンティティソース→AWS アクセスポータルの URLからコピーしてきたURLを入れるとアクセスキーなしにサインインできる
まぁローカル端末でAWS CLIを使わずにCloudShellを使えばよいのですが…
https://dev.classmethod.jp/articles/cli-is-doko/#toc-9
- ReactみたいなSPAからFirestoreに改竄されたくない情報を書き込む
- クライアント側で書き込むと想定外の部分までユーザが改竄できるため、それを防ぐ
ex. userドキュメントのプロフィールだけを更新したはずが、悪意のあるユーザがUIDフィールドを改竄対象のUIDにしたリクエストをFirestoreに送信することで他人のプロフィールを改竄できる
Firebase FunctionsではFirebase Authenticationのトークンを検証できるので便利
ただし、様々なバリデーションチェックを実装する必要があり、事故りやすい.
以下の記事を参考にすると良かった
Cloud Firestoreで「いいね」機能を実装するときの勘所 – su- tech blog
注意点
・readとwriteのメソッドは以下の細かなメソッドも含むものなので安易にtrueにしない（writeをtrueにするとユーザはドキュメントを削除できる権限を持つことになる
read: get,list
write: create,update,delete
・updateは要注意。他人のデータを改竄できるようになってないかを確認する
ex. uidフィールドをupdateできてしまう
対策：
- update前後で変更されてはいけないデータをバリデーションする
- hasOnlyでupdateできるフィールドを制限する
・セキュリティルールはVScodeとかで書いた方が楽。formatterのプラグインはあるがぶっ壊れている模様。
以下は代表的な関数とか
特定のフィールドへのアクセスを制御する | Firebase Documentation
【発生していた問題】
Firebaseにおいてv9への移行対応をしていたところ、Firestoreのセキュリティルールで、v8では認証状態に応じて値が格納されていたrequest.authが
v9ではrequest.authが常にnullとなっていた
↓こういうルールを実装していた
allow read: if request.auth != null;
【解決方法】
セキュリティルールを使う場合はgetFirestoreと同時にgetAuthする
const firebaseApp = initializeApp(firebaseConfig) const db = getFirestore(firebaseApp) //これを追加する const auth = getAuth(firebaseApp)
【解決まで】
・ぼんやりと通信を眺めていたところ、v8の通信時にはAuthenticationヘッダーがあるのにv9のときはないことに気づく
・v9でもAuthenticationヘッダーに手動でtokenを付加するとrequest.authに想定通りの挙動をするようになった
→v8のときはfirestoreを呼んだらauthも自動的に呼んでくれたが、v9では必要なコンポーネントのみを呼ぶようになってるから明示的にauthを呼ぶ必要があった
【雑記】
・firebaseはindexedDBにtokenを突っ込んでる
・setLogLevel('debug')でfirestoreのデバッグ流せることを知った
追記：有名なNextAuht.jsでも同じことができるのでそっちのほうがいいかも、、、。NextAuthは多機能すぎるのでこっちでもいいが、、、
zenn.dev
・サーバ側でFirebaseのIDトークンの情報(Twitter認証していたらアイコンとかスクリーンネームが入ってる)が使える
・クライアント側ではconst user = useAuthUser でFirebaseのIDトークンの情報が使える
・firebase v9もbeta版では対応中
・一応、Next.js公式からリンクがある
GitHub - gladly-team/next-firebase-auth: Simple Firebase authentication for all Next.js rendering strategies
IDトークン(JWT)をlocalStorageに入れることもあるが、localStorageに入れると
(XSSされる状況でわざわざIDトークンを盗むとかしないだろという反論はある)
(Googleはそんなことしないとは思うが、じゃあどのScriptまでは信用できるのか、第三者が作成するScriptを追加するたびに問題ないかソースコードを全部チェックするのかという問題）
ということらしい。
git clone https://github.com/gladly-team/next-firebase-auth
cd next-firebase-auth
yarn add next-firebase-auth
yarn add firebase firebase-admin next react react-dom
exampleディレクトリでサンプル用のprojectがあるのでそれをいじっていく
next-firebase-auth/example/.env.local.exampleを開いて
の4つをfirebaseのコンソール画面の中から探して埋める。
（左上の歯車クリックして、Firebase SDK snippetのところに書いてある）
他は埋めなくても動く。
※NEXT_PUBLIC_FIREBASE_DATABASE_URLはRealtimedatabaseを使う時に使うっぽい？
Firebase Authの設定画面でメールアドレスの認証をオンにする
next-firebase-authのexampleディレクトリに戻り、
npm run dev
を実行する。
localhost:3000を開くと画面が立ち上がっているので、
Example: SSR + data fetching with ID token
とかをクリックして適当なメールアドレスを入力する。
Firebase Authのコンソール画面で見るとユーザができていると思う
なお、もう一度Example: SSR + data fetching with ID tokenを開くとYour favorite color is: が表示されるが、これはapi/example.jsを叩いてるだけなので毎回変わる
なお、api/example.jsではAPI保護のためのIDトークン検証を行っっている。
クライアント側でデータを取得している。このページに遷移した際の挙動は以下の部分で指定している
whenUnauthedBeforeInit: AuthAction.SHOW_LOADER, whenUnauthedAfterInit: AuthAction.REDIRECT_TO_LOGIN, LoaderComponent: FullPageLoader,
メール認証からTwitter認証に変える場合は
components/FirebaseAuth.jsにある
変更前：
provider: firebase.auth.EmailAuthProvider.PROVIDER_ID,
変更後：
provider: firebase.auth.TwitterAuthProvider.PROVIDER_ID,
に変更する
他のSNSに変えたい場合はこちらのドキュメントを参照する
AuthProvider | JavaScript SDK | Firebase
ちなみにexample.jsはemail情報がないとサインインボタンを表示してしまうため、
各ページのHeaderコンポーネントを
変更前：
<Header email={AuthUser.email} signOut={AuthUser.signOut} />変更後：
<Header email={AuthUser.id} signOut={AuthUser.signOut} />に変えるとちゃんとサインアウトボタンが出る。
ページを開いている途中で
Module not found: Can't resolve 'react-firebaseui/StyledFirebaseAuth'
がでたら
npm install react-firebaseui --save --legacy-peer-deps
でなおる
utilsディレクトリのinitAuth.js内で以下を設定できる
import { useAuthUser, withAuthUser } from 'next-firebase-auth' const Demo = () => { const AuthUser = useAuthUser() return ( <div> <p>Your email is {AuthUser.email ? AuthUser.email : "unknown"}.</p> </div> ) } export default withAuthUser({ whenUnauthedAfterInit: AuthAction.REDIRECT_TO_LOGIN, })(Demo)
クライアント側でfirestoreからフェッチするやり方はここに書いてある
https://github.com/gladly-team/next-firebase-auth#getfirebaseclient--firebaseapp
サーバサイドでfirestoreからフェッチするやり方。
ログインしたユーザのみに見せたいページの時とかに使う。
withAuthUserを使うことで未ログイン時にはログインページに遷移する。
import { withAuthUser, AuthAction, withAuthUserTokenSSR, getFirebaseAdmin } from 'next-firebase-auth' export const getServerSideProps = withAuthUserTokenSSR({ whenUnauthed: AuthAction.REDIRECT_TO_LOGIN, })(async (context) => { const db = getFirebaseAdmin().firestore() const doc = await db.collection('example').get() // Firestoreから取得したデータを処理する (中略) // クエリ取得 console.log('query', context.query) // トークン検証済みのユーザ情報 console.log('AuthUser', context.AuthUser) return { props: { uid: context.AuthUser.id } } }) const MyLoader = () => <div>Loading...</div> export default withAuthUser({ whenUnauthedBeforeInit: AuthAction.SHOW_LOADER, whenUnauthedAfterInit: AuthAction.REDIRECT_TO_LOGIN, LoaderComponent: MyLoader, })(MainComponent)
・サーバ側でfirestoreからデータを取得
・ログインしていないユーザの場合、閲覧できないようにログイン画面へリダイレクト
のつもりで以下のようなコードを書くと
zenn.dev
にある脆弱性を引き起こすので注意。
※ getServerSideProps = withAuthUserTokenSSRのようにすると何もreturnせずにリダイレクトされる
import { getFirebaseAdmin } from 'next-firebase-auth' // ...other imports const Artist = ({artists}) => { return ( <ul> {artists.map((artist) => <li>{artist.name}</li>)} </ul> ) } export async function getServerSideProps({ params: { id } }) { const db = getFirebaseAdmin().firestore() const doc = await db.collection('artists').get() return { props: { artists: artists.docs.map((a) => { return { ...a.data(), key: a.id } }), } } } export default withAuthUser({ whenUnauthedAfterInit: AuthAction.REDIRECT_TO_LOGIN, })(Artist)
401の場合はAPIキーが間違ってる可能性があるが、403の場合は恐らくTwitterのCallbackURLの設定が間違っている。こっちから投げるrequestのCallbackURLと
Authentication settingsで設定しているCallbackURLが一致してないと403を返す。
なお、RailsのWebConsoleでresponse.bodyを入力するとエラーメッセージがわかる。
エラー画面の下でピョコピョコ動いてるやつ。
ちなみにデフォルトの設定は以下なので、丸パクリしてTwitterのAuthentication settingsで設定すれば良いと思う。
Devise＋omniauth＋omniauth-twitterの場合
http://localhost:3000/users/auth/twitter/callback
omniauth＋omniauth-twitterの場合
http://localhost:3000/auth/twitter/callback
※ドキュメントにはlocalhostにするなって書いてあるけどlocalhostでも認証はできる
※2 omniauthのcallbackのデフォルトの挙動は、遷移元のURLにサフィックスとして/auth/twitter/callbackをつけてcallbackurlとして投げているので、開発環境に127.0.0.1でアクセスしている時はTwitterの設定を「http://127.0.0.1:3000/auth/twitter/callback」に変更する必要がある。
これで時間を失った…。
