2019年4月27日土曜日

メールがスパム判定されないよう設定

設定の前に、IPアドレスがクリーンかどうかはチェックするべきです。
ブラックリストはIPアドレス単位で行われます。 ドメイン単位ではありません。

AWSのEC2からメールを送信する場合、固定IPにしてドメインを割り当てる必要があります。

SPFを設定します。
広く使われており、送り先によっては必須です。

DKIMはあると良いですが。無くても今はまだ大丈夫だと思います。

heloネームにサーバードメインを指定する必要があります。
sendmailなどの設定にあります。
デフォルトはローカル名なので、ほぼスパム判定されます。

送信元や返信先につかうメアドのドメインは、DNSにmxレコードが無いと偽装なのでスパム判定されます。

あとは実運用で人間がスパムだと報告すればブラックリスト入りするので、スパムと思われない運用が必要です。


2019年4月20日土曜日

Amazon Pay実装の感想

他の国産決済と違って、仕様書が存在しないのが一番大きいです。海外ではこういうのが普通なのですかね。オープンソースと同じ感じなのかな。
リファレンスとか一部機能紹介みたいなガイドは存在しますけど、結構間違っているので、自分で調査が必要でした。

任意項目となってても、必須だったり。
デフォルト値が違っていたり。

ま、さわってればすぐわかりますけど。
あと最近追加されたFAQページはまともっぽいです。

SDKを使うには、SDKのソースを見る必要があります。
主な使い方はSDKのページに書かれていますけど、書かれていない事もあります。

実装時に注意が必要だと思ったのは、

・ログインウィジェット。
ログインしたら次のページに進みたい~って処理をするとき。
onSignInを使います。これはログインが完了した後に実行されます。
authorizationは、認証処理が終了したときに実行されます。すなわちキャンセルしてログインしなくても実行されます。

・定期購入で配送先が空?
InheritShippingAddressパラーメータを追加する必要があります。
デフォルトではtrueと書かれてますが嘘です、デフォルトはfalseになっています。
今はFAQにも書かれていますね。
任意項目ですが、実質必須項目です。

・住所ウィジェットを2つ同時に使いたい
オーダーリファレンスIDは特定条件下で同時に2つ扱えます。
リファレンスIDを新規作成可能なのは、ログインウィジェットと住所選択ウィジェットです。
これを利用して、住所ウィジェットを2つ同時に扱うことが可能です。
間違っても同じIDで住所ウィジェット2つという力業はしないことです。

・アメリカ版と日本版で住所ウィジェットの仕様が微妙に違う
管理画面からテストアカウントの住所を入れるときはアメリカ版仕様なので注意でした。
アメリカ仕様:市町村項目がある
日本仕様:会社名項目がある
両者は項目名が違うだけでなく、項目そのものが別物です。
違う仕様で保存すると、無い項目のデータは消滅し引き継がれません。

こんな感じでした。

2019年4月10日水曜日

愛用のphpstormにやっかいな不具合・・・クリーンアップはオフ必須

デフォルト設定だと、コミット前にソースをクリーンアップするようになっています。

クリーンアップとは、ソース上の問題点を見つけて、自動的に勝手にソースを修正する機能です。

かってに無通知でやっちゃいます。 修正に気が付くことはありません。
これ、自動修正が正しく働かないと、ソースが破壊されます。

はい、破壊されました。

無通知の自動修正なんて使うもんじゃありません。
通知されないので、すぐに原因がわからなくて困りました。

誤動作しやすいのは、テンプレート内のjavascriptですね。
phpの変数を織り交ぜてスクリプトを書くと、正しく認識してくれなくて、破壊されることがあるようです。

2018年9月6日木曜日

chromeに神アップデートが来ていた

今や誰もが使っている人気ブラウザ chrome。
私がはるか昔にchromeを選んだ理由は、唯一マルチモニターでまともに動作するラウザだったから。
そもそも何をするにも快適でストレスが無いのは、chromeだけだったから。
直前はfirefoxを使っていたが、firefoxの問題点が全てchromeで解決できたから乗り換えた。

そのchromeも、開発者にとっては非常にストレスとなる問題点が1つあった。

アドレスバーのドメインのみをコピペしたくても、かならず https:// がついてくる。

これは本当に毎回イライラする仕様であった。

しかし最近のアップデートでchromeのデザインが色々変更され、ドメインのみのコピーが可能になった!

神すぎるアップデートだ。 
よくドメイン部コピーを行う私にとっては、やっと解放されたのであった。

2018年7月24日火曜日

upstream sent too big header while reading response header from upstream

ある程度大きなアプリを動かしていると、nginxが502エラーを発生させることがあります。

upstream sent too big header while reading response header from upstream......と長い一行がログに記録されます。

upstreamが大きすぎるヘッダーを送信しているというエラーです。
バッファーの容量を超えているということです。

原因の大抵はクッキー多すぎだと思います。
設定は、どのアップストリームで上限に引っかかっているかで少しかわります。

エラーにupstreamがどれか書かれていなければ、nginxのリバースプロキシである可能性があります。
その場合、プロキシのバッファーを増やしてあげれば解決します。


proxy_buffer_size 128k;  
proxy_buffers 4 256k; 
proxy_busy_buffers_size 256k;
他にも、原因であるクッキーの量を減らすというのもあります。
たとえばRailsならば、セッションデータをクッキーではなくActiveRecordに変更することで解決します。

