スパムや不正アクセスとFTPについて

この2年ぐらい、主にWordPressで構築したサイトを中心にスパム、 不正アクセスとサーバー管理者からのメールとクライアントとのやり取りを行う機会が増えてきた。

主要因はWordPress本体やプラグインの脆弱性をついたもので WordPressやプラグインをアップデートすることで、一昔前は収束。
ところが、最近は、侵入時に確実にバックドアを仕掛け、数日〜数ヶ月後にそれを使ってスパムメールを送るプログラムを稼働させたりすることで検知、 発覚といったことが増え、何をすればいいのかそのやり方に手詰まり、学生時代の友人に頼ったりもした。

そして、今のところ対策として一番があるのがFTPアクセス制限。

そのほか、サーバーによってはHTTPのIP制限をしてくださいとアナウンスしているところもあるけれど、 法人の回線からだとアクセスできないことが起こったりするので、現実的な方法はFTPアクセス制限。

ひとつ間違えると自分自身の端末からもアクセスできなくなるので実装するには注意は必要ではあるものの、 サーバー側でブラウザベースのファイル管理システムがあるところなどは比較的簡単に制限をしやすい。

もし、FTPアクセス制限をしても治らない場合は、アクセスできる端末やサーバーそのものにバックドアがある場合があるので、 その場合はサーバー管理者に原因を探ってもらう、サーバーを移転してしまうといった方法が考えられるけれど、 できれば、そうなる前に対処しておきたい。

問い合わせフォームの再開について

お問い合わせフォームの処理をフロントエンドに寄せる

問い合わせフォームの処理の送信するまでのところを全てフロントエンド側のJavaScriptをベースに処理できるものに変更しました。

今までのHTMLベースのボタン押下後の処理をJavaScriptで行うだけでなく、
フォームの描画からJavaScriptでコントロールする方式に変更しています。

フロントエンド側へ寄せるメリット

入力内容のバリデーションパターンなどをフロントで管理させる事で、
サーバーサイドの処理を送信のみに絞り、また質問内容などをフロント側で管理することで、
メンテナンスコストを下げる事ができます。

フロントエンド側へ寄せるデメリット

一番大きなデメリットはAMPへの対応が難しく、送信するデータを全てフロントエンド(ブラウザ)側で
準備する必要があるので改ざんされてしまう可能性は0にできないため、
改ざんを防ぐためのロジックや機能をサーバー側に準備させる必要があります。

実際に導入するにあたり、心がけていたところ

今回はサイトのリニューアルでMarionette/Backboneを本格的に導入して、
HTMLのページ生成などにgulpとejsという少し古いものを使い、
ロジカルなところをできるだけライブラリやプラグインではなく、
自分自身で書いて実装する様にしました。

reactやvueベースでとなるとバックエンドのAPI周りの開発コストが従来の比べれば減るものの、
フレームワーク自体の更新ペースが早く、それに付随してさまざまなものも変化が激しいため、
数ヶ月〜1年以上同じバージョンのものを使い続ける事がセキュリティ面など含めて現実的ではないので、
今回は少し古い技術を使って実装しています。

将来的にはAPI周りがnode.jsベースで実装できるサーバー環境が整えば、vueなどで換装したいと考えています。

コーディングを専門に扱う事業者の紹介コンテンツについて

コーディング専門の事業者をまとめたコンテンツを作る

問い合わせでかなりの割合と頻度があるのがコーディングを専門に取り扱う事業者、 SEOを専門に扱う業者からのセールスコンタクト。
そこで、その事業者をまとめ、コンテンツにすることにしました。

現状、Web業界で何か仕事を依頼しようとする場合はデザインとセットであったりと、 コーディングのみというのは考えにくく、制作会社が量の多いコーディングを外注するといったことが多いのではないかと 推測し、コーディング専門の紹介サイトが多数ある中、どこにすればいいのかわからない、 相見積もりのサイトへ掲載?といった状態になる中、ちゃんと特徴を捉えて掲載できる場所があれば、 それなりに人が集まってWin-Winになるのではないかと考え、 まずは、コンテンツページを載せようと考えています。

作ったら載せてもいいよという事業者(法人・フリーランス問わず)がおられたら、 問い合わせより連絡いただけると幸いです。

