dackdive's blog

新米webエンジニアによる技術ブログ。JavaScript(React), Salesforce, Python など

「みんなのデータ構造」学習メモ:3.2 DLList 双方向連結リスト

みんなのデータ構造(紙書籍+電子書籍) – 技術書出版と販売のラムダノート

amazon

これまでのメモ

今回は「[P58] 3.2 DLList: 双方向連結リスト」。

TypeScript によるソースコード
https://github.com/zaki-yama/open-data-structures-typescript/blob/master/src/DLList.ts

続きを読む

Chromiumベースの新しいMicrosoft Edgeについて

2020/1/15に新しいMicrosoft Edgeが正式リリースされました。

日本語

今後、これまでのMSEdgeはEdge Legacyと呼ぶようです。
(今回リリースされたChromium版Edgeのことを、以後「新Edge」と記載しています)

移行の流れや今後のアップデートポリシー、主な特徴などをまとめてみます。

なお、ユーザー目線での影響を知る上ではこちらの記事が一番わかりやすかったです。

3行まとめ

  • 新EdgeはChromiumベース(Chromeと全く同じかは不明)
  • 手動でインストールするか、Home/Proエディションのみ今後Windows Update経由で自動アップデート。インストールするとLegacy版は置き換えられて使用不可に
  • IEモードを使うとEdge内で指定したサイトをIEレンダリングエンジンで表示することが可能だが、手順はかなり複雑なので管理者向けの機能と思われ

新EdgeはChromiumベース

ずいぶん前からアナウンスされていた通りですが、新EdgeはChromiumベースになります。
そのため、レンダリングエンジンやJavaScriptエンジンは基本的にChromeと同じものになります。

基本的に、と書いたのは、実際にはChromiumをforkして独自のカスタマイズを加えている可能性も考えられるのですが、そういった記述は見つけられませんでした。

新Edgeのインストール方法と、ロールアウト計画

新Edgeをインストールしたい場合、現在は https://www.microsoft.com/edge から直接ダウンロードする必要があります。

インストールすると、これまでのLegacy版を置き換えるような挙動になり、古い方は利用できなくなります。

before f:id:dackdive:20200206003859p:plain

after f:id:dackdive:20200206003904p:plain

また、今後はWindows Update経由で配信され、数ヶ月かけてロールアウトしていく計画のようです。
ただし、公式ブログの日本語版のトップにでかでかと書かれていますが

※日本のお客様に対しては、確定申告への影響を考慮し、Windows Updateを通じた新しいMicrosoft Edgeの配信は令和2年4月1日以降、順次開始される予定です。

です。

加えて、Windows Updateでの自動更新は HomeおよびProエディションのみで、Enterprise、Education、Workstation Pro(?)といったエディションは対象外 です。
また、管理対象デバイス(*)も同様です。

(*) 「管理対象デバイス」は公式ブログ に記載されてた表現。冒頭に挙げたZDNetの記事 によると

Active DirectoryやAzure Active Directoryドメインに参加しているコンピューター、モバイルデバイス管理(MDM)で管理されているコンピューター、Windows Server Update ServiceやWindows Update for Businessなどで管理されているWindows 10 HomeやPro

を指す?

今後のアップデートポリシー

新しい Microsoft Edge へのアップグレード - Windows Blog for Japan から引用

Microsoft Edge のインストール後は、約 6 週間ごとにインストール先の OS とは独立して更新が行われます。初回のメジャー アップデートとなる Microsoft Edge 80 は、2 月上旬に Stable チャネルでリリースする予定です。

設定の「About Microsoft Edge」から更新確認とアップデートができます。Chromeと同じですね。

f:id:dackdive:20200206004027p:plain

IEモード

新Edgeには「IEモード」という機能が搭載されています。
これは、あらかじめ設定したURLにアクセスした際は、そのタブ内のみIEレンダリングエンジンを使ってサイトを描画するというものです。

この機能自体は以下のページに従って設定さえすれば誰でも使えますが、Windowsのグループポリシーを変更するなどかなり複雑な操作が必要なため、実際には情シスなどの管理者が設定する機能という位置づけのようです。

