2024/10 CTOへの日報まとめ

2024-10-1

class User extends Authenticatable implements MustVerifyEmail といったクラス定義において、implements MustVerifyEmail の部分が何を意味しているのか分からなかったため、調べました。「UserクラスがMustVerifyEmailインターフェースを実装していることを明示的に宣言している」という意味のコードであることを理解することができました。

2024-10-7

cloudformationにて、Type: “AWS::Logs::MetricFilter”で定義するcloudwatchメトリクスに関して、DefaultValueプロパティを用いることで、指定のロググループ内に吐かれたログのうち、フィルターパターンに一致するログが存在しない場合に出力する値を指定できることを知りました。

2024-10-8

cloudformationにて、Type: “AWS::CloudWatch::Alarm”で定義するCloudWatchアラームに関して、TreatMissingDataプロパティを用いることで、データ不足時の挙動を制御することができることを知りました。

指定可能な値

“breaching”：データがない場合にアラームを発動させる（データ不足を異常とみなす）
“notBreaching”：データがない場合にアラームを発動させない（データ不足を正常とみなす）
“ignore”：データがない場合は無視する
“missing”：データ不足を「不足」として扱う

そもそもデータが不足する状況を発生させないことが理想なのかなとは思いつつ、それが難しい場合は上記プロパティにて制御可能であることを知りました。

2024-10-9

CookieのPath属性を活用する事例を知ることができました。

前提として、CookieのPath属性とは、特定のウェブサイト内でクッキーが送信されるべきパスを指定するために使用される。この属性によって、クッキーがどのURLに対して送信されるかを制御することができる。

例えば、クッキーのPath属性が/abcに設定されている場合、そのクッキーはhttps://example.com/abc や https://example.com/abc/xyzなどのURLにアクセスした際に、ブラウザからサーバーに送信される。しかし、https://example.com/xyz など、/abcで始まらないパスには送信されない。

この属性を利用することで、アプリケーションが異なるパスで異なるセッション情報を持つ場合に便利。例えば、ドメインは同じだが、/companyで始まるパスは企業側サービス、/studentで始まるパスは学生側サービスという設計を採用している場合、CookieのPath属性に/companyや/studentを指定することで、企業側アカウントと学生側アカウントでセッションが混合することを防ぐことができる。

2024-10-10

CookieのSecure属性について知ることができました

CookieをHTTPS接続でのみ送信するように制限するための属性。この属性を設定すると、HTTP接続では送信されない。

2024-10-11

MySQLのFLUSH PRIVILEGESコマンドについて知ることができました。

FLUSH PRIVILEGES; とは、MySQLでの権限リロードコマンド

MySQLサーバーが現在メモリに保持しているユーザーの権限情報を、データベースのmysqlスキーマに保存されているユーザー権限テーブルから再読み込みする

これが必要な状況としては、以下のような場合が挙げられる

１、ユーザーや権限を直接テーブルに変更したとき

通常、CREATE USER や GRANT コマンドを使用して権限を変更する場合、自動的に権限情報が再読み込みされる
しかし、INSERT や UPDATE を使って直接 mysql スキーマの user テーブルを変更した場合には、FLUSH PRIVILEGES; を実行することで新しい権限を反映させる必要がある

２、古いバージョンの MySQL

現在の MySQL のバージョンでは、GRANT や REVOKE コマンドを実行した後には自動的に権限が反映されるが、以前のバージョンでは明示的に FLUSH PRIVILEGES; を実行する必要があった

2024-10-15

CORSについて、下記の記事で理解を深めることができました。非常に分かりやすかったです。
https://qiita.com/Hirohana/items/9b5501c561954ad32be7

2024-10-16

CookieのSameSite属性について知ることができました。

クッキーのSameSite属性とは、ブラウザがクッキーをどのようなリクエストに対して送信するかを制御するために使用される。この属性は、CSRF攻撃を防ぐのに役立つセキュリティ機能として導入された。

SameSite属性には以下の3つの値がある

Strict（厳格）

この設定を使用すると、クッキーは現在のウェブサイトからのリクエストにのみ送信される
ユーザーがリンクをクリックして新しいサイトに移動した場合など、他のサイトからのリクエストではクッキーは送信されない

Lax（緩やか）

この設定は、他のサイトからのGETリクエストに対してもクッキーを許可する場合がある
ただし、POSTリクエストでは、クッキーは送信されない

None（なし）

クッキーをすべてのリクエストに対して送信するために使用するが、この設定を使用する場合、必ずSecure属性も設定する必要がある
つまり、クッキーはHTTPSを介してのみ送信される必要がある

SameSite属性を適切に設定することで、ユーザーのセッション情報が安全に保たれ、意図しないリクエストによる情報漏洩のリスクを減らすことができる。

