BASIC認証の特徴

https://jp.quora.com/BASIC%E8%AA%8D%E8%A8%BC%E3%81%AF%E3%81%A9%E3%81%AE%E3%81%8F%E3%82%89%E3%81%84%E5%AE%89%E5%85%A8%E3%81%A7%E3%81%99%E3%81%8B
https://medium-company.com/http%E8%AA%8D%E8%A8%BC%E6%96%B9%E6%B3%95%E3%81%AE%E7%A8%AE%E9%A1%9E%E3%81%A8%E9%81%95%E3%81%84/
https://ks888.hatenablog.com/entry/2016/05/10/130949
BASIC認証https通信で使うならそこまで危険ではないが、牧歌的な認証手法であるのは確か。
Basic認証の改善版として、IDパスワードをハッシュ化して送信するDigest認証というもある。

  • 平文でパスワードを送る?

httpsで通信する場合は経路自体が暗号化されているので、暗号化された状態で送られる。
httpだと平文で送られる。

httpsで通信する場合はhttpsリプレイ攻撃耐性を持っているので、リプレイ攻撃も成立しない。
httpだと駄目。
Digest認証だとこの欠点は改善されている。(サーバ側で生成したランダム文字と通信回数をハッシュ生成に使う)

  • リクエスト毎にIDとパスワードを要求する?

実際には通信ごとにIDとパスワードを送っているが、1度ログインするとブラウザを終了するまではブラウザが自動的にそれを送ってくれるので初回のみIDとパスワードを要求される。

  • ログアウトできない?

できない。
ブラウザが自動的にIDとパスワードを送るのを止めるには、一度ブラウザを終了させるしかない。

javascriptのbreakはブロック脱出た多重for脱出ができる

https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Statements/break
今まで知らなかったがJavaScriptのbreakとcontinueはブロック名を指定して、そのブロックを抜けるという動作が出来るようだ。

hoge_block: {
  console.log("hoge");
  break hoge_block; // ブロックを抜ける
  console.log("fuga");
}

fuga_for: for(var fuga=0; fuga<10; fuga++) {
  piyo_for: for(var piyo=0; piyo<10; piyo++) {
    console.log("fuga piyo");
    break fuga_for; // 多重ループを抜ける
  }
}

ちなみにC#C/C++ではこの構文は使えない。
Javaにはこの構文があるのでどうもそれを引き継いだっぽいが、知ってる人は少ないと思うので積極的には使いたくない構文。

KD - Knockdown

https://www.daiwabutsuryu.co.jp/useful/words/knockdown-system
物流用語の「ノックダウン」は、部品または半完成品の状態で輸送し、現地で組み立てる生産・物流の方式のこと。
海外に輸出する場合、部品の方が積載効率が良く関税が安いのでこのような方式が利用される。

珪素「異修羅」WEB版

https://kakuyomu.jp/works/1177354054882641261
読了。
「異能最強トーナメント」を、参加者を推薦する人物たちの試合前から始まっている政治闘争まで含めて描く意欲作。
ただ政治闘争の面を丁寧に描くことで、実際正面から戦ったら絶対負けてるじゃんという奴が多く勝ち抜けている状況に不満が無いと言ったら嘘になる。「全員が最強」というキャッチコピーに偽りは無いが、その分最強を引き立てるための噛ませ犬が居ないので、最強を発揮させないまま敗退していく対戦が多いのである。
読み手としては、【死んで】の詞術を情け容赦無く使う世界詞のキアを攻略してほしかった。
2019年で未完のままWEB版は停止しており、書籍版もまだWEB版の最新場面まで到達していない状況のようだ。

分散型アイデンティティ(DID - Decentralized Identifier)

https://qiita.com/kazuhideYS/items/2f533bf14e8587c7c131
メールアドレスのように世界で一意なID。W3Cで定義されている。
ただしメールのようにどこかのサービス事業者が預かって一元管理する、というようなことはしない。
"did:"固定のスキーム、IDの管理手法を示したメソッド("web:"など)、そのメソッドで管理されるID……の3パートで構成されるURI文字列。
例「did:web:example.com#key-0」。
WebのURIDNSによって何らかのリソースに名前解決されるように、DIDは、DID Documentという構造化ドキュメントに名前解決される。DID DocumentにはDID自体・認証用公開鍵・DID主体との対話手段(=サービスエンドポイント)といった情報が記述されており、そのDID主体とどのようにコミュニケーションをすればよいかという説明書になっている。
似た言葉として、自己主権型アイデンティティ(SSI)がある。