#失敗したもの curl -X POST localhost/page/download > test.txtサーバー側のログを見るとCan't verify CSRF token authenticityとでていて頭?である。
上のエラーメッセージで調べるとこちらのページに解決策があった。
要は、ブラウザが裏側で行っていたことをしてなかったのが、失敗の原因だった。 なので、そのページ通りにコマンドを実行したら無事できて、よかった(月並み)。
curl localhost/ --cokkie-jar cookie | grep csrf curl localhost/page \ -F "authenticty_token='上のgrepしたもの中のcsrf-tokenのcontentにある文字列を入れる'" --cookie cookie > test.txt
CSRFについて
CSRFはCross-Site Request Forgeries(クロスサイトリクエストフォージェリ)と呼ばれるWebアプリケーションの脆弱性の一つ。 Wikepediaを見ると「ぼくはまちちゃん」事件で利用されたそうだ。
いくつかサイトを調べているとサーバー側の不備が原因の脆弱性だそうだ。
ユーザー側の対策としては、使っていないときはログアウトする、怪しいURLにはアクセスしないがある。
(個人的にスマホで毎回ログイン/ログアウトしている人いるのかな?って。スマホに危機が迫っている。何者かに侵略されているぞ!)
リンク一覧
リンク最後のQiitaを読むと今回したいことはPOSTではなくGETリクエストを使用する方があっているのでは?と思ったので修正。(POSTにしていたのはなんていうか流れ、惰性、なんか変わったことをするにはPOSTみたいな思い込みですかね)
そういえばWebサービスにはRESTという設計モデルがあるって、どこかで聞いていた覚えがある。RESTに当てはめると今回の機能は取得(GET)にあたる機能だから、POSTはおかしい。別にサーバー内のデータを書き換える訳ではないし。 さらにいうと更新とか削除とかすべてPOSTで行っているので、PUT、DELETEに置き換えないと…。公開する前から修正するところだらけである。
さらにいうと、作っている間にみたサイトで、最近のWebサービスにはSSR(Server Side Rendering)を使ったAjaxで1ページだけで画面遷移を行うとかみて、Webの進歩の速さは速すぎると、毎度思う。(格好いいサイトは歓迎です!)
SSRはWebページの不正コピーを防ぐため手段としても活用されているみたいでコンテンツを重要視しているサイトとかだと必須になるのかな?とか思ったり。
SSRなページを作るならVue.jsかなーって、思っていたり、Webページばかり作っていたら、オンラインゲームを作る余裕がないじゃんとか思ったり、そんな日々です。
0 件のコメント:
コメントを投稿