タイトル/名前 | 更新者 | 更新日 |
---|---|---|
技術/Security/testssl.sh | msakamoto-sf | 2017-10-07 17:33:53 |
技術/Chrome/SeleniumIDE, Selenium Builder, その他E2Eテスト用のChrome拡張について(2015-04時点) | msakamoto-sf | 2017-10-07 13:53:25 |
技術/Chrome/お気に入りChrome拡張のメモ | msakamoto-sf | 2017-10-07 13:49:57 |
技術/Security/Burp/リクエスト,レスポンスの文字化け対策参考メモ | msakamoto-sf | 2017-10-07 13:37:43 |
Java/JMXのCUIツール参考メモ | msakamoto-sf | 2017-10-07 13:19:15 |
Java/JVMオプションとデフォルト値の一覧取得(-XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:+AggressiveOpts) | msakamoto-sf | 2017-10-07 12:30:33 |
日記/2017/10/05/SingletonのGoodパターン、Badパターン | msakamoto-sf | 2017-10-06 00:37:20 |
Java/CRaSH(監視向けリモートシェル) 参考URLメモ | msakamoto-sf | 2017-06-26 19:04:10 |
SideBar | msakamoto-sf | 2017-03-26 13:57:09 |
プライバシーポリシー | msakamoto-sf | 2017-03-26 13:55:17 |
サーバのSSL/TLSをセキュリティ観点でチェックしてくれるツール、testssl.shを使うメモ。
2017年の9月に安定版として 2.9.5-1 がリリースされたのでこれをインストールしてみる。
(正確にはこの時点での安定版は 2.8 だが、開発中の 2.9 branch の中でも安定版として言える状態として 2.9.5-1 がリリースされてる。)
環境:CentOS7, 64bit版
インストールのポイントとしては、 https://testssl.sh/ から testssl.sh をDLするのではなく、GitリポジトリをそのままcloneするかリリースパッケージをDL, 展開する方法に変わってる点。
OpenSSLバイナリも特殊なのをビルドして使ってたりするので、今後はこちらの方式が簡単かもしれない。
https://github.com/drwetter/testssl.sh の Readme.md にあるとおりにする。
$ git clone --depth 1 https://github.com/drwetter/testssl.sh.git $ cd testssl.sh/ $ ./testssl.sh -v (...) ########################################################### testssl.sh 2.9dev from https://testssl.sh/dev/ (...)
2.9dev branchがデフォルトのbranchとなっている。gitのcloneオプションを調整すれば、他のbranchを利用することも可能だろう。
また、このままでは /bin/openssl を見に行ってしまい、testssl.sh 中の bin/opensslバイナリを使ってくれなかった。
→以下のようにOPENSSL環境変数で調整できる。
$ OPENSSL=./bin/openssl.Linux.x86_64 ./testssl.sh -v (...) Using "OpenSSL 1.0.2-chacha (1.0.2i-dev)" [~183 ciphers] on L0000627:./bin/openssl.Linux.x86_64 (...)
GitHubのリリースページからアーカイブをDLする。
$ curl -L -O https://github.com/drwetter/testssl.sh/archive/v2.9.5-1.tar.gz $ tar zxf v2.9.5-1.tar.gz $ cd testssl.sh-2.9.5-1/ $ ./testssl.sh -v (...) ########################################################### testssl.sh 2.9.5 from https://testssl.sh/ (...)
こちらでもやはりOpenSSLバイナリが /bin/openssl をデフォルトで使ってしまうので、環境変数かコマンドラインで調整する。
$ OPENSSL=./bin/openssl.Linux.x86_64 ./testssl.sh -v or $ ./testssl.sh --openssl ./bin/openssl.Linux.x86_64 -v → (...) Using "OpenSSL 1.0.2-chacha (1.0.2i-dev)" [~183 ciphers] on L0000627:./bin/openssl.Linux.x86_64 (...)
※チェックする対象は自分の管理下にあるサーバか、脆弱性検査を許可されたサーバのみにすること。
通常テスト:
$ ./testssl xxx.xx.xxx.xx:443
HTMLに出力(通常テストでコンソールで使われるエスケープシーケンスが、ちゃんとHTMLにも反映されます)
$ ./testssl.sh --html www.glamenv-septzen.net:443
プロトコルバージョンごとにcipher suiteをリストアップ
$ ./testssl -E xxx.xx.xxx.xx:443
特にプロトコルバージョンごと、にはこだわらず、全部混ぜてリストアップ
$ ./testssl -e xxx.xx.xxx.xx:443
参考:
その他:
$ ./testssl.sh xxx.xx.xxx.xx:443 | aha > output.html
ChromeでのSeleniumIDE相当や、End-To-Endテスト向けのChrome拡張にどんなのがあるか調べてみたメモ。
Selenium IDEの次世代、Selenium Builder :
@kyo_ago さんが、Chrome用のSelenium IDEを独自に作ってたり、独自のE2Eテストツール用Chrome拡張作ってる。
その他のブラウザ操作の記録&再生&テスト用Chrome拡張:
ブラウザ操作の記録/再生そのものではないが、WebDriver/Seleniumのテストケースの作成を支援するユーティリティ系Chrome拡張:
よく使ってる拡張について紹介します。
old:
色々調べ物してて、参考ページなどを タイトル + URL で一気にWiki/Markdownのリストに落とし込みたい時に便利です。
自分でも同様の拡張を自作( 技術/Chrome/Chrome Extension の勉強メモ(copy_tab_urls) )しましたが、上記拡張の方が複数フォーマット(テンプレ)を登録できるので、複数スタイル(Wiki/Markdown/HTML)を使い分けられて便利です。
見出しのネストが複雑なWebページを閲覧していると、目次が欲しくなってきます。
コンテンツによっては、手動または自動で見出しの目次が生成され、クリックすればその見出しにジャンプできるようになっています。
しかしそうした目次が無い場合は、大きなドキュメントになるほど、文書構造を把握することが困難になり理解するのに時間もかかってしまいます。
そうした時に、コンテンツ側ではなくブラウザ側で自動的に見出し一覧を生成してくれる機能があると便利です。
以下のChrome拡張をインストールすると、そうした機能を使えるようになります。
以下が実際に表示された様子で、左側のページ表示領域に埋め込まれているのが"HeadingsMap", 中央にアドレスバーからポップアップしているのが"HTML5 Outliner"の見出し一覧です。(2017-02時点のChrome56 + Win10 でスクリーンショットを撮り直してます)
それぞれどんな違いがあるか、簡単にまとめます。
なお、見出し一覧を生成したいコンテンツが仕事に関連する非公開コンテンツの場合も考えられます。そうしたコンテンツを上記Chrome拡張は読み取ることになりますが、コンテンツの内容を不正に外部サーバなどに送信していないか気になるところです。
そこで、HTTPプロキシを間に入れてHTTP/HTTPS通信を確認したところ、不正なサーバにコンテンツ内容を勝手に送信しているような通信は両方共確認できませんでした。
そのため、両方共、コンテンツへのアクセスは純粋に見出しを抽出して一覧を生成するためだけにアクセスしており、非公開コンテンツに対して使っても問題ないと思われます。("HTML5 Outliner"はgithub上でソースが公開されていますので、ソースの方も確認し、XMLHttpRequestなどの呼び出しが無いことを確認済み)
表示中のページの文字コード(エンコード)を変更:
URLEncode/Decode:
BurpSuite, 1.3~1.7に至るまで、Proxy historyなどでのリクエスト/レスポンスで、マルチバイト文字のコピペで文字化けする。文字化け、というか、コピーしてペーストすると、マルチバイトのところでデータが切れた内容がペーストされてしまうなど。
解決策としては、現状、Burp拡張を使う他無さそう。
2017年10月時点で有効なBurp拡張:
1.5くらいまでは burpCodeExchange というBurp拡張を使っていた。ISO-2022-JPにも対応していてすごい便利だったが、サイトがLOSTしてる・・・。
http://isayan.cocolog-nifty.com/diary/2014/04/burp-suite-16-e.html
2017年現在、JMXを見るツールとしてはJDK付属のjmc(MissionControll)やjconsoleなどがあるが、いずれも基本的にはGUIツール。サーバ内で作業するときなどは、CUIツールでJMXにアクセスできるのがあると嬉しいので、軽くググッたときの参考メモです。
→これが軽い感じのツール。実際には、以下の記事でカスタマイズしたものを使ったほうが簡単そう。
Jmxtermというのもある。これも機能的には十分そう。
これはちょっと違うかも。
基本形 : -XXオプションの一覧を標準出(-version を付けることでjavaコマンドのusage表示を省略させる)
java -XX:+PrintFlagsFinal -version
仮想マシンチューニング用のオプションも出力:
java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version
実験的なオプションも出力:
java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:+UnlockExperimentalVMOptions -version
他、"-XX:+AggressiveOpts" や "-XX:+PrintFlagsInitial" というのもある。
2011年~2017年ごろまでの参考:
その他参考:
Qiitaより:
仕事としてプログラミングしてて、もう10年来ずっと、いたるところでレガシー化しやすく、テストコードを書けなくしてる最大の原因と思うのがSingletonデザインパターンだと個人的には思う。
ただ、最近DIコンテナなど扱うようになってきて、ようやくSingletonデザインパターンの使い方でGoodなパターンとBadなパターンの二種類が見えてきた。
Javaでかけば以下のようなコード。
public class MyClass { private static final MyClass instance = new MyClass(); private MyClass() { // constructor } public static MyClass getInstance() { return MyClass.instance; } }
何が問題なのか:
なんちゃってアノテーションつければこんな感じ。
@Singleton(scope=Application) public class MyClass { private final ApplicationContext appContext; public MyClass(@Inject final ApplicationContext appContext) { $this->appContext = appContext; // ... } }
利用側:
// ... ApplicationContextImpl appContext = new ApplicationContextImpl(); // ... DIContainer dicon = DIContainer.create(appContext); MyClass singleton = dicon.get(MyClass.class);
どう問題は解決されたのか:
デメリット:
Badパターンでは「インスタンスを一つに制限する」を言語のルールで実現できていたが、逆にGoodパターンではそれを諦めている。
それでは本末転倒ではないのか?
否、「インスタンスを一つに制限する」のは、「何に対して」であるのか、という点が今まではおろそかになっていたと考える。
その前に、そもそもそうした「ルール」をどこで担保するのかについて考えなければならない。
Badパターンでは「ルール」の担保を言語側で担保していた。これは非常に強固で確実だが、同時にテストコードを書くときの障害になる。
個人的には、テストコードを書きづらい設計はどんなにデザインパターン上「正しく」ても、最低最悪のクソコードである。
テストコードがかければ、リファクタリングできる。実装コードを、洗練できる。
しかし、テストコードが書けなければ、リファクタリングする機会が大幅に失われる。実装コードを洗練することが難しくなる。
プログラミングは創造的な作業であるのは確かで、最初から100%の正しさでクラス構造をデザインできることはまずありえない。必ずリファクタリングをする時が来る、あるいは振る舞いを変えるレベル=リファクタリングを超えるレベルで設計を変更する時が来る方が自然と考えたほうが良い。(これについては賛否両論ありそうだけど。)
よって、OOPだろうが関数型だろうが手続き型だろうが、リファクタリングできないソース、端的にはテストコードが書けない設計はどんなにその他が正しく作れれていも、クソコードだと断言する。
ここでSingletonの話に戻ってくると、BadパターンがなぜBadパターンか、それはテストコードを書きづらくて、大抵は書くのをギブアップするような状況になるのが理由となる。(これがconstructorがpublicで、デフォルト実装をsingleton化してるだけで、作ろうと思えば派生クラスとかで色々いじれる状況なら、テストコード用にMock化できるので許容範囲)
つまり自分の意見としては、「インスタンスを一つに制限する」のがテストコードを書きづらくするのなら、そんなルールはゴミ箱に捨てろ。それよりもテストコードを書きやすくしろ、そして書け、書いたテストコードがサンプルコードになり、後続がそれを見て使い方を学べるようにしろ、ルールの担保はコードレビューで担保しろ。ということになる。
そして、「何に対して」インスタンスを一つに制限するのかだが、これは普通に考えればアプリケーションのライフサイクルに揃えるのがSingletonの意図として順当と思われる。
となれば、アプリケーションの開始から終了までの、様々なインスタンスを収めた「文脈=Context」的なインスタンスと同じ長さになるだろうし、またSingletonは左記の「文脈=Context」に含まれるのが順当だろう。
よって、Goodパターンではテストコードの書きやすさを担保しつつ、アプリケーションのライフサイクル(Goodパターンで挙げた例ではDIコンテナ)に合わせて管理できるようにした。これなら、テストコード中でプログラマブルにライフサイクル管理がしやすくなる。
自分の意見になるが、「テストコードを書ける設計になっていること」が最重要となる。
よって、Singletonデザインパターンを実装する場合もテストコードを書ける設計にすることがまず大前提となる。
しかし、Mock化などを考えると言語レベルでの「一つに制限」する「ルール」は採用できない。
そうなると慣れてないプログラマが自分でインスタンスを作ってしまったりする可能性があるが、そのリスクはどう見るか?
そのリスクは、「テストコードによる例示とコードレビューによる担保」で回避すればよい、というのが自分の意見になる。
重要なのは、「何に対してインスタンスを一つに制限しなければならないのか」を明示すること。
実際にDIコンテナやアプリケーションのcontextインスタンスを作り、そこからSingletonインスタンスを取り出すのをテストコードで表現すること。それができる設計にすること。
そうしておくことで、後続のプログラマに対して、そのクラスの使い方、Singletonとしての存在意義をテストコードで表現できる。
もし間違って独自にインスタンスを作るようなコードを書いた場合は、コードレビューで指摘して直してもらう。その際に、テストコードを示してSingletonとしての使い方、アクセス方法、テストコードの書き方を例示することで、後続のプログラマの勉強にもつながる。
もう一度書くと、テストコードを書く障害になるような設計は、どんなに他が正しくてもゴミ箱ゆきというのがここ数年における自分の意見なので、それに基づくと上記のようになった。
以上。
Javaの監視にはJMXがあるが、その他に、れっきとした「シェル」としてコマンドラインインターフェイス経由でJVMの内部状態を問い合わせたり、コマンドを発行できるフレームワーク兼ライブラリとして「CRaSH」というのがあるので参考URLだけメモ。
telnetやSSHでログインできるれっきとした「シェル」を内部で起動させ、そこから独自コマンドで情報を取得したり、あるいはGC実行など副作用のある処理を実行することができる。
独自コマンドについてはデフォルトでJVMの監視で最低限必要なものは備えていて、Groovyスクリプトで拡張や追加ができるらしい。
Springなど著名FWでも組み込まれており、実績もある。JMXよりはライトウェイトな使い方になるかもしれない。
その他参考:
本文書は、当サイト(Glamenv-Septzen.net)における個人情報の保護およびその適切な取り扱いについての方針を示したものです。
当サイトでは、第三者配信の広告サービス(Amazonアソシエイト https://affiliate.amazon.co.jp/ )を利用しています。
このような広告配信事業者は、ユーザーの興味に応じた商品やサービスの広告を表示するため、当サイトや他サイトへのアクセスに関する情報 「Cookie」(氏名、住所、メール アドレス、電話番号は含まれません) を使用することがあります。
当サイトでは、Googleによるアクセス解析ツール「Googleアナリティクス」を利用しています。
このGoogleアナリティクスはトラフィックデータの収集のためにCookieを使用しています。
このトラフィックデータは匿名で収集されており、個人を特定するものではありません。
この機能はCookieを無効にすることで収集を拒否することが出来ますので、お使いのブラウザの設定をご確認ください。
この規約に関して、詳しくは https://www.google.com/policies/privacy/partners/ をご確認ください。
当サイトは完全リンクフリーです。
トップページ、記事など、正規に公開しているページであれば、どのページにリンクしていただいても問題ありません。
ただしインラインフレームの使用や、画像への直リンクなどは禁止させて頂いております。
当サイトに掲載する情報は記事公表時点の正しいものを提供するよう努めております。
ただし、提供している情報、リンク先などにより、いかなる損失や損害などの被害が発生しても当サイトでは責任を負いかねますので、ご了承ください。
リンク先の商品は当サイトが販売しているのではなく、各リンク先店舗での販売となります。
購入方法、その他お問い合わせは各店舗までご確認ください。
商品購入に関するトラブルに関しては、当サイトでは責任を負いかねますのでご了承ください。
当サイト「Glamenv-Septzen.net」に掲載されている情報についての著作権は放棄しておりません。
当サイト記事からの引用に関しましては「引用元の明示」によって無償で引用頂けます。
ただし、全文転載はお断りいたしております。
引用許可範囲についても、事前予告なくこれを変更する事があります。
また、当サイトのRSSを利用し、コンテンツをそのまま盗用することも禁止しています。
初出掲載:2017-03-26
以下の記事を参考にさせていただきました:
最新コメント10件
2009-03-21 by msakamoto-sf