必要な手順はおおむね Microsoft Edge を IE モードで使用する | Microsoft Docs の通りですが、ポリシーダウンロードサイト(https://www.microsoft.com/en-us/edge/business/download)のファイルダウンロードボタンの場所がわかりづらいので注意。

f:id:dackdive:20200206004213p:plain

あと、自分が試したときはポリシーを追加でダウンロードしたファイルを選択することができず、手動でフォルダ内に配置する必要がありました。

指定するとこういったアイコンが表示されます。

f:id:dackdive:20200206010501p:plain

リリースチャネル

Chromeと同様、Stable(安定版)以外にCanary(毎日更新)、Dev(毎週更新)、Beta(6週おきに更新)が用意されています。 f:id:dackdive:20200206010537p:plain

新Edgeの独自機能その1: Tracking Prevention

新EdgeにはTracking Preventionというトラッキング防止機能が備わっています。

f:id:dackdive:20200206010552p:plain

設定>プライバシーとサービス からこのような画面にアクセスすることができ、3段階のレベルから選びます。 デフォルトは真ん中のBalancedです。

日本語の情報はあまりありませんが、公式ブログから以下の2つの記事が参考になります。

ラッキングや暗号通貨マイニング(Cryptomining)目的のサイトに分類されているURLへのアクセスに対して、ストレージへのアクセスを禁止(Restrict storage access)したり、リソースの読み込みをブロック(Block resource loads)したりするようです。

どのサイトがどういうカテゴリに分類されるか、については Disconnect社(トラッキング防止のブラウザ拡張機能などを開発してる会社)のリスト を使っているらしいです。 Firefoxも同じ?(参考

どういうしくみ?

Disconnect社のリストに加え、Site engagementOrganizationsというしくみが実装されているらしいです。

Site engagement とは、ユーザーのサイト訪問頻度や滞在時間などからサイトの信頼度をスコアリングするしくみです。
スコアはローカルに保存され、また Edge で edge://site-engagement にアクセスすると各サイトがどういうスコアになっているのか確認できます。

f:id:dackdive:20200206012230p:plain

将来変わる可能性はありますが、今のところこのスコアが4.1以上なら信頼できるサイトとして判断しています。(スコアは0〜100点)

Organizations とは、ある会社が複数のドメインを使用していたときに、それらのドメインをグルーピングし、同一グループ内でのクロスドメインリクエストはブロッキング施策を緩和するみたいなしくみです。

新Edgeの独自機能その2: Collections

こちらは現在の安定版(v79)ではまだ有効になっておらず、v80以降で使える機能です。 DevやCanary版で試せます。

f:id:dackdive:20200206010843p:plain

ブックマークをもうちょっと高機能にした感じでしょうか。 ブラウザ右側のサイドバーに、ページのURLだけでなく、テキストや画像をコレクションに追加することができます。

ブラウザ拡張

新EdgeではChrome拡張がほぼそのまま動きます。 Chrome Web Storeからもインストールできるようです。

f:id:dackdive:20200206010901p:plain

また、まだベータ版ですが、Edge専用のストアも公開されています。 https://microsoftedge.microsoft.com/

Edge専用ストアへの公開については以前記事を書きました。
Chrome拡張をChromium版Microsoft Edgeに対応する - dackdive's blog

chrome.tabsなどのAPIがそのまま使えるので、おそらくChrome拡張のソースコードに何も手を入れなくても公開できます。

リファレンス

公式ブログ・ヘルプ

日本語記事

「みんなのデータ構造」学習メモ:3.1 SLList 単方向連結リスト

みんなのデータ構造(紙書籍+電子書籍) – 技術書出版と販売のラムダノート

amazon

これまでのメモ

2章の後半をすっ飛ばして、第3章の連結リストに入る。
今回は「[P55] 3.1 SLList: 単方向連結リスト」。

TypeScript によるソースコード
https://github.com/zaki-yama/open-data-structures-typescript/blob/master/src/SLList.ts

続きを読む

「みんなのデータ構造」学習メモ:2.4 ArrayDeque

引き続き、「みんなのデータ構造」という本を読む。
みんなのデータ構造(紙書籍+電子書籍) – 技術書出版と販売のラムダノート

amazon

これまでのメモ

今回は「P35. 2.4 ArrayDeque 配列を使った高速な双方向キュー」。

TypeScript によるソースコード
https://github.com/zaki-yama/open-data-structures-typescript/blob/master/src/ArrayDeque.ts

続きを読む

Salesforce: 新しいTrailhead Playgroundがリリースされました

新しいTrailhead Playgroundがリリースされました。
といっても劇的なアップデートではなく、Playgroundにアプリが1つプリインストールされるようになっただけのようです。

今まで通り、ハンズオン形式の問題から「Trailhead Playgroundを作成」で作成すると、新しい組織にはプリインストールされるようになっています。

f:id:dackdive:20200120024205p:plain

新しいTrailhead Playgroundでできること

1. パッケージインストールが組織内から可能に

f:id:dackdive:20200120024533p:plain

「Install a Package」タブからは、パッケージIDを入力してボタンを押すとパッケージをインストールできるようになります。
単に別タブでインストール画面が開くだけですが、これまではこのためにログインを求められてパスワードが必要だったはずなので手間が減ったかな。

2. パスワードリセット画面

f:id:dackdive:20200120024907p:plain

「Get Your Login Credentials」からはユーザー名が確認できるほか、パスワードのリセットが可能です。
この場で新しいパスワードを入力させてもらえるのかと思いましたが、単にリセットが行われてメールが送信されるだけのようです。

余談

すでにTrailheadのモジュール内で、パッケージインストール手順やパスワードリセット手順などの記述はアップデート済みっぽい。(全部じゃないかもしれない)

f:id:dackdive:20200120025204p:plainSalesforce 組織へのサウンド効果の追加 > パッケージのインストール

f:id:dackdive:20200120025211p:plain

Trailhead Playground の管理 > Trailhead Playground のユーザ名とパスワードの取得

Salesforce: 「認証プロバイダ」と「指定ログイン情報」で外部サービス(GitHub)にOAuth2で接続する

こちらの記事を読んで、自分でも試してみたメモ。

認証プロバイダ、指定ログイン情報とはなにか

ヘルプ

認証プロバイダについては
10分でできる!SalesforceでSSO(認証プロバイダ:Google編) - TECH BLOG | 株式会社テラスカイ
などの記事にあるように、外部サービスのアカウントを使ってSalesforceへのSSOを実現することができる機能。
今回は単純にConsumer KeyやSecretといったクレデンシャル情報を登録するためだけに使う。

指定ログイン情報については、APIエンドポイントと必要な認証パラメータを登録しておくことで、登録した外部サービスのAPISalesforceから叩く際に面倒な認証認可のフローを肩代わりしてくれる機能。

手順

1. 認証プロバイダを登録する

認証プロバイダは英語だと「Auth. Providers」。
新規で作成しようとすると、プロバイダタイプにTwitterGitHubGoogleなど主要なサービスがデフォルトで存在することがわかる。

f:id:dackdive:20200120013150p:plain:w320

サービスごとに認証方式が異なるので必要な入力事項も異なるが、そこはフォームが動的に変化してよしなにやってくれる。

今回はプロバイダタイプにGitHubを選んだ。

f:id:dackdive:20200120014547p:plain

「コンシューマ鍵」と「コンシューマの秘密」はまだ発行してないので、この時点では適当な文字列を入れておく。

f:id:dackdive:20200120014738p:plain

保存すると「Salesforce設定」というセクションにいくつかURLが記載されている。
このうち、「コールバックURL」はこの後Consumer Key/Secret を発行する際に入力するのでコピーしておく。

2. 外部サービスのOAuthアプリケーションを登録し、Consumer KeyとConsumer Secretを取得する

GitHubの場合、Settings > Developer settings > OAuth AppsからNew OAuth Appを選ぶと作成できる。

f:id:dackdive:20200120014921p:plain

「Authorization Callback URL」に先ほどのコールバックURLを入力する。

また、発行した Consumer Key/Secret で先ほどの認証プロバイダの設定を更新する。

3. 指定ログイン情報を登録する

f:id:dackdive:20200120015049p:plain

URLはAPIのエンドポイントとなる。GitHubの場合は https://api.github.com
ID種別は「指定ユーザ」、認証プロバイダで先ほど登録したGitHub用の設定を選択する。
(ID種別については後述)

4. 試す

今回は Apex で試してみる。

このようなコードを書く。

HttpRequest req = new HttpRequest();
req.setEndpoint('callout:github/repos/zaki-yama/copy-title-and-url-as-markdown/issues');
req.setMethod('GET');
Http http = new Http();
HTTPResponse res = http.send(req);
System.debug(res.getBody());

setEndpoint() に指定する文字列は

callout:<指定ログイン情報の「名前」>/指定ログイン情報の「URL」以下のパス>

となる。

指定ログイン情報の「ID種別」について

今回使用した「指定ユーザ」以外に、「匿名」と「ユーザ」がある。
ヘルプによれば

f:id:dackdive:20200120023201p:plain

外部システムへのアクセスに 1 セットのログイン情報と複数セットのログイン情報のどちらを使用するかを決定します。

外部システムへのアクセスに 1 セットのログイン情報と複数セットのログイン情報のどちらを使用するかを決定します。

  • 匿名: ID がないため、認証は行われません。
  • ユーザ: コールアウトから外部システムにアクセスするユーザごとに、別個のログイン情報を使用します。このオプションは、ユーザ単位で外部システムのアクセスを制限する場合に選択します。 Salesforce の権限セットまたはプロファイルを使用してユーザアクセスを付与したら、ユーザは個人設定で外部システムの独自の認証設定を管理できます。JWT または JWT トークンの交換を使用している場合、それらに対して、ユーザごとのログイン情報が処理されます。

  • 指定ユーザ: 組織から外部システムにアクセスするすべてのユーザに対して、同じセットのログイン情報を使用します。このオプションは、すべての Salesforce 組織ユーザに外部システムの 1 つのユーザアカウントを指定する場合に選択します。

とあるので、外部サービス側でもSalesforceユーザごとにアカウントを区別したい場合は「ユーザ」を指定しつつユーザごとに追加の設定が必要になりそう。

HTTP/Tokyo #1に行ってきた

行ってきました。
中身の濃い勉強会で非常に勉強になった。

jxckさんの発表は圧巻でした。

Response Status codes 3xx @haormauyraa

資料: https://slides.araya.dev/http-tokyo-1/#slide=1 demo: https://playground.araya.dev/http-redirections/

  • 3xx系のステータスコードの話
    • 300〜308まで
  • RFC7231, 7232, 7538
  • 301, 302はHTTP/1.0
  • 300 Multiple Choices
    • 対象のリソースが複数の表現をもつ
      • サーバーはリダイレクト先として複数の選択肢を提示し、クライアント側はその中で優先するものを1つ選ぶ
    • サーバーが優先するべき選択を持っていたら、サーバーはその選択肢の URI 参照をLocaionヘッダーに含めるべき(SHOULD)。UA はその値を自動リダイレクトに利用してもよい(MAY)
  • 301 Moved Permanently
    • 対象のリソースに新しい恒久的なURIがあてられていて、このリソースへの今後の参照は同封されたURIのいずれかを利用するべきことを指示する
  • 302 Found
    • 302 Foundは301 Moved Permanentlyと異なりリダイレクト先となるURIは一時的という扱い。なので301はキャッシュ可能だが302はキャッシュすべきでない
  • 303 See Other
  • 304 Not Modified
    • "リクエストされたリソースを再送する必要がないことを示します。これはキャッシュされたリソースへの暗黙のリダイレクトです。" (MDN より)
    • リクエスト側が If-Modified-Since などを付けた条件つきのリクエストを送ったときに、「仮に条件がfalseでなければ200で応答することになる」ことを示す
    • 実際のリソースは返さない
    • 条件をつけたクライアント側が必要なリソースを(キャッシュなどで)持っている、ということをリクエストで示しているので、サーバーからはリソースそのものを返す必要がない
  • 305は非推奨、306はunused

「425 Too Early」@flano_yuki

資料: https://www.slideshare.net/yuki-f/status-425-httptokyo

f:id:dackdive:20200117221846p:plain

  • TLSハンドシェイクにはClientHello→ServerHelloを経てからHttpRequestを送るフルハンドシェイクと、1回目のClientHelloと一緒にHttpRequestを送る0-RTTハンドシェイクがあり、後者のClientHelloと一緒に送るHttpRequestがEarly Data
  • Early Dataの危険性
    • Early Dataは暗号化されているが第三者が複製することはできる
    • 冪等性のないリクエスト(POSTでデータを作成するとか)だとまずい
    • サーバーはHTTPリクエストを見て冪等でないリクエストは拒否することもできる

f:id:dackdive:20200117222159p:plain

  • HTTPでEarly Dataを安全に扱えない問題
    • 例:Proxyを介していると
      • Proxyはリクエストが冪等かわからない
      • originは元のリクエストがEarly Dataで送られてきたものかわからない
  • どうするか
    • Proxyは Early-Data: 1というヘッダーをつけてoriginに送る
    • originはリクエストが冪等でない場合は HTTPステータス425 Too Earlyをを返す
  • Firefoxでの実験
    • サーバーが425を返したとき、クライアントはTLSハンドシェイクを待ってからリクエストを送っている


Cookie @Jxck

資料はなし。ホワイトボードを使って説明。

  • RFC6265の話
  • Cookie はなぜ生まれたか
    • リクエスト・レスポンスが冪等な世界で、リクエストを送ってきたのが誰なのかを判断したい
  • Cookieとして送るのはIDであることがほとんどなので、ほとんどCredential
  • Cookieの欠点
    • SOP(Same Origin Policy)に則っていない
    • わかりやすい攻撃
      • 悪意のあるサイトが正規のサイトと同じリクエストを送る <form> を設置すると、Cookieを送ってリクエストが成立してしまう
      • はまちちゃん事件
  • 今どうやって対策しているか
    • csrf-tokenという一意の識別子を埋め込んでおき、リクエスト同時に送る
  • サーバーから Set-Cookie するときに、idの後ろに SameSite: というプロパティを付けることができるようになった
  • 3rd party cookie
    • サイトAにアクセス
    • サイトA内のiframeからADサーバーにアクセス -> cookie 456を返す
    • サイトBにアクセス
    • サイトB内のiframeから同じADサーバーにアクセス、このとき cookie 456を送る -> 同じ人だと特定できる
    • さらに、サイトAがECサイトだった場合、検索キーワードも一緒にADサーバーに送る -> サイトBを訪問したとき、サイトAの検索クエリの内容を元に適切な広告を送るといったことが可能
  • SafariのITP
  • ITPで困るのはADだけじゃなくAuthenticationサービス(SSO)
    • ITPはトラッキングをしてそうなサイトだけブロックする、と主張している
  • Cookieの原理は変えられないが、トラッキング目的のCookieは防ぎたい。Chromeはどうするか
  • Cookie
  • Cookie上書き問題への対策
    • id=xyz という Cookieに対して __Secure-id=xyzというように __Secure- prefix をつけると、httpsでの通信時のみしか送らなくなる
    • __Host-Secure; Path=/ じゃないとだめにするprefix
  • クライアント側でtokenを生成する Sec-Http-State: token=XXX
  • SameSite=Strict
    • Lax は別オリジンだったとしてもnavigation時にはCookieを付ける
    • Strict は別オリジンからは全てつけない
      • 例: connpassにログインした状態で、Google検索結果からconnpassへのリンクを開く
        • アドレスバーにconnpass.comと打ってアクセスしたときですらそうなる
    • Laxで何が問題か?
      • GET で何かするようなAPI(ログアウトリンクなど)
    • read cookieとwrite cookieを分ける
      • GitHubは実はやってるっぽい?
        • __Host-user_session_name_site
        • _gh_sess
        • user_sessionかも?