問い合わせフォーム

Hetemlのサーバー移設を行った所感

フリーで扱えるSSLがHetemlでも対応。しかし、それには既存のサーバーではなく、昨年から稼働しているSSDのサーバーへの移設が必須・・・

約7年の間に作って放置したままのものも複数あり、大掃除も兼ねて、移設+SSL対応をしました。

サーバー内のデータをダウンロードする方法に苦悩

単純に時間をかけてダウンロードすればいいかというとそうではなく、 管理者側がWordPressのinstall.phpのアクセス権限を000にしていたりするファイルが原因で、 ディレクトリをそのままダウンロードしようとするとフリーズしたりといったことがあり、 SSHでアクセスし、コマンドで圧縮して・・・となると忘れていたサイト丸ごとの納品データが原因で圧縮ができない・・・

と試行錯誤して、必要なデータを退避。データベース周りはサーバーが物理的に違うので特に触らず、必要なデータを新しいサーバーへ移動し、 新しいサーバー上のプログラム周りの疎通が確認できたタイミングで切り替え、順次SSLの対応を行い、 無事このサイトもhttpsでアクセスできるようになりました。

以前と比べるとものすごく表示が速い

仕事をしているとJSやCSSの圧縮やプログラムの構造を整理して高速化するといったところで10ms単位のスピード化は測れるものの、 サーバー移設に伴う速度の変化はそれをはるかに超える効果がありました。
体感では、WordPressがPHPではなく、HTMLなのではないかと思うぐらいの速さになりました。

更なる高速化を目指して試していること

ひとまずは、WordPressを取り外し、すべて静的のHTML化、タスクランナーでテンプレートと各ページをベースにHTMLをビルドするような方法へ変更、 ビルドの際はソースコードの圧縮を行い、軽量化を図っています。

案件でMVCライクなフロントエンド開発をしている制作会社でもコーポレートサイトではMVCライクなフレームワイクなどは一切使っていないところがほとんどで、 タスクランナーも使わないケースが多い中、コーポレートサイトで世代が古いとはいえ、Marionette/Backboneとはいえ、 ポートフォリオのモーダルや問い合わせフォームで実装できたのは、少し面白いかなと考えています。

もっと動的に魅せる部分が増えれば、いろいろなスクリプトを使って実装していけると思うので、 出来次第、またどこかに載せていきます。

ちなみに、Marionette/Backboneを使った理由は、ビルドなしで実装でき、 jQueryベースなのでいざという時に作法を逸脱してかけるところです。
jQueryでProtoTypeベースの記法などをしている場合は比較的コストをかけずにルーティングなどの機能を取り入れることが できるのでオススメです(しかし世代が古いです。)

iPad ProとLightroom CC

iPad ProとLightroom CC

今までiPhoneにカメラから写真を取り込んで、そのままLightroom CC → VSCO → SNSという流れでこの1年ぐらい投稿や保存をしていたが、 今まで使っていたiPad miniがもうOSアップデートもしない状態になったので思い切ってiPad Proに買い換え、そっちで写真を扱えるようにした。

iPhone、iPadともにiCloudで写真を保存するように設定して同じAdobeIDでログインすると同じ画像をシームレスに現像、投稿まですることができ、便利。
そして、iPhoneでは小さな画面で指で範囲指定して加工するしかながったが、iPad ProはApple Pencilが使えるので、ペンタブレット以上の操作感で作業できるようになった。
しかも解像度が高くきれい。

ただ、MacBook 12インチよりサイズが大きく、重く、手で持ちながら作業するといったことはほぼ無理なのでそこは難ありですが、やっぱり大きなiPadはあると便利です。

ミラーレス一眼から一眼レフになり一年

ミラーレス一眼から一眼レフになり一年

昨年(2016年)の秋に小さなミラーレス一眼カメラから、一眼レフカメラにステップアップして1年、それまでなんとなくだった、 絞りやISO、シャッタースピードもようやく理解して使いこなせるようになってきた。

SNSに撮ったものを載せていくこと

単純に「いいね」が欲しいというだけでなく、後から見返すと、同じものを撮っていても構図が変わっていたり、捉え方が変わったりしていることがわかり、成長が実感できる。