2024-10-17

下記記事より、cloudwatchに吐かれたログのうち、検知したいパターンのログが吐かれた際に、LambdaからSNSを使って通知を送信する具体的な仕組みを知ることができました。これだけ簡単に構築できることを知り、AWSすごいなと改めて思いました。
https://qiita.com/r-oku/items/85d820124c61c0f35d62

2024-10-18

PHPにおけるトレイト（trait）について理解することができました。

PHPにおけるトレイト（trait）とは、コードの再利用を目的とした機能で、クラス間で共通のメソッドやロジックを共有するために使われる
トレイトは多重継承の代替手段として提供されており、1つのクラスで複数のトレイトを「ミックスイン」できる仕組み

トレイトの特徴

コードの再利用：トレイトを使用することで、同じ機能を複数のクラスで使い回すことができる。これにより、重複したコードを書く必要がなくなり、開発効率が向上する
多重継承の問題を解決：PHPはクラスの多重継承をサポートしていない（１つのクラスが複数のクラスを継承できない）。これが多重継承に関連する複雑な問題を回避する一方、同じ機能を異なるクラスで共有したい場合には不便です。また１つのクラスが異なる機能を利用したい場合に不便。トレイトはこの問題に対応しており、クラスに複数のトレイトを含めることで、多重継承と似た機能を実現できる
複数のトレイトを1つのクラスで利用可能：トレイトは複数のクラスで利用でき、また1つのクラスで複数のトレイトを利用することもできる。トレイト内のメソッドは、そのトレイトを使うクラスで直接利用できるようになる

トレイトの基本構文
・トレイトは trait キーワードを使用して定義される。トレイトを使用したいクラスでは use キーワードを使ってトレイトをインポートする

トレイトの定義
trait Loggable
{
public function log($message)
{
echo “Log: ” . $message;
}
}

トレイトの使用
クラス内で use キーワードを使ってトレイトをインポートする

class User
{
use Loggable;

public function performAction()
{
$this->log(“User performed an action.”);
}
}

$user = new User();
$user->performAction(); // 出力: Log: User performed an action.

トレイトの活用場面

共通メソッドの共有：トレイトを使うことで、異なるクラスで同じメソッドを共有し、コードの重複を減らすことができる
DRY原則（Don’t Repeat Yourself）の実現：コードの再利用性を高め、保守性を向上させる
機能のモジュール化：特定の機能をトレイトに分けて整理することで、プロジェクト全体をよりモジュール化しやすくする

トレイトの利点

柔軟なコード再利用：複数のクラス間で同じ機能を共有できるため、重複したコードを書かなくて済む
簡単な拡張性：既存のクラスに簡単に新しい機能を追加できる
多重継承の制約を回避：クラスがすでに継承している親クラスがあっても、トレイトを追加して他の機能を利用できる

トレイトの注意点

メソッドの衝突：クラスが複数のトレイトを利用している場合、同じ名前のメソッドが存在すると、メソッドの衝突が発生する。この場合、insteadof キーワードを使用して、どのトレイトのメソッドを優先するかを指定できる
依存関係：トレイト内のメソッドが、クラス内の他のメソッドやプロパティに依存している場合、クラスでそれらを定義しなければなりません

まとめ

PHPのトレイトは、コードを再利用し、複数のクラス間で共通の機能を簡単に共有するための強力なツール。
多重継承の制約を避けつつ、クラスに柔軟に新しい機能を追加できるため、コードの重複を減らし、プロジェクトの保守性を向上させるために非常に役立つ

2024-10-21

複数のトレイトをクラスにインポートした際にメソッド衝突が起きた場合、それの解決方法を知ることができました

trait A
{
public function test()
{
echo “A’s test”;
}
}

trait B
{
public function test()
{
echo “B’s test”;
}
}

class MyClass
{
use A, B {
A::test insteadof B; // Aのtestメソッドを優先
B::test as bTest; // BのtestメソッドをbTestとして使用
}
}

$myClass = new MyClass();
$myClass->test(); // 出力: A’s test
$myClass->bTest(); // 出力: B’s test

2024-10-24

外部キー制約を付与した際に選択可能なオプションとして、カスケード以外の下記４つを知ることができました

ON DELETE SET NULL：Parentを削除するとChildのparent_idをNULLにして関連を破棄する（ただし、Childのparent_idがNULLを許可している場合に限る）
ON DELETE NO ACTION：Parentを削除しようとした時、そのParentを参照しているChildがあれば、削除に失敗する
ON DELETE RESTRICT：Parentが削除できないように制限する。関連するChildが存在する限り、Parentは削除できない
ON DELETE DEFAULT：Parentが削除されたときに、Childの外部キーにデフォルト値を設定する

2024-10-25 ①

