S3みたいなストレージサーバーっぽいものを自前で用意する③【Digest認証実装】
2022/03/26 2022/04/10S3みたいなストレージサーバーっぽいものを自前で用意する③【Digest認証実装】 こんにちは。のんです。 前回に引き続き自前でストレージサーバーを開発していこうと思います。 S3みたいなストレージサーバーっぽいものを自前で用意する②【ミドルウェア実装】 | のんラボ S3みたいなストレージサーバーっぽいものを自前で用意する②【ミドルウェア実装】こんにちは。のんです。前回に引き続き自前でストレージサーバーを開発していこうと思います。 ... GitHubプロジェクトはこちら GitHub - nonz250/storage Contribute to nonz250/storage development by creating an account on GitHub. 前回作成したAuthMiddleware にDigest認証を実装する Digest認証について Basic認証はBase64でエンコードされているとはいえ、パスワードを送ってしまうのでデコードされたらバレちゃう→ダメじゃん って流れからパスワードを含めた情報を md5 や sha256 でハッシュ化して送ろうと考案された。この辺は散々他のWEBサイトで解説されているので簡単に説明しました。 API認証でこのDigest認証を採用する可能性があった（仕事で使うかもしれない）から勉強するために採用しました。 Digest認証 - Wikipedia Digest認証 - Wikipediaを見る wikiによれば クライアントは認証が必要なページをリクエストする。しかし、通常ここではユーザ名とパスワードを送っていない。なぜならばクライアントはそのページが認証を必要とするか否かを知らないためである。 サーバは401レスポンスコードを返し、認証領域 (realm) や認証方式（Digest）に関する情報をクライアントに返す。このとき、ランダムな文字列（nonce）とサーバーがサポートしている qop (quality of protection) を示す引用符で囲まれた１つまたは複数のトークンも返される。 それを受けたクライアントは、認証領域（通常は、アクセスしているサーバやシステムなどの簡単な説明）をユーザに提示して、ユーザ名とパスワードの入力を求める。ユーザはここでキャンセルすることもできる。 ユーザによりユーザ名とパスワードが入力されると、クライアントはnonceとは別のランダムな文字列（cnonce）を生成する。そして、ユーザ名とパスワードとこれら2つのランダムな文字列などを使ってハッシュ文字列（response）を生成する。 クライアントはサーバから送られた認証に関する情報(ユーザ名, realm, nc(nonce count), nonce, cnonce, qop)とともに、responseをサーバに送信する。 サーバ側では、クライアントから送られてきたランダムな文字列（nonce、cnonce）などとサーバに格納されているハッシュ化されたパスワードから、正解のハッシュを計算する。 この計算値とクライアントから送られてきたresponseとが一致する場合は、認証が成功し、サーバはコンテンツを返す。不一致の場合は再び401レスポンスコードが返され、それによりクライアントは再びユーザにユーザ名とパスワードの入力を求める。 とある。 APIには ページが無い 認証が必要であることが明示的にわかっている ため、1, 2, 3の手順は必要ない。 このため、 AuthMiddleware には4以降のクライアントから送信された入力情報を検証する処理のみを実装する。 ざっくりとした実装と解説 <?php declare(strict_types=1); namespace Nonz250\Storage\App\Http\Auth; // 省略 class AuthMiddleware implements MiddlewareInterface { private DigestAuthInterface $digestAuth; public function __construct(DigestAuthInterface $digestAuth) { $this->digestAuth = $digestAuth; } public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface { try { $digests = $request->getHeader('Authorization') ?? []; if (count($digests) === 0) { throw new HttpUnauthorizedException('Please set `Authorization` header.'); } } catch (HttpUnauthorizedException $e) { // TODO: ログ記録 return $e->getApiProblemResponse(); } try { try { $input = new DigestAuthInput($digests[0], $request->getMethod(), App::env('DIGEST_NONCE')); $this->digestAuth->process($input); } catch (InvalidArgumentException | DataNotFoundException $e) { // TODO: ログ記録 throw new HttpBadRequestException($e->getMessage()); } catch (InvalidResponseException $e) { // TODO: ログ記録 throw new HttpUnauthorizedException('Please check user.'); } catch (Throwable $e) { // TODO: ログ記録 throw new HttpInternalErrorException($e->getMessage()); } } catch (HttpException $e) { // TODO: ログ記録 return $e->getApiProblemResponse(); } return $handler->handle($request); } } 以上が大まかな実装です。 TODO コメントが多いのは実装途中だからですね。ロギングをしなければエラーを拾うことができなくなってしまいます。未実装なのでメモを残しています。 それ以外のところを上から順に追っていきます。 try { $digests = $request->getHeader('Authorization') ?? []; if (count($digests) === 0) { throw new HttpUnauthorizedException('Please set `Authorization` header.'); } } catch (HttpUnauthorizedException $e) { // TODO: ログ記録 return $e->getApiProblemResponse(); } 特に難しいことはしていません。読めばわかると思います。 Authorization ヘッダがない場合にエラーレスポンスを返しています。 return $e->getApiProblemResponse(); の部分はまだ未解説の部分で、（たぶん）次回に解説するのでその時に。 Authorization ヘッダがない場合というのは クライアントは認証が必要なページをリクエストする。しかし、通常ここではユーザ名とパスワードを送っていない。なぜならばクライアントはそのページが認証を必要とするか否かを知らないためである。 に反しているのでエラーを返しています。 つまり、「このAPIは認証が必須ですよ。」ということをお知らせしています。 次に実際にDigest認証をしているところを見てみます。 下記のように、検証をしている箇所はUseCase層に封じ込めています。 try { try { $input = new DigestAuthInput($digests[0], $request->getMethod(), App::env('DIGEST_NONCE')); $this->digestAuth->process($input); } catch (InvalidArgumentException | DataNotFoundException $e) { // TODO: ログ記録 throw new HttpBadRequestException($e->getMessage()); } catch (InvalidResponseException $e) { // TODO: ログ記録 throw new HttpUnauthorizedException('Please check user.'); } catch (Throwable $e) { // TODO: ログ記録 throw new HttpInternalErrorException($e->getMessage()); } } catch (HttpException $e) { // TODO: ログ記録 return $e->getApiProblemResponse(); } ほとんどがエラーハンドリングのためのコードですが、実際に検証処理を呼び出している箇所は下記ですね。 $input = new DigestAuthInput($digests[0], $request->getMethod(), App::env('DIGEST_NONCE')); $this->digestAuth->process($input); Digest認証に関するコードはこちら。 Auth ├ ClientRepositoryInterface.php └ Command └─ DigestAuth ├─ DigestAuth.php ├─ DigestAuthInput.php ├─ DigestAuthInputPort.php └─ DigestAuthInterface.php DigestAuthInput クラスに Authorization ヘッダの値 HTTPリクエストメソッド nonce の値 の認証に必要な3つの値を渡し、このInputクラスを利用してDigest認証の検証プロセスを発火します。 ちなみに、 DigestAuthInput の実装はこちら。 <?php declare(strict_types=1); namespace Nonz250\Storage\App\Domain\Auth\Command\DigestAuth; class DigestAuthInput implements DigestAuthInputPort { private array $data = []; private string $method; private string $nonce; public function __construct(string $value, string $method, string $nonce) { $this->parse($value); $this->method = $method; $this->nonce = $nonce; } public function userName(): string { return $this->data['username'] ?? ''; } public function uri(): string { return $this->data['uri'] ?? ''; } public function qop(): string { return $this->data['qop'] ?? ''; } public function nc(): string { return $this->data['nc'] ?? ''; } public function cnonce(): string { return $this->data['cnonce'] ?? ''; } public function response(): string { return $this->data['response'] ?? ''; } public function method(): string { return $this->method; } private function parse(string $value): void { preg_match_all( '@(cnonce|nc|qop|response|username|uri)=(?:([\'"])([^\2]+?)\2|([^\s,]+))@', $value, $matches, PREG_SET_ORDER ); foreach ($matches as $match) { $this->data[$match[1]] = $match[3] ?: $match[4]; } } public function nonce(): string { return $this->nonce; } } 解説するべき点は1点のみです。 preg_match_all( '@(cnonce|nc|qop|response|username|uri)=(?:([\'"])([^\2]+?)\2|([^\s,]+))@', $value, $matches, PREG_SET_ORDER ); foreach ($matches as $match) { $this->data[$match[1]] = $match[3] ?: $match[4]; } Authorization ヘッダの中身（つまりクライアントから送信された入力内容）から、cnonce値, nc値 , qop値 , response値 , username値 , uri値 を取得します。 具体的な検証プロセスとその解説 DigestAuthInputPort が実装された入力内容を利用した検証プロセスはこちら。 同様に上から追っていきます。 <?php declare(strict_types=1); namespace Nonz250\Storage\App\Domain\Auth\Command\DigestAuth; // 省略 class DigestAuth implements DigestAuthInterface { private const REALM = 'Secret Zone'; private const SHA_256 = 'sha256'; private ClientRepositoryInterface $clientRepository; public function __construct(ClientRepositoryInterface $clientRepository) { $this->clientRepository = $clientRepository; } public function process(DigestAuthInputPort $inputPort): void { $client = $this->clientRepository->findById(new ClientId($inputPort->userName())); $userName = (string)$client->clientId(); $password = (string)$client->clientSecret(); $nonce = $inputPort->nonce(); // @see https://tex2e.github.io/rfc-translater/html/rfc7616.html $A1 = hash(self::SHA_256, "$userName:" . self::REALM . ":$password"); $A2 = hash(self::SHA_256, "{$inputPort->method()}:{$inputPort->uri()}"); $validResponse = hash(self::SHA_256, "$A1:" . $nonce . ":{$inputPort->nc()}:{$inputPort->cnonce()}:{$inputPort->qop()}:$A2"); if ($validResponse !== $inputPort->response()) { throw new InvalidResponseException(); } } } 以外とシンプルにまとまっています。 $client = $this->clientRepository->findById(new ClientId($inputPort->userName())); まず、入力されたユーザー（クライアント）情報を取得します。このときにユーザーの存在チェックも行っています。 ClientRepogitory の実装については実際にGithubのコードを見てみてください。 storage/ClientRepository.php at main · nonz250/storage Contribute to nonz250/storage development by creating an account on GitHub. とは言ってもただのSQL実行機ですが...複雑なクエリを必要としないので、ORMやクエリビルダなどのツールは用意していません。（これもそのうち記事にしたいと思います。） ともかく、 Repogitory からユーザー情報を取得できたので、リクエストで入手した情報とサーバーにある情報を比べて比較していきます。 $userName = (string)$client->clientId(); $password = (string)$client->clientSecret(); $nonce = $inputPort->nonce(); 見てわかるように、今後の処理が追いやすいように変数に格納しているだけです。 次のコードに行きます。 @see でも書かれているように、Digest認証は RFC 7616 で決められています。 下のサイトは日本語訳されているサイトなので比較的読みやすいと思います。 https://tex2e.github.io/rfc-translater/html/rfc7616.html https://tex2e.github.io/rfc-translater/html/rfc7616.htmlを見る ただ、もちろん RFC ft-ietf-httpauth-digest: HTTP Digest Access Authentication The Hypertext Transfer Protocol (HTTP) provides a simple challenge- response authentication mechanis... こちらのサイトの確認も推奨します。 さて、具体的な実装については 3.4.1章 に書かれていそうです。 前提として、このAPIのDigest認証は下記の仕様に従うものとします。 qop 値が auth であること ハッシュ化アルゴリズムは SHA256 であること とすると、 If the algorithm parameter's value is "", e.g., "SHA-256", then A1 is: A1 = unq(username) ":" unq(realm) ":" passwd where passwd = < user's password > と実装されるようです。 上記を参考にして、まず A1 から $A1 = hash(self::SHA_256, "$userName:" . self::REALM . ":$password"); ユーザー名 、 realm値 、 パスワード を : で結合したものを MD5 や SHA256 でハッシュ化します。 次に A2 です。 If the qop parameter's value is "auth" or is unspecified, then A2 is: A2 = Method ":" request-uri If the qop value is "auth-int", then A2 is: A2 = Method ":" request-uri ":" H(entity-body) auth を想定していますので、 A2 = Method ":" request-uri ですね。 $A2 = hash(self::SHA_256, "{$inputPort->method()}:{$inputPort->uri()}"); Httpリクエストメソッド と リクエストUri を : で結合したものを MD5 や SHA256 でハッシュ化します。 最後に A1 と A2 からレスポンス値の生成します。 このレスポンス値がクライアントで生成されたと同じであれば認証成功となります。 If the qop value is "auth" or "auth-int": response = <"> < KD ( H(A1), unq(nonce) ":" nc ":" unq(cnonce) ":" unq(qop) ":" H(A2) ) <"> See below for the definitions for A1 and A2. 日本語の文法的に最後になってしまいました。これまで作成した A1 と A2 からレスポンス値の生成方法は、 A1 、 nonce値 、 nc値 、 cnonce値 、 qop値（ここではauth） と A2 を : で結合して MD5 や SHA256 でハッシュ化します。 $validResponse = hash(self::SHA_256, "$A1:" . $nonce . ":{$inputPort->nc()}:{$inputPort->cnonce()}:{$inputPort->qop()}:$A2"); こうすることで、クライアント側で生成された response値 と同じものが作成できたはずです。 それを実際に検証し、成功すればOK。失敗すれば例外をスローします。 if ($validResponse !== $inputPort->response()) { throw new InvalidResponseException(); } これで検証プロセスの実装が完了しました。 まとめ クライアント側でユーザー情報など各種値と、決められた手順でハッシュ化された response値 を Authorization ヘッダにセット サーバーに送信。 サーバー側でユーザー情報の有無確認 クライアントとは違うリソース （重要: クライアントから取得した情報を利用しても意味がない。DBなどで保存されているクライアントとは別のリソース）を使い、同じ手順で response値 を生成 response値 の比較 という手順。 おまけ: エラーハンドリングについて ValueObjectなど引数のエラー BadRequest ユーザー情報の有無や認証エラー Unauthorized その他 InternalServerError という感じ。 最後に ぶっちゃけこのコードもまだまだ改善点はありますね。 qop は auth のみを前提にしていますし、ハッシュ化のアルゴリズムも <algorithm> -sess の考慮がされていません。 想定されていないことなら、それをエラーレスポンスとしてユーザーに教えてあげる必要がありますよね。でもそれがない。というのが今後の課題になりそうです。 とはいえ、結局自分しか使わないサービスになりそうなのでその辺は...実装するかな？ｗ 次回は予定通り RFC 7807 について記事にしたいと思います。 APIを実装する上でエラーレスポンスをどう返すかというのをルール化したものですね。 この話はどちらかというと採用したライブラリや、独自例外クラスの記事になりそうです。 賛否あるかと思いますが、温かい目で見ていただければ幸いです。 また記事にします。 その時はよしなに。 .
S3みたいなストレージサーバーっぽいものを自前で用意する②【ミドルウェア実装】
2022/03/26 2022/03/26S3みたいなストレージサーバーっぽいものを自前で用意する②【ミドルウェア実装】 こんにちは。のんです。 前回に引き続き自前でストレージサーバーを開発していこうと思います。 S3みたいなストレージサーバーっぽいものを自前で用意する①【ルーティング初期設定】 | のんラボ S3みたいなストレージサーバーっぽいものを自前で用意するこんにちは。のんです。実はちょっと前からのんラボのリプレースを考えていまして、ブログに載せる画像のアップロード先について考えていました。これまで... GitHubプロジェクトはこちら GitHub - nonz250/storage Contribute to nonz250/storage development by creating an account on GitHub. ミドルウェアを実装する league/route の MiddlewareInterface https://route.thephpleague.com/ https://route.thephpleague.com/を見る league/route は PSR-15 準拠のミドルウェア実装に対応しているので、 https://www.php-fig.org/psr/psr-15/#22-psrhttpservermiddlewareinterface https://www.php-fig.org/psr/psr-15/#22-psrhttpservermiddlewareinterfaceを見る にあるように、 The following interface MUST be implemented by compatible middleware components. namespace Psr\Http\Server; use Psr\Http\Message\ResponseInterface; use Psr\Http\Message\ServerRequestInterface; /** * Participant in processing a server request and response. * * An HTTP middleware component participates in processing an HTTP message: * by acting on the request, generating the response, or forwarding the * request to a subsequent middleware and possibly acting on its response. */ interface MiddlewareInterface { /** * Process an incoming server request. * * Processes an incoming server request in order to produce a response. * If unable to produce the response itself, it may delegate to the provided * request handler to do so. */ public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface; } を実装するようにします。 process の引数である ServerRequestInterface は PSR-7 、RequestHandlerInterface は PSR-15 準拠です。 ServerRequestInterface （※ 長いので省略） https://www.php-fig.org/psr/psr-7/#321-psrhttpmessageserverrequestinterface https://www.php-fig.org/psr/psr-7/#321-psrhttpmessageserverrequestinterfaceを見る RequestHandlerInterface https://www.php-fig.org/psr/psr-15/#22-psrhttpservermiddlewareinterface https://www.php-fig.org/psr/psr-15/#22-psrhttpservermiddlewareinterfaceを見る The following interface MUST be implemented by request handlers. namespace Psr\Http\Server; use Psr\Http\Message\ResponseInterface; use Psr\Http\Message\ServerRequestInterface; /** * Handles a server request and produces a response. * * An HTTP request handler process an HTTP request in order to produce an * HTTP response. */ interface RequestHandlerInterface { /** * Handles a request and produces a response. * * May call other collaborating code to generate the response. */ public function handle(ServerRequestInterface $request): ResponseInterface; } ミドルウェアはよくドーナツ型の図で表現されます 前処理や後処理では、実際にControllersやActionに行く前にしておきたい共通処理を書くことが多いですね。 ログの書き込み 認証チェック 共通データの取得 などなど。 もちろん上図のように、ドーナツは二重三重にすることができます。 実際に作成した AuthMiddleware がこちら。 <?php declare(strict_types=1); namespace Nonz250\Storage\App\Http\Auth; use Psr\Http\Message\ResponseInterface; use Psr\Http\Message\ServerRequestInterface; use Psr\Http\Server\MiddlewareInterface; use Psr\Http\Server\RequestHandlerInterface; class AuthMiddleware implements MiddlewareInterface { public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface { // ミドルウェアでしたい処理。ここではDigest認証を行います。 return $handler->handle($request); } } と言っても、まだDigest認証の実装はしていません。この実装については次回の記事で書こうと思います。 前回作成したルートにこの AuthMiddleware を設定します。 $router = new League\Route\Router(); $router ->group('/', static function (League\Route\RouteGroup $router) { // 認証が必要なアクションをここに登録します。 }) ->middleware(new Nonz250\Storage\App\Http\Auth\AuthMiddleware); これで $router->group() で登録したアクションを実行するときに必ず AuthMiddleware が発火します。 認証エラーの場合は例外をスローする実装にしておけばアクションまでは実行されないという寸法です。 ついでにRequestBodyをParseするMiddlewareを作成する フルスタックなフレームワークを利用していないので、 Content-Type が application/json の状態でアクションからRequestBodyを取得するとStringで取得してします。 <?php declare(strict_types=1); namespace Nonz250\Storage\App\Http\Test; use Laminas\Diactoros\Response; use Psr\Http\Message\ResponseInterface; use Psr\Http\Message\ServerRequestInterface; class TestAction { /** * @param ServerRequestInterface $request * @return ResponseInterface */ public function __invoke(ServerRequestInterface $request): ResponseInterface { $response = new Response(); // ここで取得できる$contentsがjson。つまりStringのまま。 $contents = $request->getBody()->getContents(); $response->getBody()->write($contents); return $response; } } Laravelなどのフレームワークなら自動的に配列に変換されていたり、プロパティとして取得できるのですが、それができていません。これだと非常に不便なので、同じようにMiddlewareを用意してその中でRequestBodyをjsonから配列に変換する処理を行います。 ServerRequestInterface には withParsedBody と getParsedBody という関数が実装されていますので、これを利用します。 実際に作成した ParseRequestMiddleware はこちら <?php declare(strict_types=1); namespace Nonz250\Storage\App\Http\ParseRequest; use JsonException; use Nonz250\Storage\App\Foundation\Exceptions\HttpBadRequestException; use Psr\Http\Message\ResponseInterface; use Psr\Http\Message\ServerRequestInterface; use Psr\Http\Server\MiddlewareInterface; use Psr\Http\Server\RequestHandlerInterface; class ParseRequestMiddleware implements MiddlewareInterface { public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface { try { try { $contentTypes = $request->getHeader('Content-Type'); if (count($contentTypes) === 0) { throw new EmptyContentTypeException(); } $contentType = $contentTypes[0]; if ($contentType !== 'application/json') { throw new InvalidContentTypeException(); } $contents = $request->getBody()->getContents(); $parsedBody = json_decode($contents, true, 512, JSON_THROW_ON_ERROR); } catch (EmptyContentTypeException|InvalidContentTypeException $e) { // TODO: ログ記録 throw new HttpBadRequestException($e->getMessage()); } catch (JsonException $e) { // TODO: ログ記録 throw new HttpBadRequestException('Json syntax error.'); } } catch (HttpBadRequestException $e) { return $e->getApiProblemResponse(); } $request = $request->withParsedBody($parsedBody); return $handler->handle($request); } } 一つずつ説明していきます。 $contentTypes = $request->getHeader('Content-Type'); if (count($contentTypes) === 0) { throw new EmptyContentTypeException(); } このコードでRequestHeaderから Content-Type の値を取得します。 取得できない場合は Content-Type が無い旨を示す例外をスローします。 独自に作成した HttpException と HttpExceptionInterface を継承した例外です。 return $e->getApiProblemResponse(); にある RFC 7807 に従ったエラーレスポンスを返す関数を用意しています。 実は league/route にも HttpException は実装されていますが、上記のような独自処理を実装したかったし、 league に依存しすぎるのもどうかと思ったので自前で用意したという流れです。 この件についてもいずれ記事にしたいと思います。 次のコードです。 $contentType = $contentTypes[0]; if ($contentType !== 'application/json') { throw new InvalidContentTypeException(); } このコードは Content-Type の内容が取得できたらその値が application/json かどうかを確認します。 違ったら不適切な Content-Type であることを示す例外をスローします。 $contents = $request->getBody()->getContents(); $parsedBody = json_decode($contents, true, 512, JSON_THROW_ON_ERROR); バリデーションが終了したら実際にRequestBodyを取得します。 json_encode を利用して連想配列へ変換します。このとき、Parseでエラーが発生したら JsonException をスローするように設定しているので、それを catch したらその旨を HttpBadRequestException として投げ直しています。 無事、 $parsedBody を取得できたら、 withParsedBody でRequestクラスに保存しておきます。 $request = $request->withParsedBody($parsedBody); こうすることで、 $contents = $request->getParsedBody(); で連想配列形式で取得できるようになります。 このMiddlewareをRouterに登録しておきます。 $router = new League\Route\Router(); // AuthMiddlewareと違い、全てのルートでONにしておく $router->middleware(new Nonz250\Storage\App\Http\ParseRequest\ParseRequestMiddleware); $router ->group('/', static function (League\Route\RouteGroup $router) { // 認証が必要なアクションをここに登録します。 }) ->middleware(new Nonz250\Storage\App\Http\Auth\AuthMiddleware); 最後に 今回はMiddleware、特に前処理を利用して、認証やRequestBodyの加工の実装を行いました。 連想配列を返すっていうのもまた微妙に使いづらいですが、ひとまずここで良しとしておきましょう。 必要がある場合はまた自前で拡張してプロパティから取得できるように実装すればいいでしょう。...が、その場合は素直にフレームワークを利用したほうが安心できるかもしれませんね。 次回はDigest認証の実装について記事を書こうと思います。 その後に RFC 7807 について記事にする予定です。 そのときはよしなに。 .
S3みたいなストレージサーバーっぽいものを自前で用意する①【ルーティング初期設定】
2022/03/13 2022/03/13S3みたいなストレージサーバーっぽいものを自前で用意する こんにちは。のんです。 実はちょっと前からのんラボのリプレースを考えていまして、ブログに載せる画像のアップロード先について考えていました。 これまではLaravelのデフォルト設定であるプロジェクト内のStorageディレクトリ内に保存していました。 ただ、リプレースする際にこれがかなりのネックになっていて、頭を抱えています。 新しいプロジェクトではキチンとストレージサーバーを用意してそこにアップロードするようにしようと思いました。 S3を検討していたのですが、S3使うだけじゃ何のインプットもアウトプットもできないので自前でストレージサーバーを用意しようと思い立ったのがこの記事を書くキッカケです。 今回からそのためのプロジェクトについて記事にしていきます。 一応、連載記事にしようと思っていますが、他にも書きたい内容（Rustとかチームビルディングとか）があるので、とびとびになるかも。 GitHubプロジェクトはこちら GitHub - nonz250/storage Contribute to nonz250/storage development by creating an account on GitHub. できるだけフルスタックなフレームワークは使わない Laravel CakePHP Symfony Slim などは利用しません。 しかし、自前で用意した生のPHPだけで書くという意味ではなく、laminasのコンポーネントや、leagueのコンポーネントを利用していきます。 https://getlaminas.org/ https://getlaminas.org/を見る The League of Extraordinary Packages The League of Extraordinary Packagesを見る ここでの狙いは、 PSR7やPSR15、RFC 7807やRFC 7807などの仕様、動作の勉強 となります。 何を組み合わせればいいのか。どのような実装になっているのか。 LaravelやCakePHPのドキュメントやAPIリファレンスを読んでいるだけでは得ることができない習慣を習得するため です。 では、早速始めましょう。（今回は触りだけですが...） まずはディレクトリ構成から storage/backendが前提です。 . ├── app │ ├── Adapter │ ├── Domain │ ├── Http │ ├── Provider │ └── Strategy ├── bin ├── tests └── vendor app/Adapter 主にRepository層の具象クラスをまとめる。 他のユースケース層で書きたくないものを逃がす場としても利用するかも。 ちょっと考え方ガバいけども、今の考え方で大丈夫そう。 app/Domain 主にUseCase層をまとめる。他にはEntities/ValueObjectをまとめます。つまり、レイヤードアーキテクチャでいうDomain層も含んでいるということ。 app/Http 主にHttpControllerをまとめる。MVCモデルのCです。 bin 独自コマンドを実行できるようにする予定。 リッチなMigration機能は求めていないので、単純なSQLを実行するためのコマンドや、定期的にファイルを調整するコマンドを用意するつもり。 と、だらだら書いたけども... 兎にも角にもRoutingとHttp Requestを捌きたい 自前のストレージサーバーと言ってもアップロード用のAPIを公開して受け付けるくらいの機能しかないです。この辺がFW（フレームワーク）を利用しない理由でもあります。 league/route https://route.thephpleague.com/ https://route.thephpleague.com/を見る Route is a fast PSR-7 routing/dispatcher package including PSR-15 middleware implementation that enables you to build well designed performant web apps. です。この仕様にあるライブラリを探すことになるのですが、このページで書いてある2つのライブラリを利用します。 laminas/laminas-diactoros GitHub - laminas/laminas-diactoros: PSR HTTP Message implementations PSR HTTP Message implementations. Contribute to laminas/laminas-diactoros development by creating an... If you use Laminas Diactoros project you will also need composer require laminas/laminas-httphandlerrunner とあるので、 laminas-httphandlerrunner GitHub - laminas/laminas-httphandlerrunner: Execute PSR-15 RequestHandlerInterface instances and emit responses they generate. Execute PSR-15 RequestHandlerInterface instances and emit responses they generate. - GitHub - lamina... も入れます。 これらを利用してテスト用のアクションを用意する <?php declare(strict_types=1); include_once 'vendor/autoload.php'; /** * Load dotenv. */ $dotenv = Dotenv\Dotenv::createImmutable(__DIR__); $dotenv->load(); /** * Load environment. */ $env = new Nonz250\Storage\App\Shared\ValueObject\Environment($_ENV['APP_ENV']); /** * Create request. */ $request = Laminas\Diactoros\ServerRequestFactory::fromGlobals( $_SERVER, $_GET, $_POST, $_COOKIE, $_FILES, ); /** * Setting router. */ $responseFactory = new Laminas\Diactoros\ResponseFactory(); $strategy = new League\Route\Strategy\JsonStrategy($responseFactory); $router = new League\Route\Router(); if (Nonz250\Storage\App\Foundation\App::environment(Nonz250\Storage\App\Shared\ValueObject\Environment::LOCAL)) { $router ->group('test', static function (League\Route\RouteGroup $router) use ($strategy) { $router->get('/', static function (): array { return [ 'message' => 'test', ]; })->setStrategy($strategy); $router->get('/hello', static function (): Psr\Http\Message\ResponseInterface { $response = new Laminas\Diactoros\Response(); $response->getBody()->write('<h1>Hello, World!</h1>'); return $response; }); $router->get('/action', Nonz250\Storage\App\Http\Test\TestAction::class); }); } $response = $router->dispatch($request); (new Laminas\HttpHandlerRunner\Emitter\SapiEmitter)->emit($response); 最後に 次回はPSR15を参照して、Middlewareを実装した内容を記事にします。 自分のためのAPIなので、認証が必要です。 Basic / Digestなどが一般的ですが、今回はDigest認証をAPI認証として利用します。 OAuth2の実装までやってみようと思いましたが、流石に時間かかりすぎるなと思ったのでやめました。 AuthMiddlewareについてはまた記事にしたいと思います。 そのときはよしなに。 .
Next.jsのGetServerSidePropsの挙動について
2022/02/11 2022/02/11Next.jsのGetServerSidePropsの挙動について こんにちは。のんです。 Reactは書いたことあるのですが、Next.jsは触ったこと無かったので入門しました。 今回はそこで発見したわかりにくい仕様について備忘録ついでに記事にしたいと思います。 メモ程度で終わってしまいますがご了承ください。 Next.jsのSSGとSSR。前置き。 Next.jsはPreRenderingとServerSideRenderingの2つをサポートしています。 クローラーBotのことなどを考えると、SSR一択かもしれんな。と公式からの回答もあるようにSSR推奨気味ではあるものの、それをどのように動作確認すれば良いものやら試行錯誤していました。 自分的には右クリックからでる「ページのソースを確認」でHTMLの内容が表示されていればSSRできていると考えています。 デフォルトの設定だとSSRできていないようで、どこで切り替えられるのかと調査していました。 Nuxt.jsとは違い設定にSSRモードのフラグ管理も無いようなので、発見時にはなるほど〜といった感想です。 GetServerSidePropsの挙動について 結論としてはGetServerSidePropsの関数をexportしてやる必要がありました。 SSRの処理がない場合でも宣言することでSSRできるようになります。 ここが重要なようで、別段SSR時に特別なfetch処理がない場合でもこいつを宣言することでSSRが可能になるようです。 こんな感じ。（省略とかしてない本当のコード） import {GetServerSideProps, NextPage} from "next"; import {useRouter} from "next/router"; const Article: NextPage = () => { const router = useRouter(); const { id } = router.query; return ( <div> <p>articles</p> <p>{id}</p> </div> ); }; export const getServerSideProps: GetServerSideProps = async (context) => { return { props: {}, }; }; export default Article; このgetServerSidePropsの部分。 処理もしていないし、propsも渡していませんが、このページをSSRするために宣言しています。 いや、そんなことする必要あるの？という話ですが、jsでレンダリングされる以上クローラーに検知され易くするためには必要な処置だと考えています。 具体的な例を書くとこのようになります。 import {GetServerSideProps, NextPage} from "next"; import {useRouter} from "next/router"; const Article: NextPage = () => { const router = useRouter(); const { id } = router.query; return ( <div> <p>articles</p> <p>{id}</p> </div> ); }; // SSRされないようにコメントアウト // export const getServerSideProps: GetServerSideProps = async (context) => { // return { // props: {}, // }; // }; export default Article; とすると、 const router = useRouter(); const { id } = router.query; で取得した <p>{id}</p> の部分がSSRされません。 このコメントアウトをもとに戻すと......SSRされます。 これは const router = useRouter(); const { id } = router.query; がjsの処理であり、PreRenderingされているためソースレベルではhtmlとして出力されていないからだと考えます。 なので、全てをしっかりクローラーに判断してもらうためには、何も処理がなくてもいいので export const getServerSideProps: GetServerSideProps = async (context) => { return { props: {}, }; }; を書いておこうということを発見しました。 最後に 正直、普段触っている方からしたら「何を今更。」という話かもしれませんが、Nuxt.jsユーザーからすると結構珍しいことだったのでメモ程度に記事にさせていただきました。 この「のんラボ」もそろそろ一新するタイミングかなぁ〜と考えています。そのときにはNext.jsを使って一新したいです。 あと、技術記事にするときに「わからなかったこと」や「わかりにくいこと」を中心に記事にしてきましたが、ブログのネタに困ることが多くなってきたので、垂れ流し形式変更しようかなと思い始めています。 まぁこのへんはゆるく考えます。 また記事を書きますので、その時はよしなに。 .
RustでMVC・クリーンアーキテクチャっぽく書いてみた
2022/01/29 2022/01/29RustでMVC & クリーンアーキテクチャっぽく書いてみた こんにちは。のんです。 久しぶりにRustの記事更新です。 何もしていなかったわけではなく、ブログにできるレベルの成果物ができていなかっただけですｗ。 成果物 ※masterブランチで作業しているので、既に色々更新されている可能性があることにご注意ください。 GitHub - nonz250/rust-sample Contribute to nonz250/rust-sample development by creating an account on GitHub. 個人的悩みポイント mod.rsについて Rustはmoduleの考え方あので、modを定義する必要があるのですが、クリーンアーキテクチャを適用するとどうしてもファイル数が多くなります。 その際、 mod.rs というファイルをたくさん作ることになるのですが、これをどうにかスマートに書く方法がないものかなやんでしまいました。 結局、 mod.rs を作りまくるこで対応しましたが、もう少しいい感じに書く方法はありそう。。 今後に期待。 エラーについて Rustをやるにあたって一番最初に躓くところだそうです。 特に私はPHPerなので、例外ガンガン書くタイプのプログラマーでした。 Golangなども普段業務で触っているわけではないので、例外がないプログラミング言語をどのように書けばいいのかめっちゃ困りました。 DBアクセスができなかった...とか、データが存在しないとか、ランタイム系のエラーはWEBアプリには付き物なので、通る前提でコーディングできないのが辛いところです。 例外を投げるというより、エラー型？（ Result 型）を返すという方がニュアンスとして合っていそうなのでそのように実装していますが、エラーのバケツリレーが始まった感出ていてありゃ〜という感じ この問題もどうにかしてスマートに書く方法はありそう。 現在は泥臭くエラー返しています。。。がこの方法も悪くはないのでは？とブログ書きながら考えていたりもします。 PostRepository の実装部分であるこことか fn find_by_id(id: PostIdentifier) -> Result<Post, String> { let connection = establish_connection(); let post = match posts_schema::dsl::posts .find(id.to_string()) .first::<PostModel>(&connection) { Ok(ret) => ret, Err(_err) => return Err("Post not found".to_string()) }; return Ok(Post::new( PostIdentifier { identifier: Ulid::from_string(&post.id).unwrap() }, PostTitle::new(post.title).unwrap() )) } それを呼び出すユースケース、こことかの話。 impl UpdatePost { pub fn process(input: UpdatePostInput) -> Result<(), String> { let mut post = match PostMySqlRepository::find_by_id(input.identifier) { Ok(post) => post, Err(err) => return Err(err) }; post.change_title(input.title); PostMySqlRepository::save(post); return Ok(()); } } ぜーんぶResult返すようになっちゃいました。 ここまででRustいいなって思ったところ 強力な安全性 これはRustに限ったことではありませんが、やっぱり強力な型安全、処理安全なところですね。 ValueObject は採用していますが、これ書く意味ある？（いや、当然書く意味はあるのですが。）と感じてしまうくらい、Rustの仕様を信じてコーディングできるのはすごいなと思いました。 あと、エラー周りも最初は戸惑いましたが、エラーを投げるということすらも 「これくらいのエラーは想定しておけよ」 と言われているようで、 ストイックな言語である ということがヒシヒシと伝わってきます。私は好感持てました。 CQRSでReadModelを実装したときはほぼほぼRustの仕様に乗っからせてもらっています。 #[derive(Serialize)] pub struct PostReadModel { identifier: String, title: String } そのほかの実装部分 pub struct GetPostMySqlQuery {} pub struct GetPostMockQuery {} pub trait GetPostQuery { fn get_post() -> Vec<PostReadModel>; } impl GetPostQuery for GetPostMySqlQuery { fn get_post() -> Vec<PostReadModel> { let connection = establish_connection(); let results = posts_schema::dsl::posts .load::<Post>(&connection) .expect("Error loading posts"); let mut posts = Vec::new(); for result in results { posts.push(PostReadModel { identifier: result.id, title: result.title }) } return posts; } } impl GetPostQuery for GetPostMockQuery { fn get_post() -> Vec<PostReadModel> { return Vec::from([PostReadModel { identifier: Ulid::new().to_string(), title: "mock".to_string() }]); } } serde = { version = "1.0", features = ["derive"] } ただの構造体をReadModelとして定義して、jsonにシリアライズできるようにしています。 これだけストイックなら、コードを短く書こうと書いている側も頑張るはず これは個人の感想ですが、ここまでストイックな言語ですと、書けば書くほどエラーに直面します。 冗長なコードがだらだら書くとエラーに当たりやすくなるので、短く簡潔に必要なものだけを書くように方向性を矯正させられるとも考えました。 とりあえず動けば良かろうをすると、大変な目に合いますねｗ 最後に とはいえ、まだまだ基礎中の基礎しか実装てきていないので、このリポジトリで色々勉強していきたいと思います。 そのほかにUlidのライブラリを導入したりしていましたが、この辺は書くまでもないことなので割愛しています。 多分ここまでくればシンプルなWEBアプリは書けるようになっているはずですが、メールの送信とか、 curl の実行くらいは勉強しておきたい。 「rocket使え」ってのはなしでｗ FW使うと勉強の意味無くなってしまいますから。 また進捗あれば記事にします。 そのときはよしなに。 .
2022年の抱負
2022/01/07 2022/01/072022年の抱負 明けましておめでとうございます。今年もよろしくお願いいたします。 のんです。 遅ればせながら、今年の抱負記事を書いてみました。 自分の作成した今年の抱負メーカーを利用して画像も作成しました！ よかったら使ってみてください！ 今年の抱負メーカー | ツイッターで今年の抱負をつぶやこう！ 今年の抱負メーカー | ツイッターで今年の抱負をつぶやこう！ 時間をフル活用個人アプリを次のステップへ 去年はちょっと色々なことに手を出しすぎてグダってしまったというか、本当にやりたいことに対して時間を割くことができなかったなという反省がありました。 そこで、今年はやりたいことにしっかりと時間を割けるように意識していきたいと思います！ 個人開発したアプリの面倒をあまり見れていなくて、去年のうちにやっておきたかったことも他のすべきことで時間を使ってしまい、未達となってしまいました。 個人開発のアプリに時間をたくさん使って、たくさんの人に使ってもらえるように頑張りたい。 常日頃からそのように思っているので、今年はしっかりと個人アプリに対して時間を使ってあげたいと思っています。 Rust / Golangの勉強 今まで個人アプリをPHPで書いていましたが、ある程度成熟したアプリについてはRustやGoで書き直してみようかなと思っています。 特にこのブログはおかげさまで色々な方に見ていただけているので「もっと早く描画できるようにしたいな」と結構前から思っていたところです。 パフォーマンス的にどのくらい改善されるかはわかりませんが、勉強がてらやってみるのもいいかも。 実は少しずつRustの勉強を初めていたのですが、他のブログなどを見るとGoの勉強から始めてみるのもいいかもとあるのでGoで実装してみようかなと考えを改めて見ようとしているところ。 あとWEBでRustはオーバースペックっぽい？仕事ではGoが主流のよう。 実際にどうなるかはわかりませんが、ひとまずRustでMVCっぽいことをできるようになったのでGoでそれをできるようにしたいと思います。 最後に 今回は今年の抱負記事でした。 数を絞ることで目標を見失わない作戦は果たしてうまくいくでしょうか？ 仕事も頑張りつつ、自分のための一年にできたらと思います！ また記事書きます。 そのときはよしなに。 .
2021年の振り返り
2021/12/26 2021/12/262021年の振り返り こんにちは。のんです。 今回は2021年の振り返り記事になります。 今年も色々イベントがありまして、楽しい年になりました！ ということで振り返っていきます。 会社の業務以外の活動（副業）をたくさんした年 中には途中で止まってしまっているものもありますが多めに見てくださいｗ やはりいちばん最初に挙げられるのは副業ですね。 副業（プログラム開発支援） たまたまとあるサイトで出会った方に「開発の手伝いをしてくれないか」とお声がけいただき、丁度私も探していたところでしたので、協力させていただきました。 その方がとても良心的な方で、技術的にも仕事的にも大変良い思いをさせていただいております。 このブログを見ているかはわかりませんが、本年は大変お世話になりました。引き続き変わらぬお付き合いをさせていただきたいと思っております。 これ以外にも他の方から、ちょっとしたお手伝いに誘っていただくことも多く、大変ありがたいことに本格的に始動した今年から、嬉しい悲鳴をあげさせていただきました🙇 副業（プログラミングレクチャー） こちらは結構前から活動していました。 最初は友達やその知り合いのレクチャーや相談といった感じでしたが、こちらも今年をきっかけに色々な方からお声がけいただき、いつも予約パンパンの状態にさせていただいております。 本当はお断りしている方々にもレクチャーしたいと思っているのですが、本業との兼ね合いで最大同時に2名までと決めているのです。本当に申し訳ない🙇 機会があればまたお声がけいただければと思います。 プログラミングレクチャー系の動画投稿 こちらは完全に止まっていますね... なんとか投稿していきたいですが、動画の作成に時間がかかりすぎる。中途半端なものを出すのもアレなので、一度STOPしているというのが現状です。このあたりはキチンと解決して動画を出していきたい。私は学生向けに投稿していきたいので、簡単なものを短期間で成果が出るような内容で投稿するつもりです。 来年どうなるかは...まだわからない。 名刺代わりのサイトを作りました こういうこともあり、自分のことを紹介することが多くなりました。 ということで、 https://nozomi.bike/ を作成。 こちらから私の情報にアクセスできます。 コンタクトのとり方はまだメールオンリーですが、追々増やしていくつもりです。 よかったらTwitterも覗いてみてください。このサイトに掲載しています。 お仕事も頑張った年 去年ももちろん頑張ってましたが、今年はベクトルを変え、社外の方々に会社のことを知ってもらうために、自分のTwitterで社内のことをつぶやき始めた年でもあります。 TwitterのDMから何回かアプローチが届くこともありましたし、そこそこ貢献できているでは？ あとは自分のプロダクト絡みで、顔と名前だして動画を投稿したりもしました。 作るのを頑張ったというより、知ってもらう努力をした年。という感じですね。 バイク乗り換えた これは比較的最近の話ですが、５年ほど乗ったバイクを乗り換えました。 これは感慨深かった... 愛車を手放すのがこんなに喪失感あるとは... まぁその代わりバルカンSという新しい相棒に出会えたわけですけどもね！ｗ 来年も乗って乗って乗りまくります！！ 最後に こう見ると割と仕事人間なのかもしれん。 でもPCの前に居るか、バイクに跨っているかとどちらかなので、間違っていないかｗ ついに確定申告が必要な規模になったので、戦々恐々としています。 来年は一発目は今年の抱負メーカーを利用したつぶやきにしたいなという思いです。 またお会いしましょう！ その時はよしなに。 .
バルカンSを納車しました！
2021/12/12 2021/12/12バルカンSを納車しました！ こんにちは！のんです！！ バルカンSを納車しました！ 前々から気になっていたクルーザータイプのバイクです！ 株式会社カワサキモータースジャパン 株式会社カワサキモータースジャパンのオフィシャルウェブサイトです。モーターサイクル、ジェットスキー、ドリームプラス、汎用ガソリンエンジンなど、カワサキブランド製品の製品情報、購入サポート情報をご紹介し... 実は結構前から乗り換えは検討していた。 やっぱり、２５０ccは軽い。高速ではおもちゃみたいにどっかすっ飛んでいきそうで怖かったのです。 もちろんZ250はいいバイクで街乗りや峠のツーリングはとても楽しいです。 でもそろそろ大排気量のバイクも乗ってみたいなでもリッターバイクはでかすぎるし乗らなくなってしまいそう。ということでZ650やZ900を候補にあげていました。しかしまたタイプの似ているバイクはどうなのか。。。ということで。。。↓ 前乗っていたZ250とは全く別のタイプを選択しました これまでのZ250 前乗っていたのはZ250。ストリートファイターという見た目が尖っているスポーツタイプのバイクといったところです。 こんな感じです。結構尖っているバイクかと思います。 でも見た目の割に軽量で取り回しが簡単なので、女性人気が高いバイクでもあります。 あと、めちゃくちゃコアなファンが多いことでも有名ですｗ 新しく納車したバルカンS めちゃくちゃマッシブ。クルーザータイプではありますが、バルカンS（このSはSportのSだそうです）と呼ばれるだけあり取り回しがスポーティーな味付けです。ドコドコというエンジン音も控えめなので、ライトにアメリカンタイプのバイクに乗りたい方にはオススメかもしれません。 足つきも抜群。何ならZ250よりもいいまであります。まぁクルーザーですし。 重心が低いので人馬一体のような乗り方はとても難しい。ニーグリップもできない（いや、できるんだけど、するとダサいｗ）のでコーナーは要注意ですね。 しかし、その分ロングツーリングでは力を発揮します。優れた安定性にパワーもあるし、乗り心地も最高です。積載性能は相変わらずなしですが、サイドバック装備を前提にしているので思ったより載ります。 スポーツタイプから乗り換えるために装備も一新した どうですかね？ 乗り心地の違い やっぱり重い 押し歩きは考えたくないですね。重心が低いのもあって押して歩くと転けそうです。 転びそうなときに復帰するのも大変そう。。。 重さのおかげで高速巡航が快適。 ちょっとした風や衝撃で車体が揺れません。どっしりと走れるのはとても快適です！ 足を投げ出すタイプ 足が真下に下ろすのではなく、前に投げ出すタイプなのでバイクで立つことができません。 注意して乗らないと結構、腰に来るバイクかもしれませんｗ それでも他のバイクよりはふかふかなのは嬉しい。 前傾姿勢というより前屈姿勢。ポジションの調整は必要になるかも。体が硬い人は試乗してみてください。 背もたれをつけるとめちゃくちゃ違いそうｗ今度試してレビューしてみます。 最後に とまぁこんな感じで全然違うタイプのバイクに乗ってみる。。というのもいいですね。 この週末は完全に体調不良で死んでました。2日も寝込んだのいつぶりだろうか。口の中が風邪の味がするｗ 次回は今年の振り返り記事、その後に今年の抱負記事になりそうですね。 また書きます。そのときはよしなに。 .
自己紹介ページ（ポートフォリオサイト）を一新した話
2021/11/28 2021/11/28自己紹介ページ（ポートフォリオサイト）を一新した話 こんにちは。のんです。 今回は自分のポートフォリオサイトを一新した話です。 今回作成したポートフォリオサイト Nozomi Hosaka https://nozomi.bike 結構前からポートフォリオサイトは用意していた。 それがこちら https://portfolio.nozomi.bike/ こちらは完全に自作のhtmlとjsとCSSのみ。 モーダルなども全て自作となっていますが、機能重視で正直ダサかったので、一新しようと思っていました。 新しいサイトはどのような構成か？ NuxtでSSGしています。 やっぱりポートフォリオサイトは静的なもので十分なので、SSRに対応できるように作成していたり、環境もDockerのコンテナで起動できるように調整済みですが、インフラ周りはそこまで用意せず、ただ単にSSGで生成したものを配置しているだけです（手抜き） このブログもサーバーやバックエンド（PHPではなく違う言語など、）丸ごと変えたいと思っているので、そのタイミングで、このポートフォリオサイトも構成が変わることでしょう。 ひとまず、サイトとしてやりたいことはできているので及第点としたい。 地味に自分の名刺代わりになるサイトが存在しなかったので、年内のうちに用意できたのは大きいなぁと感じています。 新しいサイトでやりたかったこと せっかくドメイン登録している（nozomi.bike）のに、このドメインにふさわしいサイトが無かった。 これまでの制作物のまとめが全然できていなかったので、そのピックアップとその見せ方を整えたかった。 自分の名前や顔を公開してもいいと思った。 お仕事の受付ページを作りたかった。 この辺を静的サイトではできないので、今後改善予定 といった感じでしょうか？ ポートフォリオというと初学者の面接対策のように考えられがちですが、イチプログラマーとして名刺のように使用したいという側面が強いですね。 最後に 現状はただの１枚のページですが、ここに書ききれない成果を上げられるようにがんばります。 Nozomi Hosaka https://nozomi.bike よかったら見てください。 あと、ブログの更新や今年の抱負メーカーの更新もしなきゃなと思っています。 また記事にするので、そのときはよしなに。 .
WSR-5400AX6Sのネットの速度が異常に遅いときの対策法
2021/09/12 2021/11/14WSR-5400AX6Sのネットの速度が異常に遅いときの対策法 こんにちは。のんです。 5年位使った無線LANを買い替えたときにネット回線が遅くなっちゃいました。 それについて記事にしていきたいと思います。 前回まで利用していた無線LANルーター「WSR-1166SHP2」 WSR-1166DHP2 : Wi-Fiルーター : AirStation | バッファロー Wi-Fiルーター WSR-1166DHP2の商品情報サイト。バッファロー公式情報です。 正直、賃貸で利用するレベルのネット回線ならこのレベルでも十分でした。一人暮らしですので、家もめちゃくちゃ広いわけではありませんので、性能的に無問題。 しかし、5年間も利用してきた経緯からか、度々再起動がかかるようになってしまいました。しかもインターネットから切断されることもしばしば。 そろそろ新調しようかということで購入を決意。 この子は中古屋さんに売ろうかなと思います。 今回購入した「WSR-5400AX6S」 WSR-5400AX6S-MB : Wi-Fiルーター : AirStation | バッファロー Wi-Fiルーター WSR-5400AX6S-MBの商品情報サイト。バッファロー公式情報です。 この子が問題児でした。というか、最近のBuffalo製の無線LAN全般ですね。 なんと、最新モデルにも関わらずネット回線が激重。 アップロード0Mbps いや、流石にない というか、他の作業でアップロードはできているので、何かの要因があるはず。 めちゃくちゃ調べた。 結論 ネット脅威ブロッカーをOFFにしました。 いや、ありがたいけどアップロード0はない。 切った瞬間ネットのレスポンスがめちゃくちゃ良くなりました。 セキュリティ的に不安がある場合は各デバイスにセキュリティソフトを入れておくべきでしょう。 これにて解決。 最後に WSR-5400AX6S、上記の問題以外はいい商品でした。 WSR-1166SHP2より若干レスポンス良くなりましたし、パワーも向上しました。 去年からリモートワークをガッツリするようになって、そのうち買い替えたいと思っていたことが叶って嬉しいです。 のんラボでは基本的に技術記事を書いています。今回は例外ですが、ガジェット系なので許してね。 また書きます。 その時はよしなに。 .
