低い断熱性なぜ放置、世界に遅れる「窓」後進国ニッポン: 日本経済新聞
https://www.nikkei.com/article/DGXMZO78836460U4A021C1000000
Posting らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)
低い断熱性なぜ放置、世界に遅れる「窓」後進国ニッポン: 日本経済新聞
https://www.nikkei.com/article/DGXMZO78836460U4A021C1000000
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
“日頃の行い” を感じられてとてもすき
kb氏は日頃が日頃なので、注釈がないとマジで「そんなにカロリー使うほど抜くのかよ……」となります
そういえばめちゃくちゃどうでもいい話をするんですけど
「イく」とか「ヌく」みたいな隠語系の動詞で接尾辞の「く」を片仮名にする派と平仮名にする派があって、私は平仮名にするべきだと思ってるんですが、これは動詞が活用するとき片仮名部分 (いわゆる語根？) が変化するのはちょっとおかしいのではないかと考えるからです。
「イク / イカない」よりは「イく / イかない」の方が自然じゃないですか？
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
並列と言ってないだけ良しとしよう (???)
This account is not set to public on notestock.
ごはん食べたのでオカズ食べてるとかかな (?)
This account is not set to public on notestock.
これは純粋に Mastodon や twitter の自動リンク化が最悪すぎるので、どうしようもないと思っている
(本来ならば明示的にリンクを指定するか、 <uri> のような明示的な形を <a href="uri">uri</a> とかに変換するような仕組みであってほしい)
Mastodon はまだマシな方だけど Twitter がドメイン名っぽいのを勝手にリンクにするのはマジでくたばれと思う
ドメイン名のリンク化だと、特定拡張子を持つファイル名が全滅するので本当に厳しい (.rs とか .sh とか)
LinkHeader - W3C Wiki
https://www.w3.org/wiki/LinkHeader
私が知ったのは HTTP 由来 (初出がどこかは知らない)
RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1
https://tools.ietf.org/html/rfc2068#section-19.6.2.4
1997-01
RFC 1945 - Hypertext Transfer Protocol -- HTTP/1.0
https://tools.ietf.org/html/rfc1945#appendix-D.2.6
HTTP/1.0 時点では Link header は additional であって構文の詳細とかは書かれていないな
（CV：安済知佳）
zabuton1mai@maho.app
This account is not set to public on notestock.
（CV：安済知佳）
zabuton1mai@maho.appThis account is not set to public on notestock.
色々な知見を自鯖に立てた Media Wiki 上に集積しているのですが，「お前用勉強しとるな…」と過去の自分にいろいろと教えられる事案が発生した
自分用 MediaWiki、昔 RasPi の Arch 上に立てていたんだけど、何が悪かったのかレスポンスに毎回8秒くらいかかる最悪のアレで、しかも Arch なのでパッケージのビルドが時折発生してあっというまに SD カードが死んだ
自分用静的サイトジェネレータと自動デプロイ、はよ作りてえな…… (いま全然関係ないもの書いてる)
それ以前の問題で、そのアーキテクチャ用のバイナリが配布されていない場合、ローカルでコンパイルが走るので一時ファイルの読み書きで大変なことになる
(tmpfs 使うにしてもメモリがね……)
男は何かにつけ悪者扱いされるので、自衛のために避けてるのはあると思う……
@cmplstofB どうでしょうね……そもそも pacman / yaourt の設定には全然詳しくなかったのでコンパイラオプションは全く弄りませんでした
普通の web サービスにありがちな感じで (Basic 認証でなく) HTML フォームでログインの認証をする場合、ログイン失敗したとき 401 Unauthorized を返せなくない？
というのも、 401 を返すなら WWW-Authenticate ヘッダが必須なんだけど、オレオレログインページに対応する challenge がないので……
rest - What WWW-Authenticate header should a http server return in a 401 response when using form-based authentication? - Stack Overflow
https://stackoverflow.com/questions/48408530/what-www-authenticate-header-should-a-http-server-return-in-a-401-response-when
つらいなぁ
ブラウザで bearer token って使えたっけ？
単に使えるだけでなく、 Cookie のようにログイン後のどのような GET / POST リクエストについても自動的に Bearer token が付いてほしいんだけど、ブラウザにそんな仕様があるか微妙な気がするので調べている
この用途の場合には Cookie に bearer token を入れといて(もちろん httpOnly secure でね)、サーバー側でその Cookie を Authorization として介錯する実装が主流かも
私もそう思ったので cookie に暗号化した bearer token を突っ込む実装にしてたんですが、そこで 401 Unauthorized が WWW-Authenticate ヘッダを必要とする問題に遭遇したわけです
なおクライアントサイドのスクリプトは使いたくない、オタクなので
ﾌﾑｰ
403 Forbidden も違う気がしてて、というのもこれは認証が成功したうえで権限がないことがわかっているという意味っぽいので、認証が失敗した場合に使うものではない
302 Found はかなりモヤっとするな……
302 Found - HTTP | MDN
https://developer.mozilla.org/ja/docs/Web/HTTP/Status/302
そもそも 302 によるリダイレクトは method を変更しないことになっているから、 /login への POST が失敗したとき 302 で /login に POST リダイレクトさせるのはかなり嫌な感じがする
Grafana のログイン認証は 401 で返ってきてるけど WWW-Authenticate ヘッダは付いてないね
RFC 7235 - Hypertext Transfer Protocol (HTTP/1.1): Authentication
https://tools.ietf.org/html/rfc7235#section-3.1
> The server generating a 401 response MUST send a WWW-Authenticate header field (Section 4.1) containing at least one challenge applicable to the target resource.
ログインページでのログイン妊娠レスポンスは各フレームワークで思い思いに実装されているらしい
個人的には ログインページが 401 を返すとまるでログインページそのものに認証が必要という印象を受ける
根本的にはブラウザの HTTP 規格カバー度が低すぎるのが悪いと思っている (DELETE / PUT / PATCH 然り、 Bearer authentication 然り)
Bearer token がちゃんと HTTP ヘッダで扱えれば、ブラウザと REST クライアントを一緒くたに扱えるのに……
401 はターゲットのリソースそのものに認証を個別にかけて妊娠した場合という感じがいたしますわね
まあ遺伝子情報が入ってるし精液は credentials みたいなところがある (は？)
私の解釈としては 400 Bad Request は syntax error で、422 Unprocessable Entity は semantic error という認識
リクエスト本体以外についての諸々のトラブルが 400 と 422 以外で表現されていて、認証失敗も権限不足もその枠に入るので、いずれも別の status code が割り当てられていて然るべきなんだけど
それかオレオレ WWW-Authenticate とそれに対応したブラウザを両方自作するというウルトラ C がある
本文が解釈できない=>415
本文の構文に問題がある=>400
構文は正しいけど要求に一致しない=>422
415 については Content-Type や Content-Encoding が引き合いに出されることから、単に未知のフォーマットであるという解釈 (構文的に正しいかどうか判定する能力がない)
そういえば 300 Multiple Choices は
ttps://www.w3.org/TR/xhtml11/DTD/xhtml11.html
以外で見たことがないんだよな
まあapplicaton/json期待してるのにapplication/xml(text/xml?)できたりしたときとかに返すよね
text/javascript に対して application/json なの微妙に納得いかないんだよな……
文法ではなく意味論の問題だから (たとえば PNM は ASCII テキストで記述できるけど image/x-portable-pixmap)
> javascript - OBSOLETED in favor of application/javascript
https://www.iana.org/assignments/media-types/media-types.xhtml#application
ほんとだ
解釈に何らかのアプリケーションを要求するという点でいくと text/plain 以外虫の息になってしまうな
text/* は人間用文書かつテキストフォーマットであるくらいの認識でいる
MIME タイプ (IANA メディアタイプ) - HTTP | MDN
https://developer.mozilla.org/ja/docs/Web/HTTP/Basics_of_HTTP/MIME_types
> テキストのみのデータで、人間が読むことができるあらゆるコンテンツ、ソースコード、コンマ区切り値 (CSV) 形式のデータのようなテキストデータを含みます。例えば、 text/plain, text/csv, text/html などがあります。
text/csv がありなのか……だったら text/json もありな気がしてきてしまうな
ソースコードは納得できるけど (人間が読むものなので)、 CSV はちょっとモヤっとする
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
これ警察に通報して何日で消えるか予想するゲームができそう
This account is not set to public on notestock.
This account is not set to public on notestock.
こういうの仮に偽造申請したら金と個人情報だけ吸われてトンズラこかれるやつっぽそう、ついでに抜かれた情報が悪い商売の人に渡りそう。
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
“同課によると、同容疑者はＨＰを２００８年から開設。ネットで注文を受け付け、免許証１０万～２０万円、卒業証明書２０万円、学生証１２万円などで販売。１１年６月からの１年間で１千万円以上を売り上げていたとみられる。”
「証明屋」を再逮捕、免許証や卒業証明書偽造し販売容疑／神奈川 | 社会 | カナロコ by 神奈川新聞 https://www.kanaloco.jp/news/social/entry-111756.html
生体認証を単体で使うことに対する私の反感は大体「本人がそこにいれば同意がなくても認証できる」と「十分な精度で複製されたら交換できない」で説明できる
パスワードを頻繁に変更しろと言っている人々が理由のひとつとして「攻撃にかけられる時間を減らすことで云々」というのを挙げている場合、生体認証で使う情報が変更不可能で攻撃可能な期間が長いことについてはどう考えてるんだろう
「パスワードを頻繁に変更しろ」と「多要素認証 (生体認証を含む) を使え」というのはちょっと無理がない？
一応「弱点の違う認証方式を複数組み合わせることで……」みたいな言い訳はできるけど
既知で今まさに回避しようとしている弱点を持つ認証を後から加えて、セキュリティが向上すると主張していることになると思うんだけど……
This account is not set to public on notestock.
それ BSD ユーザの前で同じこと言えるか？
This account is not set to public on notestock.
