今回はチャットで発言する内容にNGワードのチェックを入れたいと思います。
特定のキーワードが含まれている場合、「？」など伏せ字に置換する機能です。
この実装方法は2つのパターンが考えられます。
あくまでFirestoreで実装した前提ですが、いずれも一長一短ありますがここはひとまずサーバ側で実装してみたいと思います。
続きを読む
FirebaseのCloud Functionsを利用すると巷で話題のサーバレスなシステムを構築することができます。外部にURLを公開してRESTful APIなども作成できますし、Firebase内のイベントに合わせて特定の処理を実行することが可能です。もちろんFirestoreやRealtimeDatabaseなどと連携することもできます。
functionsはNode.js上で動作するプログラムを記述することになりますので、すでにJavaScriptやTypeScriptの経験がある方なら特別な言語仕様を覚える必要が無いのも魅力でしょう。
Firebaseのコンソールからプロジェクトを作成します。すでに利用しているプロジェクトがある場合はそちらを使用しても大丈夫です。
その後CLIツールのインストールを行います。詳しくは以下のページの「1 環境の準備」の項、Googleアカウントでログインするまでの部分を参照ください。
すでにFirebaseで利用しているディレクトリがあればそちらに、無ければ新規にディレクトリを作成しカレントディレクトリを移ります。今回はすでに使ってるプロジェクトがあったのでそちらに移動しました。
$ cd miku3net
ではおもむろに初期化コマンドを叩きます。
$ firebase init functions
前々回でFirestoreを利用してリアルタイムな通信が行えるチャットを、前回はユーザー認証を導入しました。
今回は自分が書き込んだログを削除する機能を追加してみます。
前回、Firestoreを利用してリアルタイムな通信が行えるチャットを作成しましたが、今回はこのチャットに書き込みためにはログインが必要な状態に仕様変更したいと思います。
今回はFirestoreでリアルタイムに情報のやりとりをしてみます。こういったときのサンプルは概ねチャットと相場が決まっていますので、ひとまずデータの授受ができる最低限のコードを書いてみます。
詳しくは以下のページをご覧くださいませ。
今回はひとまず動くものを作るのを目標としますので、ユーザー管理は行わず一つの部屋にひたすらメッセージがたまっていく作りにします。
また「ルール」は今回も全開放しています。
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if true;
}
}
}
首都高にチャリが突撃したというニュースを時々見かけますよね。つい先日も話題になっていました。
高速道路を走る１台の自転車。自転車が高速を走ることはもちろん禁止されていて、非常に危険な状態です。これは、１４日午後１１時すぎ、首都高速の霞が関トンネル付近を自転車が走る様子を捉えたドライブレコーダーの映像です。映像を提供した男性によりますと、自転車は時速およそ５０キロで走っていたということです。
普段首都高を利用しない方であれば、普通に考えればそんなことありえない、そんな風に思っていた時期が自分もありました。ここで自分がいつも利用しているICの動画が手元にあったのでアップしてみました。
荏原IC(入り口)
続きを読む
Google Apps Script(以降GAS)は、多少語弊がありますが雑に言うとGoogleDrive上で動作させるプログラムの実行環境です。今回は初歩的な利用方法についてメモしておきます。
GASはEXCELやWORDなどMS Officeで言うところのVBAのGoogle版だと思えばイメージしやすいと思います。GoogleSpreadSheetやDocumentなどGoogleのOfficeSuiteはもちろん、その他のGoogleのサービスと連携することが簡単にできるのが強みですね。またGASの開発言語はJavaScriptとなっており、すでにJSが使える方にとっては新たに言語仕様を学習するコストがないのも魅力です。
制限はありますがこれらがすべて無料で利用できる点も大きいですね。
今年は初日に確定申告してきたのですが、税務署の壁面に混雑予報が貼ってあったのでパシャリ。
確定申告の混雑状況予測が張り出されてたのだけど、最終週はアルマゲドンらいしいのでご注意を。たぶん月末が一番空いてるんじゃないかな。 pic.twitter.com/GWERc8oxgN
— 勝部麻季人 🍲 (@katsube) 2019年2月18日
これはあくまで川崎北税務署の見解のようですが、他の地域でも参考になるかもしれません。
やっぱり最終週はアルマゲドン状態みたいですねｗ
自分の場合は11:30に到着し、すべて終わるまで90分程度でした。
昨年は開始してから数日経過してから訪れたので待ち時間は5秒くらいでしたがｗ あと午前中よりも午後の方が空いてそうです。みなさん午前中に税務署に直行し午後から仕事という思考ではないかと。
行列に並んでる時間は長いのですが、実際に窓口の方に書類を渡してからは1分もかかりませんでした。逆に不安になるから少しくらいチェックしてほしいｗ あとは税務署から電話がかかってこないことを祈るのみです。
続きを読む
こちらのニュースが話題になってますね。
国土交通省は、自動車メーカーが車に搭載されたシステムのプログラムを更新する場合、国の許可制とする方針を固めた。今後、自動運転技術による高速道路での車線変更といったプログラムの更新が想定されるため、国が事前に安全性を確認できるようにする。今年３月にも、開会中の通常国会に道路運送車両法の改正案を提出し、２０２０年の施行を目指す。
個人的に何かしらのチェック機構は法整備も含めて必要だと思ってます。
実際に自動車の制御プログラムのセキュリティチェックなどを依頼されている企業の方と会議をする機会があり、割と簡単にハッキング出来て勝手に動かすことができるというエピソードを耳にしました。こういった脆弱性や何かしら内部の人間が悪意を持ったコードを埋め込む可能性が今後出てくる可能性は非常に高いと思います。
クルマがネットワークにつながり、それらの情報をモトに制御される未来がやってくると、命に関わるリスクが高まると言わざるを得ません。特に自動制御プログラムが乗っ取られた日には、大量の自動車を同時に操作した自爆テロなどハリウッド映画的な展開が現実の物になることが簡単に想像できます。そこまで行かなくてもGPSなどと連動すれば位置情報などプライベートな情報も抜き放題です。
それら悪意のあるコードが混入しやすいのは新車として購入する段階よりも、運用フェーズに入ってからだろうと考えればこの対策は当然と言えば当然かもしれません。
前回の続きです。
狙われやすいアカウント名ランキングに続きまして、どこの国からアタックを受けているかも調査してみました。…まぁなんとなく結果はわかっていましたが、数値化するのが大事ですよね！（虚空を見つめがら）
| # | カウント | IPアドレス | 国CD | 国名 |
|---|---|---|---|---|
| 1 | 43,148 | 218.92.1.163 | CN | 中国 |
| 2 | 43,147 | 58.242.83.7 | CN | 中国 |
| 3 | 43,147 | 218.92.1.174 | CN | 中国 |
| 4 | 43,147 | 218.92.1.173 | CN | 中国 |
| 5 | 31,139 | 112.85.42.196 | CN | 中国 |
| 6 | 27,063 | 218.92.1.181 | CN | 中国 |
| 7 | 21,800 | 112.85.42.238 | CN | 中国 |
| 8 | 20,223 | 112.85.42.197 | CN | 中国 |
| 9 | 13,908 | 218.92.1.172 | CN | 中国 |
| 10 | 10,678 | 112.85.42.232 | CN | 中国 |
| 11 | 9,605 | 112.85.42.233 | CN | 中国 |
| 12 | 8,584 | 112.85.42.151 | CN | 中国 |
| 13 | 6,735 | 58.242.83.17 | CN | 中国 |
| 14 | 6,666 | 193.201.224.216 | UA | ウクライナ共和国 |
| 15 | 3,559 | 122.194.229.49 | CN | 中国 |
| 16 | 3,359 | 112.85.42.231 | CN | 中国 |
| 17 | 3,228 | 112.85.42.193 | CN | 中国 |
| 18 | 2,558 | 101.91.215.199 | CN | 中国 |
| 19 | 2,548 | 101.91.215.80 | CN | 中国 |
| 20 | 1,818 | 188.92.77.235 | LV | ラトビア共和国 |
| 21 | 1,505 | 122.194.229.18 | CN | 中国 |
| 22 | 1,483 | 106.13.34.94 | CN | 中国 |
| 23 | 1,209 | 188.92.75.248 | LV | ラトビア共和国 |
| 24 | 980 | 59.46.135.42 | CN | 中国 |
| 25 | 828 | 146.0.228.106 | DE | ドイツ連邦共和国 |
| 26 | 719 | 206.189.149.126 | SG | シンガポール |
| 27 | 606 | 112.85.42.235 | CN | 中国 |
| 28 | 575 | 54.169.36.191 | SG | シンガポール |
| 29 | 408 | 185.246.128.25 | SE | スウェーデン王国 |
| 30 | 402 | 103.207.38.197 | VN | ベトナム |
| # | 行ラベル | 合計 / カウント | 割合 |
|---|---|---|---|
| 1 | 中国 | 353,341 | 87.5079% |
| 2 | アメリカ合衆国 | 8,128 | 2.0130% |
| 3 | ウクライナ共和国 | 6,939 | 1.7185% |
| 4 | フランス共和国 | 4,729 | 1.1712% |
| 5 | ラトビア共和国 | 3,039 | 0.7526% |
| 6 | シンガポール | 2,893 | 0.7165% |
| 7 | ドイツ連邦共和国 | 2,270 | 0.5622% |
| 8 | インド | 1,975 | 0.4891% |
| 9 | ロシア | 1,629 | 0.4034% |
| 10 | 大韓民国 | 1,504 | 0.3725% |
| 11 | ブラジル連邦共和国 | 1,443 | 0.3574% |
| 12 | イギリス | 1,346 | 0.3333% |
| 13 | オランダ王国 | 1,176 | 0.2912% |
| 14 | カナダ | 922 | 0.2283% |
| 15 | ベトナム | 899 | 0.2226% |
| 16 | インドネシア共和国 | 857 | 0.2122% |
| 17 | イタリア共和国 | 688 | 0.1704% |
| 18 | ポーランド共和国 | 634 | 0.1570% |
| 19 | コロンビア共和国 | 626 | 0.1550% |
| 20 | スウェーデン王国 | 525 | 0.1300% |
| 21 | 日本 | 494 | 0.1223% |
| 22 | メキシコ合衆国 | 483 | 0.1196% |
| 23 | 香港 | 445 | 0.1102% |
| 24 | 中華民国 | 441 | 0.1092% |
| 25 | アルゼンチン共和国 | 428 | 0.1060% |
| 26 | タイ王国 | 388 | 0.0961% |
| 27 | スペイン | 276 | 0.0684% |
| 28 | イラン・イスラム共和国 | 222 | 0.0550% |
| 29 | 南アフリカ | 215 | 0.0532% |
| 30 | マレーシア | 211 | 0.0523% |
中国からのアクセスをブロックすれば80%以上のアタックを防げる結果になりました＼(^o^)／
ちなみに日本からのアタックは494件、0.1223%でした。
続きを読む
専門学校の生徒用にAWS(Lightsail)でサーバを一台用意しているのですが、(乗っ取られてはいない物の)意図せずハニーポット状態になっていたので、どのアカウント名が狙われていたか軽く集計してみました。
サーバ自体は2018年12月16日に立ち上げたのですが、現存する最古のデータが1月6日となっていたためざっくり1ヶ月間(27日程度)のデータと思っていただければと。
この間の/var/log/secureを集計すると約45万件のアタックを受けていた計算になります。
$ sudo grep -c 'Failed' /var/log/secure*
/var/log/secure:18982
/var/log/secure-20190113:127392
/var/log/secure-20190120:46130
/var/log/secure-20190127:132703
/var/log/secure-20190203:78543
403,750件
$ sudo grep -c 'Invalid' /var/log/secure*
/var/log/secure:1849
/var/log/secure-20190113:10378
/var/log/secure-20190120:11506
/var/log/secure-20190127:9932
/var/log/secure-20190203:14927
48,592件
FirebaseのHostingを利用すれば基本無料で静的なサイトを運用できます。
独自ドメインも追加でき、何らならSSL証明書も無料でついてくるという太っ腹。もしサイトが成長し膨大なアクセスが発生した場合は課金する必要がありますが、こちらがプラン変更しない限り料金は一切発生しません。
ドメインやDNSの準備や設定、本番へデプロイ(反映)するにはコマンドを叩く必要がありますが、それさえ乗り越えてしまえばさほど難しくはありません。
サイトを設置するためのプロジェクトが必要になります。
プロジェクトの作成方法は以下のページを参照くださいませ。
Hostingの利用は原則としてTerminalなどのCLI上でコマンドを叩いて行いますので、まずはその準備を行います。
Node.jsがインストールされている必要があります。公式サイトからダウンロードしインストールしてください。「推奨版」と書かれている方でOKです。
もしmacOSを利用されている場合で、凝った設定をしたい場合は以下のページを参照くださいませ。
Node.jsをインストールするとnpmという、様々なライブラリやツールを取得できる便利なツールが同時に入るのですが、これを使ってインストールを行います。
$ npm install -g firebase-tools
今回は以下のバージョンが入りました。
$ firebase --version
6.3.0
2018年分の確定申告終了まで残り68日となりました（執筆時点）
みなさん順調に入力進んでますか？こちらは地獄ですｗ
今回は自分でも時々わからなくなる勘定科目についてメモ代わりにまとめました。
定期的に思いついたら更新したいと思います。
私は大きく2つの事業を行っております。
あくまでこちらの範囲で登場するの勘定科目のうち、私が利用している物に限定されます。
それでは張り切ってどうぞ。
続きを読む
過去、AWSを大きな組織や複数のプロジェクトで利用する場合、AWSのアカウント自体を複数用意して利用していたわけですが、2017年2月に登場した「AWS Organizations」を利用すると、請求先の一元化や、ユーザーの権限管理が一括して行えます。
それぞれのアカウントが独立して存在しており、請求情報やユーザー管理もそれぞれ行う必要がありました。
図はイメージですが、AWSアカウント内に「組織」を作成することで、独立した世界を用意することができます。
請求情報は「親」で一元管理できます。
また必要があれば各ユーザーに対し制限をまとめてかけることもできます。
「子ユーザー」はルートユーザーと同じ権限が与えられますので、組織内のユーザーから見ても、使い勝手はこれまでと変わりません。また各組織が影響を与えることもありませんので万が一の場合の影響範囲を心配する必要がないのもこれまでと変わらないポイントです。
もうどこからアカウント情報が漏れるかわかりませんからね。昨年GitHubの2段階認証の設定をしたように、今回はAWSのアカウントにも施したいと思います。特にルートアカウント。
詳しくはAWSの「多要素認証」のページに書かれていますが、実質的にスマホアプリか専用のデバイスを用いることになります。
要はスマホのアプリで認証するタイプ。
Google認証とAuthy2、WindowsPhone用の「認証システム」に対応しているようです。
| OS | アプリ |
|---|---|
| Android | Google認証 / Authy2 |
| iOS | Google認証 / Authy2 |
| WindowsPhone | 認証システム |
物理的な認証デバイスとの連携にも対応しているようです。
USBポートに差し込んで指紋を読み取らせるだけで、ワンタイムパスワード的な物が発行されログインできる便利なやつですね。興味のある方はAmazonからも購入できるのでどうぞ。
新規受付はすでに終了したそうです。また既存ユーザーも2019年1月31日で提供終了とのこと。がーん。本命だったのに(´・ω・`)
