Reactサンドボックス作ってあれこれやる
tags:2022-07-25
ToC
何を学ぶか
- Viteってなに
- ReactLocation使ってみる
- ReactHooksForm使ってみる
- ReactQuery使ってみる
- tailwind使ってみる
- laravelと組み合わせた認証・認可やってみる
viteメモ
- postcssにデフォルトで対応しているので、tailwindcssの導入も簡単
ReactLocationメモ
- routeの指定はobject
- loaderというattributeをrouteが持ってて、非同期のapi取得などを待機できる
- これで読み込み終わってから遷移というのができそう
- 遷移中に画面が白くなるような気もするが...これはなんか書いてあった気がするな
- useNavigateを使うと、関数呼び出しでlinkの移動ができる
- loginされていない時にlogin画面に遷移はどう作る?
- user情報を参照して、持っていなければloginへ飛ばすようなNavigateを作る
- でやってみたけど微妙そう
- dataloaderかoutletが必要そう?
- Outletはデフォルトのコンポーネントで、階層を作るためだけに使われるっぽい(通常そのpathをそのまま下に流す?)
- react-queryでuserを取得しているのがそもそも微妙そうな予感
- 必ず通るrootでuserエンドポイントを叩いて、帰って来なかったらlogin帰ってきたなら元のpath、というようにすれば良い気がしてきたが...
- ダメだった
- 初回のアクセスで必ず通るcomponentを作れば良いんでは?
- 調査中
tailwindcss(とCSS)メモ
- postcss必要
- バンドルサイズがデカくなるのでpurgeが必須っぽい?
- will-cahngeは要素がどうやって更新されるかを示す。filterとかtransitionとかみたいだけど、filterはdocumentにない
- しかしviteでセットアップしたprojectのcssに入ってた
- labelのforにidを当てると、labelクリックでidの要素をクリックしたことにできる
- role属性はアクセシビリティのためにあるようだ
Laravelの認証認可
- 普通のpassword認証がやってみたい
- というか仕組みが見たい
- Guardがリクエストごとにユーザを認証する方法を提供する
- 例えばSessionとCookieでの検証であればセッションガード
- laravelのbreezeというスキャッフォルドをまず試す
- composerでinstallしたあと、
php artisan breeze:install api
でapi用のスキャっフォルドが作られる- apiをつけないとresorucesのjsに諸々作られてしまう
- 実行すると
- corsの設定に許可されるoriginが追加される
- これはenvにFRONTEND_URLを記載していないといけない
- routes/にauth.phpが追加されて、色々endpointが生えてる
- AuthServiceProviderも書き変わっている
- corsの設定に許可されるoriginが追加される
- composerでinstallしたあと、
- guest middlewareは何をしているか
- RedirectIfAuthenticatedのmiddlewareを通過している
- 認証済みだったらばRouteServiceProvider::HOMEにredirectする
- これはデフォルトだと/home
- 認証済みだったらばRouteServiceProvider::HOMEにredirectする
- RedirectIfAuthenticatedのmiddlewareを通過している
- UserにはHasApiTokenトレイトのuseが必要
- validateのconfirmed、同じparamの_confirmationと同値の必要がある
- password_confirmationみたいなね
- sanctum
- configに設定が生えてる。SPA認証なども行える認証用ライブラリ
- FRONTEND_URLやAPP_URLの設定から、許可するdomainを決定してるっぽい
- csrf-cookieって何?
- どうやってcsrfの判定通すんだ?
- responseで帰ってきたXSRF-TOKENをX-XSRF-TOKENに詰めて渡せばいいみたいだけども
- 見えないと思ったけど、artisanのroute一覧表示で確認できる
- vendorを見ると、SanctumServiceProviderで登録がなされてる(defineRoutesがそう)
- laravelの直下にあるから、publishすると勝手に入るものなのかも
- publishしてるProviderがSanctumServiceProviderだもんなぁ
- SANCTUM_STATEFUL_DOMAINSに
localhost:5173
入れないとfromFrontendがtrueにならん - documentにport含むならそれをdomainに書きたまえよってあった...
- $table->morphs('string')
- string_id(BIG int)と、string_type(varchar)を生成するshorthandっぽい
- はまったところメモ
- SANCTUM_STATEFUL_DOMAINSの指定が必要だった
- FRONTEND_URL設定してるから平気やろwとか思ってたらそんなこたぁなかった
- FRONTEND_URLをhttp://localhost:5173にしてるから大丈夫だろ、とか思ってたけど、localhost:5173の指定が必要だったみたい
- SESSION_DOMAINを指定していたら、XSRF_TOKENがjsからさわれなくて困った
- 指定を外すか、単にlocalhostとしたら直った(port番号をつけてしまっていたのが良くなかったみたい)
- SESSION_DOMAINは、本来サブドメインが一致するサイト間でsessionを共有する仕組みみたいだ
- decodeURIComponentで、sanctum/csrf-cookieで取得したCookieを変換しないとtokenの認証通らなかった
- paddingで入っている==とかが引っかかる
- defaultではCookieは送られないので、fetchでauth:sanctum通す場合、mode: corsとcredentials:includeの設定が必要
- SANCTUM_STATEFUL_DOMAINSの指定が必要だった
セキュリティあれこれ
- https://www.slideshare.net/ockeghem/phpconf2021spasecurity
- laravel sanctumの話が乗ってる
- ヘッダにトークンを付与する場合、CORS不備の影響は少ない
- Cookieを伴う場合、
- Access-Control-Allow-Credentials: true
- Access-Control-Allow-Origin: "サイトのorigin"
- の指定が必要
- JWTはOpenID ConnectのID運搬ように作られたが、セッションとして使われる例が多発
- これだとセッション飛ばしてログアウトさせるということができない
- タイムアウトと、リフレッシュトークンを使う
- 1時間ぐらいでJWTをタイムアウトするようにしておく(Firebase Authenticationのデフォルトが1時間)
- sanctumのトークン
- APIトークンをDBに埋めるのでステートフル
- Authorizationヘッダにトークンを埋めて認証認可
- SanctumのSPA認証ではトークンを利用しない
- Cookieベースのセッション認証サービスを利用する
- JWTのメリットは認可サーバの負荷軽減、スケールアウトのしやすさ
- デメリットは即時ログアウトができない
- Chatworkは実際のオペレーションで停止するのも30分かかるだろうということで、30分設定のJWTで運用している
- ステートフルなセッションのメリットはすぐにログアウトできる、が
- デメリットとしてスケールしづらい、セッションDBがボトルネックになるかも
- Web APIの脆弱性は、Content-Typeをapplication/jsonにしていると防ぎやすい
- DOM周りにエスケープしない文字列を表示する処理は基本的に危ない
- SPAでヘッダにトークンをつける場合は、CSRF攻撃はできない
- Cookieはcrendentialとも呼ばれる
- Cookieの情報でもって認証などを行うことがあるため
- CORSリクエストでは通常cookieが付与されない
- credentials: 'include'にすると付与される
- Access-Control-Allow-Credentials: trueで、Cookieを必要とするアクセスを明示的に許可している
- Simple RequestではPreflightが不要
- ブラウザがデフォルトで送信できるRequest(formによるもの)とかはSimpleRequest
- formから発生するGETとPOST
a
,img
,script
から発生するRequestもSimpleRequest
- ブラウザがデフォルトで送信できるRequest(formによるもの)とかはSimpleRequest
- Fetchのmodeには五種類ある
- navigate
- no-cors
- cors
- same-origin
- websocket
- 真ん中三つはfetchの引数に指定可能
- EnsureFrontendRequestsAreStatefulは何やってるの?
- configureSecureCookieSessionsを呼ぶ。以下の二つがconfigに設定される
- 'session.http_only' => true,
- 'session.same_site' => 'lax',
- ちなみにcookieがhttp_onlyかどうかとかはdevtoolから見れるよ
- Pipelineで認証を通してそうだけど、Pipelineはなに?
- それぞれのステップで起こった例外をキャッチしてresponseにしてくれるみたい?
- webで使う一部のmiddlewareを呼び出している
- \App\Http\Middleware\EncryptCookiesは、Cookieの暗号化
- CsrfTokenのverifyとかもそう
- configureSecureCookieSessionsを呼ぶ。以下の二つがconfigに設定される
- app()を受けて、sendにrequestを指定して、throughでfromFrontendがtrueなら、
- 'sanctum'をtrueにして、
- sanctum.middleware.encrypt_cookiesを設定して、
- \Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,を設定して
- \Illuminate\Session\Middleware\StartSession::classも設定して、
- classを投げると自動でinstantiateしてるっぽい挙動
- instaintiateしてhandleが呼ばれる?
- 見た目はmiddlewareっぽい、引数と$nextを受ける
- Illuminate\Pipeline\Pipelineを読むと、method変数に定義されている関数をstepsに入れたものに対して呼び出すみたいだ
- デフォルトではhandleが呼ばれる
$this->{$this->method}()
こんな呼び出しできるんだなぁ
- sanctum.middleware.verify_csrf_tokenを設定して
- $next($request)を呼び出す
- fromFrontendはなに?
- sanctum.statefulに指定したdomainに一致するrequestかどうかを確認している
- SubstituteBindingsは何やってるの?
- Routeのpathにモデルのbindingをしているみたいだ
- laravelのeventとlistener
- registerでevent(new Registerd($user))があるけどこれなに
- 誰がサブスクライブしてるんだ?
- event:listをartisanで叩くと一覧が見れる
- EventServiceProviderに登録があって、デフォルトだとメールが飛ぶっぽい