はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事では reCAPTCHA v2 と v3 の違いについて説明します。 reCAPTCHA v2 には、Invisible、Checkbox、Android の3種類があります。この記事では v2 Invisible を主に扱います。Checkbox は「私はロボットではありません」のチェックボックスを見せるタイプ、Android はアプリに組み込むタイプで、これらを使いたい場合は、特に迷うことはないと思います。 https://developers.google.com/recaptcha/docs/invisible v3 は

REST API の呼び出し結果を、集中的に何度も使いたいような場合、API のレスポンスをキャッシュするのではなく、Promise をキャッシュすることで、API が 1 回だけ呼ばれることを保証できます。 何もキャッシュしない場合 まず最初に、何もキャッシュしない場合を見てみます。 import axios from 'axios' class App { /** * API に GET リクエストを送信するメソッド。何もキャッシュしないバージョンです。 */ async request(url) { return await axios.get(url) } /** * API を使ってなにかするメソッドです。 */ async doSomethingWithAPI(url, index) { const result = await this.request(url) consol

Emacs から VSCode への移行は大した苦労もなかったのですが、Explorer でディレクトリツリーからファイルを見つける操作には、どうしても慣れることができませんでした。 (どうやるのかいまだによくわかっていません、、) dired を再現する拡張も試してみて、よく出来ているとは思ったのですが、自分にはいまひとつしっくり来ませんでした。 ダメ元で統合ターミナルで Emacs を起ち上げて dired を使うようにしてみたら、非常によい感じだったので、その方法のご紹介です。 dired から VSCode を開けるようにする まず、dired から VSCode を開けるようにします。.emacs.d/init.el に以下を追加します。 ; dired で c キーで VSCode を開く (define-key dired-mode-map (kbd "c") 'open-v

メチャクチャにめんどくさいです…… 他の手段 2019/10 に Instagram Basic Display API というのが出たようですが、トークンの有効期限が1時間だそうなので、サイトに画像を埋め込むような用途には使えません。 https://developers.facebook.com/docs/instagram-basic-display-api/ https://webty.jp/staffblog/production/post-2234/ 参考にした記事 https://arrown-blog.com/instagram-graph-api/ こちらの記事が詳しく、非常に助かりました。 以下は、上の記事を読む前提での補足です。 構成 次のような構成にします。 ダミーの Instagram アカウント、Facebook ページを使う Instagram へのアクセス権

ただし、ユーザにデバイス名を正しく入力してもらう必要があり、運用は難しくなります。IAM の MFA を削除しても時間稼ぎにしかならなそうな気もします。 初期ユーザ用・MFA 設定済みユーザ用ポリシー ポリシーを2つ作ります。 MFA 無しでもパスワードリセットできるポリシー (初期ユーザ用) パスワードリセットにMFA が必要なポリシー (既存ユーザ用) 最初は1のポリシーを設定し、ユーザが MFA の登録を終えたら2に切り替えます。 1. 初期ユーザ用ポリシー 公式ドキュメントのポリシーに、冒頭に書いた、パスワード変更を許可する修正と、デバイス名を制限する修正を行います。JSON は以下のようになります。 (実際に設定するときは、公式のドキュメントからコピペして編集してください) { "Version": "2012-10-17", "Statement": [ { "Sid": "A

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

CloudFront に SSL を入れる際に気をつける項目のまとめです。 2017年9月時点では、特に S3 との連携で大きな制約があり、将来的には改善されていくのではと思います。現在の状況を確認してください。 (2017/10/26 追記) Lambda@Edge で S3 の制約を回避できるようになりました。こちらの記事を参照してください。 SNI か専用 IP か まず、ブラウザと CloudFront 間の通信で、SNI (Server Name Indication) が使えるかどうか検討します。 ガラケーやWindowsXP の IE は SNI に対応していません。これらの古い環境でサイトが見えなくても構わないかどうかを確認します。 SNI 非対応のブラウザに対応するには、専用 IP を使う必要があります。専用 IP は $600/月かかります。 https://aws.a

基本的に想像通りなのだが、Whitelist の Set-Cookie の扱いだけ例外的で、ホワイトリストに関わらず全てのクッキーをビューアに返す。 なので、Whitelist で制限しているつもりでも、例えばセッションIDがキャッシュで配信されてしまうことに注意が必要。場合によっては、とても危険な状態になり得る。 ドキュメントは以下のように書かれている。 ホワイトリストにない Cookie がオリジンからの応答に含まれている場合、CloudFront はその Cookie もビューアに返します。 一方で、以下の説明もあり、矛盾しているように思えるのだけれども、 オリジンがホワイトリストに登録された Cookie と登録されていない Cookie の両方を返した場合、CloudFront はホワイトリストに登録された Cookie のみをキャッシュします これは、Cookie: をキャッシ

(2018 年追記、ここから) この記事は 2015 年に書かれた記事 SPF and Amazon SES を読んだメモでしたが、自分の整理のためにも少し追記します。 Amazon SES を使う際、DNS に SPF を設定する必要はありません。 以下公式スライドからの引用です。 https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-tech-2016-amazon-ses SPF は MAIL FROM (Return-Path、エンベロープFROM、バウンスメール宛先) のドメインを認証します。MAIL FROM は、メールの送信者 From と一致している必要はありません。 SPF の目的は、メールサーバの IP と、MAIL FROM という「苦情の受付窓口」を結びつけるところにある、というのが自分の理

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Git のガベージコレクションについてのメモ。 設定 git help config (v1.9.2) より。 http://git-scm.com/docs/git-config/1.9.2 見出しの () はデフォルト値。 gc.auto (6700) When there are approximately more than this many loose objects in the repository, git gc --auto will pack them. ルーズオブジェクト (パックされてないオブジェクト) が、こ