php-fpmを使っている場合は、エラーの中に
upstream: "fastcgi://unix:/var/run/php-fpm/php-fpm.sock:"
と書かれているかもしれません。
この場合は、fastcgiのバッファーを増やす必要があります。


fastcgi_buffers 8 16k; 
fastcgi_buffer_size 32k;


fastcgiのバッファーを増やしたら、リバースプロキシ―のバッファーが足りなくなるということもあるので
両方使っている場合は、両方あげないと動かないこともあります。
2つの設定を合わせると以下になります。

fastcgi_buffers 8 16k; 
fastcgi_buffer_size 32k; 
proxy_buffer_size   128k; 
proxy_buffers   4 256k;  
proxy_busy_buffers_size   256k;



2018年6月26日火曜日

正しく動作するプログラムには正しいデータが必須とは限らない

「正しいデータが必須条件」がプログラムの動作原理に基づく条件としている方がおりますが、それは間違っています。

仕様上あり得ない入力を受け入れる必要性があることもあります。
ソフトウェアは様々な物が存在し、そう単純ではないのです。
これが卓上の論争をしている人と、現場の人の意見の違いだと思います。

また別のある人は、「入力値検証では値の変更をすべきではありません。」とも書いています。
「全角数字が入っていたから半角にするなど、一見親切っぽい動作ですが、はっきりいって邪魔です。」と言っています。

まぁたしかに、プログラムを組むだけの人から見れば、余計な脆弱性を組み込む原因となるかもしれないから嫌だと思うかもしれません。
しかし実際は、業務上それが必要になることもあります。
全角入力でいちいちエラーになるより、自動半角で通した方がスムーズなのは明白ですからね。
特に一般ユーザーに入力させる場合、これをやるかどうかで売り上げに結構響きます。
そもそも全角半角って何?ですから。

またよくあるのは、1行のテキストボックス。
仕様上改行を入れることはできない、と普通は思います。
しかしコピー&ペーストを使うことで改行を含ませることができます。
そして、エクセルからのコピーでは改行が含まれます。
業務内容によっては、不正な改行を取り除いて正常なデータとして扱うという処理が必要になります。

こういった例は他にも色々あります。
いくらセキュリティーが高くても、目的を達成できなければ本末転倒なのです。
よって、入力の種類は4種類になります。

・正しい入力
・入力ミス
・不正な入力だが、ホワイトリストにより変換して正常に扱える入力
・完全に不正な入力


何を目的とするプログラムか。 それが一番大切です。
何事も、手段が目的にならないようにする必要があります。

2018年6月23日土曜日

Coinhiveは 仮想通貨発掘マルウェアだよ

近年登場して問題となっているマルウェアに、仮想通貨発掘マルウェアがあります。
感染したパソコン上で発掘するという悪質なソフトウェアです。

そしてさらに発展させて素人でも手軽に行えるマルウェアが登場しました。
それが coinhive です。

次々と逮捕されてますので、絶対に使わないようにしましょう。
少し考えれば、悪い事だってぐらいわかるはずです。たとえ違法じゃなかったとしてもやりすぎだ。
おそらく、バレないだろうと思って使うのでしょうけど、バレますんで使っちゃダメです。

あと、ある有名なセキュリティ専門家が反社会的なとんでも理論で正当化しようとしていたのは、とても残念に感じた。テロリストと同じ思考だということに気づいていないのだろうか。

coinhiveは簡単にブロックできますので、各ブラウザの拡張機能/プラグインを使ってブロックしておきましょう。no coinとか。
ウイルススキャナーを入れていれば、大抵はブロックしてくれると思います。
今時のブラウザの仕組み上、ブラウザを閉じても裏で発掘させることができますので、ブロックは必須に近い状態です。

合法的にcoinhiveを使いたければ、サイトのプッシュ通知の許可と同じことをすればいいんじゃないだろうか。
そうすれば、利用者の意思で動かしているので問題ない。いちいちポップアップするのでうっざいですけど。


coinhiveがどう悪いか、適当に書いてみると、

・サイトの片隅に表示される広告とはまったく別です。
広告は訪問者側にも利益がある場合があります。無ければ広告を表示する意味が無いわけですし。広告をクリックして商品購入をするってことは、その広告が訪問者の役に立ったということです。需要と供給なのです。ただリンクを置いているだけですし。
coinhiveはどうですが?訪問者に無断で敷地内で商売(採掘)をはじめるんですよ。
もはや泥棒と同じですよね。※リソースを泥棒して売り払う犯罪行為

・今やどのサイトもjavascriptが走っていてCPUに負荷がかかっていて、coinhiveもその中の一つですって?
おいおい、目的がまったく違うでしょう。すなわち許容を超えてるってこと。
coinhiveはサイトとは関係ないでしょ。 利益でサイト運営だから広告と同じだって? それじゃ上の説明に戻ってね。

・ブラウザのタブを10個20個開く人は結構多い。勝手に踏み台にされちゃたまったもんじゃない。


ようは、訪問者が認識することなく訪問者の財産を一方的に利用(踏み台に)して金儲けしているということが一番の問題なのです。
こんなの禁止の方向へ進むのが当然でしょう。