vscode copilot chat の言語設定
"github.copilot.chat.localeOverride": "ja",
apache, ajp, tomcat
リバースプロキシとはなんですか?
リバースプロキシ(Reverse Proxy)は、クライアントと複数のバックエンドサーバーとの間に配置されるサーバーの一種です。通常のプロキシサーバーとは異なり、リバースプロキシはクライアントから受け取ったリクエストをバックエンドサーバーに転送し、バックエンドサーバーからのレスポンスをクライアントに返す役割を果たします。
以下はリバースプロキシの主な特徴と用途です:
クライアントとバックエンドサーバーの間に挟む役割: リバースプロキシはクライアントと複数のバックエンドサーバー(通常はウェブサーバー、アプリケーションサーバー、またはコンテンツ配信サーバー)の間に配置されます。クライアントはリバースプロキシを通じて通信し、リバースプロキシが適切なバックエンドサーバーにリクエストを転送します。
負荷分散: リバースプロキシは負荷分散を実現するために使用できます。クライアントのリクエストは複数のバックエンドサーバーに均等に分散され、トラフィックの負荷を分散することができます。これにより、高い可用性とスケーラビリティが実現されます。
セキュリティ: リバースプロキシはセキュリティの境界を形成し、バックエンドサーバーを直接公開しないため、セキュリティの強化に役立ちます。クライアントからのリクエストを検査し、不正なトラフィックや攻撃を検出・ブロックすることができます。
SSLオフロード: リバースプロキシはSSL/TLS暗号化を処理することができ、バックエンドサーバーからの負荷を軽減します。これにより、バックエンドサーバーは暗号化解除されたデータを処理する必要がなくなり、パフォーマンスが向上します。
キャッシング: リバースプロキシは一時的にデータをキャッシュすることができ、再リクエスト時にキャッシュからデータを提供することができます。これにより、静的コンテンツの高速な提供や、負荷軽減が可能です。
リバースプロキシは、ウェブサービスやアプリケーションの運用において重要な役割を果たし、セキュリティ、パフォーマンス、可用性の向上に寄与します。代表的なリバースプロキシソフトウェアにはApache HTTP Server、Nginx、HAProxyなどがあります。
Apache、AJP、Tomcat、Strutsの関係性をそれぞれ説明してください
Apache: Apache HTTP Serverは、ウェブサーバーソフトウェアで、HTTPリクエストを受け取り、それに対するレスポンスを返す役割を担います。Apacheは静的なコンテンツの提供、リバースプロキシとしての機能、セキュリティ、ロードバランシングなどを提供します。
AJP(Apache JServ Protocol): AJPは、Apache HTTP Serverとアプリケーションサーバー(ここではTomcat)間での通信プロトコルです。AJPは通常、高性能なJavaアプリケーションサーバーと連携するために使用されます。ApacheとTomcat間でAJPを介してデータの受け渡しを行い、リバースプロキシとしてApacheがTomcatにリクエストを転送するために利用されます。
Tomcat: Apache Tomcatは、Java ServletとJavaServer Pages(JSP)を実行するためのオープンソースのアプリケーションサーバーです。Tomcatはクライアントからのリクエストを受け取り、JavaベースのWebアプリケーションを実行し、レスポンスを生成してApacheなどのウェブサーバーに返します。ApacheとTomcatを組み合わせて使用することで、静的なコンテンツはApacheが処理し、ダイナミックなコンテンツはTomcatが処理することができます。
Struts: Apache Strutsは、JavaベースのWebアプリケーションフレームワークです。Strutsはアプリケーションのコントロールフロー、ビューの表示、ユーザーからの入力の受け取りなど、Webアプリケーションの開発をサポートします。StrutsはTomcatなどのJavaアプリケーションサーバー上で実行され、
■
通常インデックス作成時には、テーブルに対して書き込みロック
→ マルチテナントの場合は?
INDEX CONCURRENTLY
PostgreSQLはテーブルを2回スキャンしなければなりません。 さらに、潜在的にそのインデックスを使用する可能性がある、実行中のすべてのトランザクションが終わるまで待機しなければなりません。 したがって、この方式は通常の方式よりも総作業時間がかかり、また、完了するまでの時間が非常に長くなります。 しかし、インデックス作成中に通常の操作を行い続けることができますので、この方式は運用環境での新規インデックス作成に有用です。 もちろん、インデックス作成によりCPUや入出力に負荷がかかりますので、他の操作が低速になる可能性があります。
絶対にテーブル全体インデックス張り直しになるの?
例えば、TENANT_ID
, STATUS
の複合インデックスを作成したテーブルにINSERT
した場合、
TREEの一部に追加されるだけのイメージだが、他テナントに影響はありますのん?
複数検索条件(A
, B
, C
)があるとき...
idx_tenant_id_A
: (tenant_id
,A
)idx_tenant_id_B
: (tenant_id
,B
)idx_tenant_id_C
: (tenant_id
,C
)
のインデックスを作成すると?
SELECT * FROM table_name WHERE TENANT_ID = 1 AND A = "A" AND C = "C"
みたいなクエリはどうなる?
- テーブル内のデータ量が多く、少量のレコードを検索する場合
- WHERE句の条件、結合の条件、ORDER BY句の条件として頻繁に利用する
わかってません
This job is stuck because the project doesn't have any runners online assigned to it.Go to project CI settings
jobは実行されるがずっとpending
ts array undefined 除去
array.filter((i): i is Exclude<typeof i, undefined> => i !== undefined);
認証についての知識がほぼゼロなので... #01
認証についての知識がほぼゼロだったので触る
現場でJWTという認証方式が採用されたので、ちょいとお勉強しておく
ざっくり
- 公式サイト
- 仕様 - RFC7519
- 正式名称を JSON Web Token という
- 発音は"ジョット"らしい
- トークンベースの認証
トークンベースの認証とは、ユーザーが自分のアイデンティティを確認し、代わりに一意のアクセストークンを受け取ることを可能にするプロトコルです。トークンの存続期間中、ユーザーはトークンが発行されたWebサイトやアプリにアクセスできます。同じトークンで保護されたWebページ/アプリ/リソースに再度アクセスするたびに、資格情報を再入力する必要はありません。
毎回、IDパスワードで認証する必要はありませんよ〜と
なんか検索してると「JWT 認証 使うな」とかでてくるが、
正直認証まわりの知識がゼロに近いので、メリットデメリットがよくわからない
ので一旦JWTを勉強する。
(なんかしらの脆弱性とかがあるのか?わからない...
とりあえずのざっくりイメージ
認証
/** * Synchronously sign the given payload into a JSON Web Token string * payload - Payload to sign, could be an literal, buffer or string * secretOrPrivateKey - Either the secret for HMAC algorithms, or the PEM encoded private key for RSA and ECDSA. * [options] - Options for the signature * returns - The JSON Web Token string */ export function sign( payload: string | Buffer | object, // Claim?? secretOrPrivateKey: Secret, // 秘密キー options?: SignOptions, // なんやかんやのオプション ): string;
次回接続時
/** * Synchronously verify given token using a secret or a public key to get a decoded token * token - JWT string to verify * secretOrPublicKey - Either the secret for HMAC algorithms, or the PEM encoded public key for RSA and ECDSA. * [options] - Options for the verification * returns - The decoded token. */ export function verify(token: string, secretOrPublicKey: Secret, options: VerifyOptions & { complete: true }): Jwt | string; export function verify(token: string, secretOrPublicKey: Secret, options?: VerifyOptions): JwtPayload | string;
デコードされたものが返却される、この時返されるのが、生成時に使用したpayload: string | Buffer | object, // Claim??
?
3.アクセストークンが期限切れの場合、リフレッシュトークンを検証するらしい(この辺はまた後で調べる必要ありそう
4.なんやかんや新しく生成されたトークンを返却する
アクセストークンが期限切れの場合
アクセストークンが期限切れではない場合
受け取ったアクセストークン / リフレッシュトークンをそのまま返却する
大まかな流れはこんなところ?
クライアント側の動きがよくわからないので、次はそのあたり
todo: ts配列からundefinedを除去したときの型推論について
.filter((item): item is Exclude<typeof item, undefined> => item !== undefined);
ts todo
todo
const hoge = (inHoge1: any) => (inHoge2: any): any => `