mod_headersモジュールについて理解することができました。

mod_headersモジュールとは、Apache HTTP サーバーのための標準モジュールで、クライアントやサーバーに送信される HTTP ヘッダーを操作するための機能を提供する。このモジュールは、リクエストヘッダーおよびレスポンスヘッダーの値を追加、削除、または変更することができる。

主な機能

ヘッダーの追加：新しいヘッダーをリクエストやレスポンスに追加する
ヘッダーの削除：不要なヘッダーをリクエストやレスポンスから削除する
ヘッダーの変更：既存のヘッダーの内容を変更する

使用例
1. セキュリティヘッダーを追加する：セキュリティを強化するために、特定のセキュリティ関連のヘッダーをレスポンスに追加する使われ方がよくある。
Header always set Strict-Transport-Security “max-age=31536000; includeSubDomains”

2. CORSの設定：特定のオリジンからのリクエストに対してリソースへのアクセスを許可するために CORS ヘッダーを設定する
Header set Access-Control-Allow-Origin “https://example.com”

3. クッキーヘッダーの変更：既存のクッキーに属性を追加することもできる（SameSite属性を追加するなど）
Header always edit Set-Cookie (.*) “$1; SameSite=Lax”

mod_headersモジュールを使用することで、サーバー管理者はクライアントのブラウザや他のクライアントに送信される情報をより細かくコントロールできるようになる。これにより、パフォーマンスの向上、セキュリティの強化、または特定のクライアントのニーズに対応するためのカスタマイズが可能になる。

2024-10-25 ②

https://zenn.dev/praha/articles/2667cbb1ab7233

上記記事にて、外部キー制約を付与した際に選択可能な各オプション（cascade、set null、no action）に関する１開発者の見解が書かれていました。非常に面白かったです。カスケード削除に関して、自分は割と肯定的でしたが、上記記事では否定的な感じで書かれており、これを読んで改めて「開発者によって色々な意見があるのだな」と感じました。色々な開発者に見解を聞き、自分のそれまでの考えが本当に適しているのか、たびたび考える必要があると感じました。

2024-10-28

/etc/httpd/ディレクトリについて知ることができました。

/etc/httpd/ ディレクトリは、Apache HTTPサーバー（httpd）の設定ファイルが置かれるディレクトリ。このディレクトリには、Apacheサーバーの動作や設定に関する様々なファイルが含まれている。

主な内容

１、/etc/httpd/conf/

Apacheのメイン設定ファイルである httpd.conf が含まれている
このファイルには、サーバーの基本的な設定（ポート番号、ドキュメントルート、ログの設定など）が記述されている

２、/etc/httpd/conf.d/

Apacheの追加設定ファイルが配置されるディレクトリ
このディレクトリにある .conf ファイルはすべて自動的に読み込まれる
サイトやバーチャルホストの設定、モジュールの設定などがここに配置される

３、/etc/httpd/conf.modules.d/

Apacheのモジュール設定ファイルが置かれるディレクトリ
モジュールのロードや設定に関する .conf ファイルが含まれる
例えば、00-base.conf のようなファイルに LoadModule ディレクティブを使用して、Apacheにロードするモジュールを指定する

４、/etc/httpd/logs/（シンボリックリンクとして設定されることが多い）

ログファイルの格納先を指し示す
実際のログファイルは通常 /var/log/httpd/ に配置されるが、/etc/httpd/logs/ からアクセスすることもできる

５、/etc/httpd/modules/

Apacheで利用するモジュール（バイナリファイル）が配置されるディレクトリ
mod_*.so というファイル名で保存されており、必要なモジュールをロードする際に使われる

６、/etc/httpd/run/（一部のシステムで使用される）

Apacheの実行に関連する一時ファイルが配置されることがある

/etc/httpd/ ディレクトリ全体は、Apacheサーバーの構成を管理するための重要な場所であり、設定ファイルを適切に変更することで、サーバーの動作を制御することができる

2024-10-29

AWSのポリシーにて、ActionだけではなくNotActionも指定可能であることを知りました。

NotAction は Action とは異なり、「指定したアクション以外を許可または拒否する」ために使われる。そのため、Effect が Allow になっている場合、指定されたアクション以外のすべてが許可される。逆に Effect が Deny になっている場合、指定されたアクション以外のすべてが拒否される。

2024-10-30

Content Security Policy（CSP）について理解することができました。

Content Security Policy（CSP）とは、ウェブサイトやウェブアプリケーションにおけるXSSやデータインジェクション攻撃を防ぐためのセキュリティ機能
CSPは、ブラウザに対して、ページ上でどのリソース（スクリプト、スタイル、画像など）がロード可能かを指示するHTTPヘッダーを使用する

CSPの主な仕組み