まとめそもそもどういう事象なのかも含めて整理する。Spoofing(IPスプーフィング)とは何か送るリクエストの送信元IPを偽装してアクセスをする手法。IP制限などで特定のIPのリクエストしか受け付けない環境に対して、自身のIPを偽装をすることで制限を突破することなどを目的に行われる。通常TCP/IPの方式ではTCPが送信元のIPを改ざんするのは難しい作りになっているため、TCPを用いる場合での送信元IPの偽装は難しいとされている。見ると、リクエスト元となるクライアントIPを推測する処理のところでraiseされる。この処理ではIPアドレスをHTTPのヘッダ情報から類推して特定する処理となっている。ヘッダのいずれかを利用する。関して送信元IPを含むべきX-FORWARDED-FORにCLIENT-IPで書かれているIPが入っていない場合に異常として検知するもの。関しては過去の記事に書いたので説明は端折ります)該当コードとしては以下のあたりです。SpoofingよりもHTTPヘッダでの整合性の合わない話へのエラーとなっている。無効にするにはこのraiseが上がらないように設定をすることもできる。Railsガイド曰く以下の通り。この設定はconfig.action_dispatch.ip_spoofing_checkオプションとconfig.action_dispatch.trusted_proxiesオプションで変更可能です。falseとしておけばこのチェック自体がスキップされる。ヘッダの仕様について調べようとしたところ2024年時点だと全然情報が見つけられずでした。同様のことをやるのが一般的という情報しか出てこなかったので、今だとセットするほうが珍しい可能性があります。それ故にもしエラーが上がった場合は経路的にどこでセットされているのかを確かめるようほうが良いかもしれません。未来の自分が見返したくなる可能性があるのでスクラップ的な意味で書き残す。一般サイトにも参考になる話です。微妙なことが多いですが、公的機関の問題は国民全体の不利益なので素晴らしい問題指摘と思います。中の人、これを見て改善検討して欲しいなあ。内容としては国が運営するナビイを題材に、SEO的に気に掛けるべきところがまとめられている。クローラーが回遊しやすいようにaタグを配置するなどというところに関してはSEOに携わったことがない方だとピンと来ない部分の可能性があるので、そのあたりが実例込みで知れるよい記事となっています。検索の基本事項(旧ウェブマスター向けガイドライン)を読んだあとに実例として目を通すと良さそうな記事でした。読者になる広告を非表示にするもっと読むコメントを書く2024-07-27iOS17.4.1時点では、QRコードを読み取るアプリ「コードスキャナー」でURLを読み込むとWebViewで起動する。17.4.1どういうことかiOSにはQRコードを読み取るアプリが標準で2種類ある。一つはカメラ、一つはコードスキャナーである。この2つのアプリでURLを指し示すQRコードを読み取ったときの挙動が異なる。コードスキャナー内でWebViewが開くこの挙動のため、コードスキャナーでページを開くとSafariでのログインセッションなどは引き継がれないため、Safariでログインをしていても改めてログインを要求される。何がおきるのかWebViewというものを認識していない利用ユーザーからすると「Safariでログインした直後にも関わらず再ログインを要求される」「QRコードからログイン限定領域を見ようとすると毎度ログインを要求される」などの事態がおきる。気をつけるべきこと要ログイン領域のページに遷移するQRコードを準備する場合にはこのような事態になることを勘案してオペレーションを設計する。可能な限りコードスキャナーではなくカメラでのQRコードの読み取りを推奨すると懸念は減らせそう。Routingどのようなことが定義されているのかRFC7230では以下のようなことが記載されている。octets.(リクエストラインの長さに関するさまざまなアドホック制限が実際に見られます。すべてのHTTP送信者と受信者が、少なくとも8000オクテットのリクエストライン長をサポートすることが推奨されます。日本語訳リクエストライン(リクエスト行)には8000文字程度扱えることが推奨されるということになっている。このリクエストラインとは何かというと、HTTPリクエストを送るときの一行目にあたる情報。アクセスするリクエストを送る場合は以下の内容がリクエストのテキストになる。リクエストラインにあたる。このリクエストラインが8000文字程度のサポートを推奨しているので、ホスト部を覗く文字列の長さもその分だけ表現可能ため、8000文字前後はURLの文字列の長さとして許容できる、という見解になる。※資料スライドは見つけたら貼ります。感想カスタマーサクセスからWebエンジニアに変わって景色の見え方が変わった、という内容の話。お互いのコミュニケーションの話で、何を大事にするといいかということを改めて感じる。個人的に強烈に違和感を感じる部分があったので、それに関してはどこかで書き留めたいなと思っている。片方の努力に頼りすぎない|shinkufencer関連リンク今日からできる。さんのこの話が好きで「プロトコルを合わせる」ってのは常に意識してる。個人的にこの手の話を見るたびに、目指すべきは「チームの共通見解の構築」が第一の目的になるんだろうなとは感じている。感想エンジニアに求められることと、その先の事業貢献する話。スケーリングしたのに売上が増えないと、逆回転して退職につながるというのはなるほどなと思う話だった。半自動的にプロダクトの未来や事業の未来を自分ごとに落とす仕組みがOKRなのではないかなと思い、この話と連動させると理にかなっている仕組みなのではないのか?とか思ったりなどした。感想Linuxとコンテナの歴史の話。登壇自体は途中から聞き始めたので、資料ベースで読み返しをしたのですがコンテナ技術がLinuxの技術と地続きなっているのがスッと入る話でした「コンテナは仮想じゃないよ隔離だよ」というのは意識しておきたいなと思う一句でした。資料アップロードしました!「僕のキャリアとワインと鍋」https://t.co/NYiYHfzvEH※先ほどのやつはURL間違えてました。飲食店であるワインと鍋にまつわるいろいろな話とエンジニアリングの話ゴーストレストランをやって手応えを掴むというところからしてプロダクトマネジメント力高いのでは...?など思った現在のWeb開発のプラクティスってどこにでも転用可能なんだなと思ったし、そういう話もいろいろなところで聞くなと思いました。昨日の大吉祥寺.pmで話しました『古典ドメインモデリングパターンの解脱』のスライドです。複雑さに関して、本質的なものと偶有的なもの、ローカルなもの、グローバルなものと切り分けて行って考えを整理していく過程はただただ聞いてて面白かった。集中して作業する技術のスライドです。健康と集中に関するエビデンスが詰まったスライド健康のためには睡眠と運動が大事...という話題以外にもちゃんと即実践できるものがあってよかった個人的にポモドーロ計測をやっていた身なので、7ポモが出せるのはすごいという印象デスク環境を整える話はkawasimaさんの話に通ずるものがあった関連リンク実用性を追求したWebエンジニアのリモートワーク環境。インストールしました。感想サッカーのパスになぞらえたコミュニケーションの話(一休さんの橋の端のような)パスのパスの話みたいにもなったがうなづけるところは多かった相手の状況を把握するというのと、前段の発表の「勝手に諦めない」という話に通ずるものがあるなと聞いていた。コミ(ビッグコミックス)エンジニアリングじゃないエンジニアのお仕事スライドは見つけたら貼ります、forteeはこちら感想エンジニアから技術広報や教育のほうにまわった事に関する話スカウト送ったり送られたりは大変だよね...とは思いながら聞いてました。時間切れで教育の話は聞けなかったのでスライドが公開されたらちょっと見てみたいなと思いました。「全部の非機能要件を拾うのは無理」というのはたしかにそう現状のコンテキストに合わせて相対する軸を出してあげる考え方は大事。技術史料館に行ってみよう!ページの調整があってアップロードが遅れましたが本日のLT資料です。感想NTT技術資料館の行ってみたレポ&推せるときに推せトーク子どもの頃は知らないことを知るみたいな側面で好きだったんですが、ある程度大人になるとベースの知識との差分埋めみたいなのができて楽しいよなと思います。僕はまだ見ぬ誰かを動かすために登壇をする。大吉祥寺.pmでの登壇資料です。口頭のみで話した部分を大幅に加筆しました。登壇することが幸福に繋がっているって話です。誰かの心と行動を変えることができたらとても嬉しく思います。幸福と登壇について、哲学的なアプローチから入る話いわゆる「何者」かになれば幸福を捕まえることができるんじゃないかというところから、そうではなかったんだという話に入るところがとてもキレイに語られていました。勇気とは何かというのも深い問いだなと思いました。Deck伊藤淳一氏が語る「僕の9年間の無名時代」。レバテックラボ(レバテックLAB)エンジニアの登壇を応援する会、再開してます!|ariaki全体を通しての感想10年の振り返りもあり、技術的な話もあり、若い層の経験談もあり、抽象的な設計の話もあり、バラエティに富んだ会だなと改めて思いました。最後に「続けていくことが大事」という話をされていましたが、つくづく自分自身もこのブログを続けていてそう思いました。自分自身も様々な場所の勉強会で刺激をもらいつつ、自分の記録と周りへの議事録共有のぐらいの気持ちでブログにしたためていますが、たまに誰かの役になったお声はいただくので細々とやりたいなと思っています。Railsかな...とか思っています。ガワンデ晋遊舎Amazon読むきっかけ明確にどなたかのツイートかは覚えてないのですが、Twitterなどでオススメされていたのを見たのがきっかけ本についてこの書籍の著者であるアトゥール・ガワンデ氏は外科医かつ公衆衛生学者である。checklist」(安全な手術は命を救うチェックリスト)を作り上げたのだが、このチェックリストができあがるまでのエピソードと「チェックリスト」という考え方が汎用的に使えることをまとめた本となっている。ミスが許されない医療の現場でいかに成功率を上げるかということにおいて、チェックリストが有用であることを様々な角度で語られている。書籍の最後には「チェックリスト作成ためのチェックリスト」があり、普段の生活のチェックリストを作る際にも役立つものとなっている。使われているチェックリストの考え方を取り入れて医療業界に取り入れていくエピソードも紹介されている。その過程を通して「チェックリストが持つ本来の力を発揮するものはどのようなものであるべきなのか」ということもわかる内容となっている。個人的にはこの部分が非常に重要だと感じた。こちらに関しては書籍内で書かれている航空機のチェックリストの事例の話を見ると非常にわかりやすいので、抜粋して紹介する。単発のセスナ機での飛行中に、エンジンが停止したときのためのチェックリストだ。(中略)このチェックリストには、エンジン再始動の方法が六つの手順に凝縮されている。燃料バルブを開く、予備燃料ポンプのスイッチをいれる、などだ。一つ目の手順が最も興味深い。そこには「飛行機を飛ばせ」とだけ書いてあるのだ。パイロットは、エンジンの再始動や原因の分析に一所懸命になり、最も基本的なことを忘れてしまうことがある。「飛行機を飛ばせ」硬直した思考を溶きほぐし、生存の確率を少しでも上げるためにそう書いてあるのだ。事故が発生して頭が真っ白になったら普段できていたこともできなくなる、というエピソードはどこでも聞く話ではあるが、それを加味して事故時の対応のチェックリストに盛り込まれている。チェックリストはマニュアルでも教科書でもない普段チェックリストを作っているとただの「手順書」となってしまう場合がある、言い換えればマニュアルになってしまう。このことに関して書籍内で「チェックリストはマニュアルでも教科書でもない」と書かれている。航空機のチェックリストの事例のとおり、良いチェックリストは要点が凝縮されており、それ自体がなにかの手順を説明するものにはなっていない。してしまうと利用者が使いにくくなってしまうし、純粋に手術や航空機の操縦などで細かく書かれた手順をこなすというのは、紙に対してペンでチェックをいれるようなことができないので難しい。マニュアルではないという側面が強く感じられるのは各項目が簡潔に書くべきというところで、マニュアルや教科書は「何もわかっていない」人向けに書かれるものだが、チェックリストは「ちゃんとわかっている人がヌケモレせずやる」というためのものになっている。そのためこの書籍では「プロフェッショナルこそチェックリストを有効活用すべきである」という旨のことがかかれている。こあたりもマニュアルとは異なるというところを表しているなと感じた。予想外のミスはコミュニケーションで軽減させる。不確実性が高い事象を取り扱うことが多ければ多いほど、トラブルやミスが起きやすい。それらをカバーするために「チェックリスト作成のためのチェックリスト」には下記のような項目がある。抜粋これは、コミュニケーション不全が多い場所ではミスが起きやすいという話から記載がされている。著書の中の例だと手術の話がある。手術の実施前に自己紹介や取り組むことに関しての話がされていない状態で挑んだ場合、なにか予想外のトラブルが起きたときに誰にどう頼むべきかもわからず混乱する。自己紹介と簡単な作業の概要に関して手術の前に言葉を交えるだけでトラブルが起きたときに対処しやすい。事前に喋るタイミングがあれば、不安に思っていることや心配事もお互いに告げやすい。建設現場のエピソードでは以下のように書かれている。建設を任された専門家たちは個人の能力を過信せず、二種類のチェックリストを使う。単純な手順の間違いを防ぐチェックリストと、話し合いをさせることで予想外の困難も確実にすべて解決させるためのチェックリストだ。P82より抜粋チェックリストの力を最大限につかうこの書籍を読むと、チェックリストは平時の事前確認や有事のトラブル対応など様々な場面で使うことができることがわかる。無意味なチェックリストに関して意味のあるものへの変え方も見えてくるので、普段チェックリストに辟易してしまっている人ほど、一読する価値があるような本なのではないかなと思いました。情報処理推進機構みどころ「非機能要件って何を見ればいいんだっけ?」と思ったときに自分自身に馴染のある部分に関してはすぐ検討できるが、馴染のない部分は忘れがちになる。いうときに「一般的にはどういう要素があるんだ?」ということをざっと紹介してくれている。自分自身が扱うシステムがどの程度のレベルまで担保すればいいのだろうというときに具体的な指標も示してくれる。メインの資料自体はExcel形式になっており、項目ごとに気にするべき観点とそれに対する対応度合いがレベルで表現されている。システムが稼働素べき時間を5段階で表しており、レベル3は「1日のうち1時間の停止は許容する」レベル5は「24時間無停止」というような形で項目ごとに守るべき段階を例示してくれている。モデルケース別にどのレベルまで担保すべきか?という例示もセットで用意されている。とりあつかうもの次第で気にするべき非機能要件の要素は変わるが、そこに関しても上からなぞっていくと頭に浮かべておいたほうがいいポイントが見ることができるので、普段非機能要件を整理しない人にはもちろん、普段からやってきていた人もヌケモレチェック用途として利活用できそうな資料でした。「入門『状態』」という内容で登壇してきました。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。