WPに投稿した記事を自動でFBに投げてくれるPluginとして、Facebook Auto Publishがあるが、どハマったのでメモ

なお、無料で（Donateは可能）利用できるこの手のPluginで、2018/01時点のFB APIにOAuthレベルで完全に対応しているのはこれだけだった。 とてもありがたい。

ただし、もし、SettingのAuthorizeがうまくいかなくて、NGINXのlogに

NGINX Error log (URL is changed to example.jp)
2018/01/11 18:30:20 [error] 27732#100162: *40 FastCGI sent in stderr: "PHP message: PHP Warning: session_start(): Cannot start session when headers already sent in /usr/home/www/wordpress/wp-content/plugins/facebook-auto-publish/admin/authorization.php on line 9
PHP message: PHP Warning: Cannot modify header information - headers already sent by (output started at /usr/home/www/wordpress/wp-includes/formatting.php:5100) in /usr/home/www/wordpress/wp-content/plugins/facebook-auto-publish/admin/authorization.php on line 28
PHP message: PHP Warning: Cannot modify header information - headers already sent by (output started at /usr/home/www/wordpress/wp-includes/formatting.php:5100) in /usr/home/www/wordpress/wp-content/plugins/facebook-auto-publish/admin/authorization.php on line 34" while reading upstream, client: 10.2.101.41, server: example.jp, request: "POST /wp-admin/admin.php?page=facebook-auto-publish-settings HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-fpm.sock:", host: "example.jp", referrer: "https://example.jp/wp-admin/admin.php?page=facebook-auto-publish-settings"

みたいなエラーが出ていたならば、以下のどちらかを行うこと

1. enable the output buffering in the server
2. uncomment the code ob_start(); in the file facebook-auto-publish.php (line no. 32)

但し、自分のところでは、1ではだめだったので、2を行なった。 おそらく、一番最初の時だけ問題になると思われるので、PluginのUpdateには影響がないと信じて…

そのうち、詳細を書かないといかんなぁ。

最近まで自宅の対外接続Router兼FirewallとしてpfSenseを利用していた。 しかし、pfSenseの来船に関する変更を見て、ちょっと調べ直したら、OPNSense がかなりよくなっていることに気がついたので、OPNSenseに切り替えてみる気になった。

1. OPNSenseのIPSがsuricataになってた (いつからかわかってない)
2. OpenVPN を利用するためのClient ConfigurationがExportできるようになってた
3. Commandlineからの制御とは言え、pkgが利用できる
   1. すなわち、CEoRで多少の面倒はみられると言うこと
4. pfSenseで自分が利用していた機能は全てOPNSenseで動作する
5. 実質の影響はないとは言え、pfSenseのライセンス変更は正直気に入らなかった
   1. もちろん、彼らはOpenであんなに素晴らしいシステムを公開しているのだから、彼らに文句を言う気はない。むしろ当然とも思う
   2. 気に入らなかったら意見は述べて良い。それでも気に入らなければ別実装を使え！は鉄則。彼らだって完全なVoluntierではないのだから

というわけで、Installしたのでそのメモを。

（最終的なやつは別記事にしてあげるので、ここではメモのみ記述する）

→ 続き...

NGINXやApache(おそらくSQUIDでも)あたりでReverse Proxy(まぁ、Load Balancer的に使う設定)をしようとした場合に、中継段となるhttpdでHeaderを追加したいことはしばしばある。 こういう場合に、X-xxx-xxxのようなHeaderを追加することがしばしばある。

しかし、この手法は、一般的によく利用されている慣習であって、HTTP Protocol的に規定されているものではなかった。そして、この慣習は2012年6月に非推奨となった。

なぜそうなったかに関してはRFC6648を参照のこと。まぁ、要するに「非標準のフィールドが標準になったときに発生した不便さのため」ということになると思う。

んで、どうすりゃいいかということなのだが、要するに「使われていない」かつ意味がわかりやすいものを使えということらしい。

でも、それはそれで困るよなぁ…….

仕方がないから、被りそうもない文字列を入れるしかないか。

非常に個人的な意見なので、気に入らない人は華麗にスルーしてください。

http://itpro.nikkeibp.co.jp/atcl/column/14/549762/062900154/?n_cid=nbpitp_fbed&rt=nocnt&ST=spleafの記事についておもうことを少し。

• googleが検索市場で独占的な地位にいる
  • 代替が事実上存在しない(百度？bing? yahoo?)以上、独占状態になるのは当然。
  • これだけの長きにわたって、「無料で高精度」の検索エンジンを提供しているのだから、googleがすごいのだとしか言いようもない。
  • 対抗が現れるまではどうしようもないというのが実情だろう

• スポンサー広告を優先して、公平な市場競争を阻害した
  • タダで受け取っている情報にある種のバイアスがかかるのは当然。
  • バイアスは小さい方が望ましいが、googleはボランティアではない。
  • バイアスがかかることが嫌なら検索エンジンを変えればいい。ないなら作るしかない。(死屍累々の道だけど)

個人的には、googleが正しいとは思わない(むしろできるなら使いたくない)。しかし、この件に関して言えば、「ヨーロッパすらこの程度か。日本の民間人と変わらないレベルだ」と思ってしまう。世界的に「情報と安全はタダ」の方向に思考が向かっているとしか思えない。本当なら、利用する側がすべき選択や判断を提供者側に押し付けて、自らは被害を受けた、的なワガママに見えてしまう。

いっそ、googleは、「バイアスをかけない検索結果の提供」を始めればいいんじゃないかと。「有料」で。そうすれば、情報の対価と、企業広告・スポンサードの意味がわかるんじゃないか？とおもうのです。

わかるかなぁ(松鶴家千とせ風)

山賀さんの記事より。

要するに、

• 多くのユーザーが、脆弱性を抱えているadobe flashを利用している
• 調査範囲内では、古いプレーヤーの利用率が、前年の調査より上がっている
• flash playerの利用率自体は減少傾向にある
• duo securityは、chromeの利用を推奨している。セキュリティ系の企業が名指しで実装を推奨するのは珍しい

といった内容です。

記事中に記載されていませんでしたが、Duo security (最初avastと書きましたが、思い込みでの勘違いでした。訂正します) がchromeを推すのは、恐らく、

1. chrome自身にflash playerが内蔵されている
2. chromeは更新が早く、常に最新のflash playerに対応している
3. 調査結果から、割合chromeユーザーは更新頻度が高いと見られる

からでしょう。推すことに対する是非は人によるでしょうが、例えばavastは昔からchrome推しなので、まぁそんなものかと。 まだ、著者の山賀さん曰く

「あまりの調査結果に「やむにやまれず」という思いはちょっと感じられます^^」

とありましたが、僕もそう思います。

個人的にはflashはもう滅びて欲しいけど、使うなら常に最新の物を使いたいものですね。

困るのは、子供付けのページの動画がflashが多いことだな。これは、なんとかならないものかと思います。