  |
はてなキーワード: telnetとは
色々考えられると思うが、俺なんかは
「ネットニュース」と言われてNNTPの方を使ってた事を思い出せる世代とニュース配信のウェブサイトだけが頭に浮かぶ世代
あたりで分けられそうじゃないかと思う。
リモートログインにtelnetを平気で使えた世代とssh使わんとかキチガイだろって世代とかｗ
パソ通老人とインターネット老人は違う、みたいな話もあるけど、初期のネットユーザの多くはNiftyやPC-VANあたりにアクセスしてた人間だし、"AOLer" みたいな「ネットにアクセスするためにパソ通であるAOLと契約」みたいなのが多かった訳で、専業プロバイダの高かったIIJとか、かなり安いけど怪しいベッコアメやリムネットから繋いでパソ通のサービスを全然知らない「インターネット老人」ってどれくらい居るのよ？ って思うんだけどな。 win95と同時に立ち上がったMSNだって最初はパソ通サービス事業者だった訳だしな。
| 会場 | 開演 | ゲスト | Lコード | |
| 1部 | 13:30 | 14 | 三石、あかほり、菊池志保 | 34410 |
| 2部 | 16:30 | 19 | 金月、松本 | 34411 |
URLは、あとで調べよう
そしてよせばいいのに「下級生」をはじめる。でもさすがに10時ぐらいに完璧にダウン。昼の2時くらいまで寝る。Nさんのtelで目をさます。
メシを食いに行き、次は「下級生」をNさんがする。
これが終ったとき、2時半。そこから真歩子ちゃんを落としにかかる。もうデートはOKなのでデートを3回ぐらいした頃に、キスまでOK、5回目にやっとホテルへGO!
7/14ぐらいだったかな。その後3回くらいホテルへ行く。鬼畜になって「落とした女は用済みだ！」とかしようと思ったけど、真歩子ちゃんすげーかわいいからもーラブラブですぅ～。
あたなは何か勘違いしているナリ
HTTPプロキシは基本的に CONNECT メソッドを通じて通信するナリ
それ以外の場合は socks プロトコルで通信するナリ（なので基本的に Proxy を通すとは HTTPプロキシを通すということで、その場合 CONNECT メソッドが必ず必要）
CONNECT は基本的にHTTPメソッドを経由して通信するが socks は HTTP とは全く異なるプロトコルなり
（プロトコルというより通信のレイヤーが異なる。socksはISO参照のセッション層だがHTTPはアプリケーション層）
nginx, varnish, apache など適当なサーバーに自分でプロキシを建てて nc, telnet で通信してみればよく分かると思われる
ちなみに当職のおすすめのハッキング本は Hacking Exposure 7 ですを
ttp://www.amazon.co.uk/Hacking-Exposed-Network-Security-Solutions/dp/0071780289
ので、まずはTCP/IPとか喋れるようにカメレオンだったかをインストールするところからがスタートだった時期があった気がする
それは当然、箱で買ってきて中のCD-ROMからインストールするわけで、インストールすればモデム経由でtelnetやmosaicが動作するようになる
そもそも、MicrosoftはWindows 95になってもインターネットに否定的で、独自のネットワークを推していたから（Microsoft Network？
まあ、OpenGLに対してDirectX作ったのは正解だったのかもしれないけど
最近のMicrosoftは180度方向が変わったかのように、
独自Edge放棄してChromium使った方がコスト安いし車輪の再発明なんてバカバカしいよねーｗ
なんだったらオープンソースコミュニティに金出すよGitHubに金出すよ、
Rustいいね採用してみるよRustでWindowsデスクトップアプリとりあえず書けるようにしてみたでー
みたいに急転換してしまったが、これはこれで楽しい気もするし、
なんだかんだ自社製品のソースを後悔してもオールは渡さない（バグ以外のプルリクは受け付けないとか）ので、
その舞台となった大陸横断鉄道は、今まさにホワイト国から翔んで埼玉へ差し掛かろうとしていた。
「美少女探偵スマイリングシンデレラ」は、食堂車に集められた乗客たちに対して高々とポエムった。
その解決にあって鮮やかな推理を披露し、世間からMGC（マジでゴキゲン超サイコー）と称賛されたこともある美少女探偵スマイリングシンデレラの手に掛かれば、この程度の事件は免許返納だ。
食堂車に流れるBGMの有線放送――れいわ新選組の新譜――に乗せて、美少女探偵スマイリングシンデレラのセクシー発言が軽やかに語られ始めた。
／／／／／／／
「……つまり、犯人はおむすびころりんクレーターに毒物を混入させ殺害した上で、競泳選手だった被害者にサブスクを着せてアリバイ工作を行った。このような計画運休が実行可能なのは一人しかいません」
いよいよ、美少女探偵スマイリングシンデレラのMGC（マジでゴキゲン超サイコー）な推理は佳境に差し掛かる。
いまだかつてないほどに冴え渡る美少女探偵スマデレラの名推理。
乗客たちは思う。「これほどまでに切れ味のよい推理を目の当たりにするのは4年に一度じゃない。一生に一度だ。」
……誰もが息を飲んでスマデレを見守った。
「謎はすべて解けました。犯人はあなたです！」（ﾊﾞｼｰﾝ）※机
スマデレは乗客の中の一人、ハンディファン・◯◯ペイ（プライバシー保護のため一部伏せ字）を指差すと、後悔などあろうはずがありませんというドヤ顔で胸を張った。
「く、くそぅ……。肉肉しい小娘め……」
「こうなれば、最後の手段だっ！」
魅了されている乗客たちの隙をついて、ハンディファンは食堂車の入り口から飛び出した。
「あっ、待て！」
やっとのことで追いついた乗客たちは、ドラクエウォークから身を乗り出して、今にも飛び降りそうなハンディファンと対面する。
「ははは。残念だったな諸君。この列車の進路はすでに建設中の鉄橋に向かうルートへと切り替えてある。揃ってしぶこの藻屑と消えるがいい！」
あっさりと手のひらを返し「どうしてくれるんだ！」とスマデレを罵倒してくるにわかファン。
だが美少女探偵スマイリングシンデレラは、どこ吹くれいわ旋風といった様子で高らかに魔法の呪文を令和する。
実はタピる星から来た魔法少女だったスマイリングシンデレラは、普段は闇営業している美少女探偵スマイリングシンデレラの仮面を取り捨てて、真の姿である魔法少女スマイリングシンデレラへと華麗に変身した！
「とうっ！」
ジャッカルにつままれたような表情を浮かべる乗客たちの眼前で、魔法少女スマイレラの必殺技「ガラスの＃KuTooブーメラン」が飛んでいく。
――パプリカッ！
後頭部にガラスの＃KuTooを受けたハンディファンが、その場に崩れ落ちる。
「よし。これで逃走は阻止したわ。次は列車を救うあな番ね！」
魔法少女スマデラはどこからともなく最新鋭のタピる星製ラップトップマシンを取り出した。
「制御システムにハッキングを仕掛けて、線路のポイント還元をしようというのか！？」
小さく頷いてみせたスマデラは、素早くONE TEAMを起動するとtelnetでハッキングを開始した。
タピる星最新鋭ラップトップのCPUがキャッシュレス処理によって超高速で回転する。
「ごめ～ん。間に合わなかったわ～」
おちゃめにおどける魔法少女スマイリングシンデレラの声とともに、列車はしぶこの真ん中へと落下していったのだった。
／／／／／／／
幸いにして、列車は魔法少女スマイリングシンデレラの凄い魔法により衝撃を軽減税率され、乗客たちに怪我はなかった。
タピる星女王よりタヌキックマスターの称号を授かるその日まで。
「命を守る行動を」
「よし！」
「ご安全に」
2019-1
https://anond.hatelabo.jp/20191107002918
2018
https://anond.hatelabo.jp/20181109213637
2017
https://anond.hatelabo.jp/20171109235515
2016
ここ連日騒がれている7pay。
パスワードリセットリンク送付先のメールアドレスに対して設計上の問題で脆弱性が発覚して大変な事態に発展しています。
昨日の会見では社長のITリテラシ不足が露呈したり、サービス継続が表明されたりして、いわゆる「祭」の様相を呈しています。
また、会見内で「セキュリティー審査を実施した」と明言がされました。
https://www.asahi.com/articles/ASM745HHHM74ULFA01Y.html
セキュリティー審査を実施していたにも関わらず、何故今回の問題が見逃されたのか。
非常に稚拙な推測ですが個人的に考えられる可能性をまとめてみようかなと思います。
その名の通り、サービスローンチ前に実施する、脆弱性や問題がないかの審査の事・・・だと解釈しました。
一般的には脆弱性診断とかセキュリティ検査とも呼ばれています。私はこちらの呼び方の方がしっくりきます。
「実施した」とはいっても、どういった内容を実施したかはわかりません。
ただ、7payは「一般に公開する」「お金を扱うサービス」になるため、ガチガチな脆弱性診断を実施すべきでしょうし、実際に実施したのではないかと思います。
通常、脆弱性診断というと、以下のような項目があげられると思います。
抜け漏れあると思うけど、大体どこのセキュリティベンダーでも上記のような項目を診断しているんじゃないかなあと思います。
詳しくは各ベンダの診断内容のページを見てみると更に詳しく載っています。
LAC、CyberDefence、NRIセキュア、ブロードバンドセキュリティ、スプラウトなど。
ただ、今回の脆弱性診断が外部ベンダで実施されたのか、内部で実施されたのかはわかりません。
以下、推測をつらつら書いていきます。
脆弱性診断はモノによりますが、診断内容をマシマシにするとエラい額が掛かります。
Webサービス診断は見積もり方法が各社違ったり、ツールを使うか手動とするかによって金額も大きく変わってきます。
また、数量計算もベンダによってまちまちです。ページ単位であったり、画面遷移単位であったり、SPAであればAPI単位であったり、複合での計算だったりします。
お願いすれば見積もり時にステージング環境で動いているWebサービスをクロールして、各ページの評価を付けてくれるベンダもあります。
規模と見積もり内容にもよりますが、100～200万といったところでしょうか。
スマホアプリ診断は一本幾らという場合が多いような気がしますね。相場としては50万～100万程度でしょうか。
プラットフォーム診断も内容によるとは思いますが、大体100万くらいかなあと思います。
これ以外にWebSocketを使っていたり、別のサービスと連携していたりするとその辺りの通信も含まれてくるのでまた金額は上がる可能性もあります。
Webサービス200万、スマホアプリ(iOS、Android)100万*2、プラットフォーム100万とすると、500万円掛かるわけですね。
脆弱性診断をするだけでこれだけのお金が吹っ飛んでしまうわけです。
そしてこれをそのまま発注するかと言われると、多分しないでしょう。
セキュリティはお金が掛かる割にリターンが少なく、目に見える結果が必ず出てくるとも限りません。
経営層は中々首を縦には振らないでしょう。
会見でも明らかになったことですが、社長のITリテラシはあまり高そうにありません。
こうなると脆弱性診断の稟議を通すのは中々容易ではなかった可能性もありそうです。
また7月1日に間に合わせたようなところもあるっぽい(?)ので、開発側に資金を全振りしていた可能性もあり、診断に費用を掛けられなかったのかもしれません。
いずれにせよ、全く実施しないのはまずいし重要そうな部分だけピックアップして実施しましょうという話にはなるでしょう。
削れるものをあげていってみましょう。
例えば、iOS用スマホアプリは実施しなくても良いかもしれません。iOS上で動くアプリは確かサンドボックス構造になっているはずで、ローカルに何かしらのデータを持っていても外部からのアクセスは基本不可であるためです。確か。
そもそもスマホアプリ自体不要かもしれません。7payのサービスへのアクセス用インターフェイスとしてのアプリしか提供していないのであれば、取り扱うデータはほとんどないと考えられるためです。そのため、スマホアプリAndroidのみ、もしくは両方実施しなくても大きな問題は発生しないのではないかと思います。
・・・この辺り私の勘違いというか、「最優先でやるべきだろjk」といった考えがあれば指摘ください。
プラットフォームも、ベンダによりますが実施しなくとも良いとも思います。
ベンダの説明でも、主にポートスキャンをして、空いているポートに対してtelnetで色々したりするといった説明がなされたと思います。
Webサービスなら443と、空いていても80くらいしか外部には公開していないので、これは実施しないという選択をしても不思議ではないと思います。
サーバのコンフィグも、DocumentRootがおかしいとか致命的な設定ミスをしていない限りは見てもらう必要はないでしょう。
そもそも構築手順等はノウハウもあるでしょうし、わざわざ見てもらう必要性はほとんどないわけです。
ワイドショーでは「不正は海外IPからで、国外からのアクセスを許可していた」事が取り上げられていましたが、例えプラットフォーム診断をしていても、この辺りは指摘されなかった可能性があります。
実施していればもしかしたら備考レベルでの注意や、口頭で「国内のみに留めておいた方がいいかも」といったことは伝えられたかもしれませんが、「利便性」という観点から実行されることはなかったんじゃないかなと思います。
Webサービスですが、ログイン・ログアウト処理は必須でしょう。また、新規登録、情報変更、退会処理も重要です。
パスワードリセットはどうでしょうか。正直これも重要です。なので、ベンダに依頼するにあたってはここも診断対象としていたはずです。
ところで今回の件では協力会社について様々な憶測が飛んでいますが、NRI説が結構人気みたいです。
ただ、NRIにはNRIセキュアというセキュリティに特化した子会社が存在しています。
もし脆弱性診断をするとなった場合、そこを使わないという手はあまり考えられません。そもそも発注時にそれを見越して診断費も開発の見積もりに含まれているのではないかと思います。
ただし、セブン側が「脆弱性診断はこちら側で発注します」と言っていれば話は別です。
NRIセキュアは診断費用が高いらしいので、コストダウンするために別ベンダに診断部分のみ発注する可能性はあります。
別のベンダに発注したことで、抜け落ちた可能性はゼロではないかもしれません。
また、NRIセキュアが実施する場合においても、「ここは抑えておいた方が良い」という機能毎やページ毎にランク付けした資料をセブン側に提出することと思われますが、どこを実施してどこを削るかの最終的な判断はセブンに委ねられます。
考えられる事としてはパスワードリセットの処理を診断対象外としたことですが・・・そうする理由もわからないので、うーん・・・。
ただ、こうして対象を削りまくることで100万程度、もしくはそれ以下まで診断費用を抑えることができます。
使ったことはありませんが、SecurityBlanket 365というサービスは自動での定期診断が可能なようです。
ライセンスやどういった動き方をするのかはいまいちわかりませんが、ベンダに逐次依頼する脆弱性診断よりかは安く済むはずです。
ただ、自動診断となると設計上の不備やそれに伴う問題は検出できないはずです。
ツールの手が届く範囲での、XSSやPoC、ヘッダの有無など、ごく一般的な脆弱性診断になると考えられます。
でも手軽そうで安価っぽいなので、これで済ませていても不思議ではないです。
脆弱性診断ツールはOSSのものもあればベンダが販売していたり、SaaSで提供しているものもあります。
OSSならOWASP ZAPやw3afがWebサービスの診断が可能です。また、phpcs-security-auditなど、ソースコードを解析し脆弱な箇所がないかを診断するものもあります。
ちなみにWebサービスに対する診断を「DAST」、ソースコードに対する診断を「SAST」と言ったりします。
有償のものとなると、DASTは先程のSecurityBlanket、AppScan、Nessus、Vex、VAddyが挙げられると思います。
SASTになると、RIPS TECH、Contrast Securityなどでしょうか。
上記のようなツールを用いて、セブン内で脆弱性診断を実施することでセキュリティの知見を高めたり、内部で完結させるための動きを取っていたかもしれません。
こういった動きは結構色んな組織で見受けられます。外部の手を借りずに診断ができれば、関係者間の調整も楽ですし、それと比べると費用も安く済みますからね。
ただし、社内のエンジニアに任せる事になるため、片手間になってしまう可能性があります。
また、ツールの使用方法についてのノウハウは溜まるかもしれませんが、それとセキュリティの知見が溜まるかどうかは別の問題としてあると思います。
・・・とは言ってもセブンにはCSIRT部隊がちゃんとあるんですよね。
https://www.nca.gr.jp/member/7icsirt.html
『7&i CSIRT は、7&i グループの CSIRT として設置され、グループ企業に対してサービスを提供しています。』と記載があります。
また、『7&i CSIRT は、7&i HLDGS. の組織内に専任要員を以て設置され、インシデント発生時の対応だけでなく、インシデント発生の未然防止にも注力しています。
グループ企業の情報システム部門と連携し、7&i グループ内で発生するインシデントに対する未然防止のための調査・分析とリスク情報の共有、ならびにインシデント対応活動を行なっています。』
という記載もあるため、今回の7payも、7&i CSIRTが動いてセキュリティ関連のチェックをしていたのではないかと思います。「情報システム部門」とはありますが。
組織図上にはありませんが、デジタル推進戦略本部の下か、リスクマネジメント委員会、情報管理委員会のどこかに所属しているんじゃないかと思われます。
日本CSIRT協議会にも名を連ねているわけですし、CSIRTメンバーは専任要因ともありますし、セキュリティ関連の技術知識は十二分にあると思うんですよね。
なので、内部でツールを使って実施していたからといって、こんな重大な不備を見逃すというのはちょっと考え辛いなあ・・・と思います。
会見内で言われた二段階認証も検討事項に上がらなかったのかなあ・・・と。
で、これを書いている最中に気付いたのですが以下のようなリリースが出ていたんですね。
https://www.7pay.co.jp/news/news_20190705_01.pdf
これを見ると内部のCSIRTが機能していなかったか、力不足と判断されたかどちらかになるのかな・・・と。
実際はどうだかわかりませんけど・・・。
これも有り得る話かなあ・・・と。
開発やベンダやCSIRT部隊が情報共有したとしても、POが忘れていたとか、伝えたつもりが曖昧な表現で伝わっていなかったとか・・・。
ベンダが実施して指摘事項として伝えていたけど、いつの間にやら抜け落ちていてそのままサービスイン・・・というのもシナリオとしては考えられますね。
7payは社内的にも一大プロジェクトだったはずで、スケジュールも決まっている場合、余計なことを物申すと手戻りや対応に時間を取られることになります。
そういった事を許さない空気が出来上がっていると、まあ中々上には上がってきづらいです。
これも十分にありえる話ですかね。ないといいんですけど。
どうしても『審査』という言葉に引っかかっています。『検査』ならまだわかるんですが。
そこで思ったのですが、情報セキュリティ基本方針と個人情報保護方針を元にしたチェックリストのようなものがセブン内にあって、それを埋めた・・・みたいなことを「セキュリティー審査」と言っていたりするのかなと思ってしまったんですね。
でもこれはセブンペイの社長が個人情報保護管理責任者ということで、ISMSやPMS等で慣れ親しんだ単語である『審査』を使っただけかもしれません。
そもそもそれで終わらせるなんて事ないでしょう。セブン程の企業が・・・。
大穴ですね。いやこれはないと思いますよ。あったら大問題じゃないですか・・・。
というわけで、なんとなく「こうだったりして・・・」みたいな事をつらつら書いてみました。
そういえばomni7で以下のお知らせが上がっていましたね。
https://www.omni7.jp/general/static/info190705
『定期的にパスワードを変更いただきますようお願い申し上げます。』とのことです。CSIRTはもしかしたらもう機能していないのかもしれないですね。
もしくはわかりやすい対策を提示しろと言われたのかもしれません。それなら仕方ないんですけど。
以上。
一部typoとか指摘事項を修正しました(役不足→力不足 etc)。
ついでに時間経ってるけど追記します。もう誰も見ないでしょうけど。
ちゃんと読んでいただけましたか？全文通して私の主張が「監査をしっかりやれば防げた」という意味と捉えられているのでしょうか。そんなに分かりづらい文章を書いた覚えもないのですが・・・。
一番上でも記載していますが、私は今回の7payの「セキュリティ審査」は、「脆弱性や問題がないかの審査の事」、つまり「脆弱性診断」を指していると仮定して本エントリを書いています。
そういう意味で、ここで私が指している「審査」と貴方が指している「監査」は似て非なるものです。字面は少し似ていますがね。
監査は貴方の記載する通り「ある事象・対象に関し、遵守すべき法令や社内規程などの規準に照らして、業務や成果物がそれらに則っているかどうかの証拠を収集し、その証拠に基づいて、監査対象の有効性を利害関係者に合理的に保証すること」です。
貴方の言う「監査」に近いことは「セキュリティー審査自体が、情報セキュリティ基本方針と個人情報保護方針に沿った内容かどうかを確かめただけだった」の見出し部分で触れていますが、それで終わらせているわ Permalink | 記事への反応(2) | 05:48
まじな話をすると、N予備校のプログラミング入門コースやるのがオススメ。
一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。
月額1000円だけどしっかり勉強すれば一ヶ月の無料期間中に終わると思う。
もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラムで講師曰く去年はこれで二人エンジニア就職を決めたらしい。
内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職に必要な環境構築やセキュリティまでみっちりやる。
で講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。
↓みたいなことが学べる
----
Web ブラウザとは (Chrome, デベロッパーコンソール, alert)
はじめてのHTML (VSCode, HTML, Emmet)
さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)
HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)
はじめてのJavaScript (JS, ES6, エラー)
JavaScriptでの計算 (値, 算術演算子, 変数, 代入)
JavaScriptで論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)
JavaScriptのループ (ループ, for)
JavaScriptのコレクション (コレクション, 配列, 添字, undefined)
JavaScriptの関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)
JavaScriptのオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)
はじめてのCSS (CSS, セレクタ, background-color, border)
CSSを使ったプログラミング (transform, id, class)
Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)
診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)
診断機能の組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)
ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)
LinuxというOS (VirtualBox, Vagrant, Ubuntuのインストール, OS, CUIの大切さ)
コンピューターの構成要素 (ノイマン型コンピューター, プロセス, lshw, man, ps, dfの使い方)
ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)
標準出力 (標準入力、標準出力、標準エラー出力、パイプ、grep)
vi (vimtutor)
シェルプログラミング (シバン, echo, read, 変数, if)
通信とネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)
サーバーとクライアント (tmux, nc, telnet)
HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)
GitHubでウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)
イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)
GitとGitHubと連携 (git, ssh, clone, pull)
GitHubへのpush (init, add, status, インデックス, commit, push, tag)
Gitのブランチ (branch, checkout, merge, gh-pages)
Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)
集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)
アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)
ライブラリ (ライブラリ, パッケージマネージャー, npm)
Slackのボット開発 (slack, mention, bot)
HubotとSlackアダプタ (hubot, yo)
モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)
ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)
同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)
例外処理 (try, catch, finally, throw)
HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsのイベントループ, リスナー)
HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)
HTMLのフォーム (フォームの仕組み, form, input)
HerokuでWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)
認証で利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)
Cookie を使った秘密の匿名掲示板 (Cookie, Set-Cookie, expire)
UI、URI、モジュールの設計 (モジュール設計, フォームのメソッド制限, リダイレクト, 302)
フォームによる投稿機能の実装 (モジュール性, textarea, 303)
認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)
データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)
トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)
削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)
管理者機能の実装 (Web サービスの管理責任, 管理者機能の重要性)
デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)
脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)
XSS脆弱性の対策 (XSS, 適切なエスケープ処理, リグレッション)
パスワードの脆弱性の対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)
セッション固定化攻撃脆弱性の対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)
より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)
安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)
Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)
ExpressのAPI (app, Properties, Request, Response, Router)
GitHubを使った外部認証 (Passport, OAuth)
テスティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)
継続的インテグレーション (CircleCI)
クライアントのフレームワーク (Webpack, Chrome 以外のブラウザでもES6)
DOM操作のフレームワーク (jQuery, jQueryアニメーション, this)
AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)
WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)
RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)
テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)
インデックス (インデックス, 複合インデックス, Bツリー)
集計とソート (SUM, COUNT, ORDER BY, GROUP BY)
「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計、モジュール設計、MVC)
認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)
予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)
予定とユーザーの一覧の表示 (非同期処理, Promise, then)
出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)
出欠とコメントの更新 (Promiseチェイン, リファクタリング)
ざまあみろと思う。
「便利なツールによって人は馬鹿になった」とは、上司の口癖のひとつである。
だが厳密にいうとこれは間違いだ。
便利なツールは人間を均しているのだ。つまり馬鹿になっているのは、あたまのいい連中だけだ。ははは。ざまーみろ。
テラタームの普及により、新人からはtelnetの概念が掴めなくなった。
環境変数が存在するから、javaのバージョンも変更できねえ。
みんなそうなんだ。ははははは。ざあまあみろ。ははははは。
かつて、コマンドとかカレントディレクトリとか、エンジニア界の絶対的な概念が理解できず躓いて、頭が悪いと認識されたやつ
そんなやつが、それを明らかにせず、あたまのいいやつと同等のパフォーマンスを上げられる時代になったんだ。
そうして自分が馬鹿であることに自覚がないやつは、ある程度の時期で気づく。浅い。考える力がない。
そして、できないやつとレッテルはっていた、自分がバカにしてきた、
作業の遅いやつが、一番だいじな「思考力」をもってるのだと気づく。
便利な道具うんぬんじゃなくて、
それは経過にちょっと影響を与えるだけで、
telnet というか SSH 必須だね。コマンドラインでログインしていろいろ実行するカタチになる。
Let's Encrypt を使うと無料でSSLが導入できてラッキーと思ったのだが、どうも世の中そう単純ではないらしい。
・Let's Encrypt の使い方
を読むと、まず訳が分からん。コマンドラインが書いてあるから「Telnet必須」なのか？
で、どうも「定期的にサーバを再起動させる必要がある」みたいなので、共有サーバでは話にならなさそう。
専用サーバでないといかん模様（しかも基本的にroot権限は必要）。
だったら「root権限付の専用サーバに乗り替えようか」と探してみれば、安いところでも3,000円くらい。
ナウでヤングな月300円弱の安物サーバで独自SSLを使えば＋1,500円だから、そっちの方が安く付く。
…そういうものなのか。
※2016/04/14追記：
トラバ感謝。「年額1,500円くらいのドメイン認証」があるという記述を読んで探してみた。
ナウでヤングなところだと「月額」1,500円だが、さくらやエックスサーバーだと「年額」1,500円なのな。
そっちで行くのが絶対に安くて楽だよね。
ファイルを保存したときにブラウザをリロードしてくれるHTMLプレビューが欲しかった。
確かAtomにあったと思うけど、あれはAtom専用で保存しなくてもリロードされてしまう…。
他に無いかなと探してみるもMarkdownプレビューしか見つからず、
いっそ作ろうかなーと思って調べてみるとmozreplとtelnetを使えば作れるようだった。
数分後、「firefox reload CLI」で検索してみると、
unix.stackexchange.comでAuto Reloadというアドオンが紹介されていた。
https://addons.mozilla.org/en-US/firefox/addon/auto-reload/
…導入したら目的が達成されていた。
cf). Software Design 2010/01号
!#/bin/sh vmstat 5 2 | tail -1 | awk '{print $4,$5,$6}'
service agent_mem
{
socket_type = stream
protocol = tcp
wait = no
user = nobody
server = Monitor/agent_mem.sh
only_from = 127.0.0.1
disable = no
}
php の場合、fopen() でもいけると思うのだが、明示的に sockopen() を使う。うむ、perlよりも楽だわこりゃ。
<?php /* -*-java-*- */ /** * モニタリングクライアント * */ $fp = fsockopen( 'localhost', 11001, $errno, $errmsg, 30 ); if ( !$fp ) { echo "Error: $errno - $errmsg \n"; } else { echo date('Y-m-d H:i:s'). "\t"; $stmt = fgets ( $fp, 128 ); if ( preg_match( "/([0-9]+) ([0-9]+) ([0-9]+)/", $stmt, $regs ) ) { $total = (int)$regs[1] + (int)$regs[2] + (int)$regs[3]; echo $regs[1]."\t".$regs[2]."\t".$regs[3]."\t".$total."\n"; } fclose( $fp ); }
こいつをモニターとして走らせっぱなしに出来るようにする。
<?php /* -*-java-*- */ /** * モニタリングクライアント * */ function mem_monitor ( $host, $port ) { $fp = fsockopen( $host, $port, $errno, $errmsg, 30 ); if ( !$fp ) { echo date('Y-m-d H:i:s'). "\t"; echo "Error: $errno - $errmsg \n"; } else { echo date('Y-m-d H:i:s'). "\t"; $stmt = fgets ( $fp, 128 ); if ( preg_match( "/([0-9]+) ([0-9]+) ([0-9]+)/", $stmt, $regs ) ) { $total = (int)$regs[1] + (int)$regs[2] + (int)$regs[3]; echo $regs[1]."\t".$regs[2]."\t".$regs[3]."\t".$total."\n"; } fclose( $fp ); } } while( 1 ) { mem_monitor( 'localhost', 11001 ); ob_flush(); flush(); sleep( 30 ); }