Scrapdiary

DesigningとEngineeringの架け橋

「SocialConnect/Auth」においてTwitter API利用時にcURLを用いた通信時に「Bad Request」

SNSでのログイン実装時に有益と思われる「SocialConnect/Auth」です。

socialconnect.lowl.io

github.com

問題

Twitterでの認証を行おうとするとAPIから「Bad Request」と返却されてしまいました。他のSNSプロバイダ(Twitterの他に今回実装したのはFacebookGoogle)は問題がなく成功する。

環境: CentOS Linux release 7.9.2009 (Core)

検証

SocialConnectの挙動を追っているとどうやらcURLを用いた通信時に問題が発生している模様でした。

開発環境のcRULが古かったのか発生しませんでしたが他のCentOS 7のサーバ検証したところ

  • 開発環境: ver.7.19.7 → OK
  • 稼働環境: ver.7.29.0 → NG
  • 手持ちのMac: ver.7.64.1 → OK

という状況だっため7.29.0を最新版にアップデートすることにしました。

対策

yumでパッケージ管理しているためupdatesからは最新にできないため、別途リポジトリを追加してアップデートしました。

qiita.com

実行コマンド
rpm -Uvh http://www.city-fan.org/ftp/contrib/yum-repo/rhel7/x86_64/city-fan.org-release-2-1.rhel7.noarch.rpm
yum install libcurl libcurl-devel --enablerepo=city-fan.org

 

「libcurl」がアップデートされることで依存関係があるパッケージもアップデートされます。アップデート後にhttpdをrestartしてもPHP側でcURLのバージョンが最新に反映されなかったので致し方なくサーバ自体を再起動しましたが、このあたりは再起動を要さなくてもいいのかもしれません。(未検証)

 

Gitの方でもissueが上がっていたりしていないのでworkaroundなのかもしれませんが、以上の対応でSocialConnectを用いてTwitterログインが正常に行えるようになりました。

 

mailgunで"Your account is temporarily disabled. ( Business Verification ) Please contact support to resolve."と表示された時

GCPではメール関連のポートが全て閉じており、直接サーバからのメール配信が出来ないという罠があります。そのためAPIベースのメール配信システムであるmailgunを使ってGCEからメール配信をテスト運用していました。  

 

いつのタイミングかがわかりませんが

Your account is temporarily disabled. ( Business Verification ) Please contact support to resolve.

と画面上部に表示されるようになっていました。Concept(無料)枠でしたがメールの配信数もリミットに届くような使い方をしていたわけではなく、正直「なぜ」という印象でした。

 

「サポートに連絡して解決して」ということだったので supportメニューからticketを「Please enable my account」にて発行します。

以下の項目について(可能なかぎり詳細に)情報提供するように、と言われます。

**In order to complete this process please answer the questions below (in as much detail as possible):**


1. What types of emails will you be sending - transactional or marketing? Please tell us briefly about how your business uses email.

2. How do you obtain the email addresses for your recipients? Please provide any available links to your signup page(s).

3. Are all of your email addresses double-opt in? (This means that the user has requested your emails through sign-up and then confirmed via email that they want to receive your communication).

4. What is your expected monthly volume of messages?

5. Have you read our Email Best Practices document?

6. Please provide a link to your Privacy Policy, Terms of Service, and Sign-up link (if applicable).

7. Please provide a sample email you would typically send to your users. 

 一つでも抜けがあるとサポートから不足を指摘されるので全て答えます。

 

1. What types of emails will you be sending - transactional or marketing? Please tell us briefly about how your business uses email.

どのタイプのメールを送信しますか? -「取引」または「広告」ですか?あなたのビジネスがメールをどのように使用しているかについて簡単に教えてください。

 

2. How do you obtain the email addresses for your recipients? Please provide any available links to your signup page(s).

受信者の電子メールアドレスはどのように収集していますか?サインアップページへの利用可能なリンクを提供してください。

 

3. Are all of your email addresses double-opt in? (This means that the user has requested your emails through sign-up and then confirmed via email that they want to receive your communication).

全てのメールアドレスが、ユーザからの二重許可(これはユーザーがサインアップの際にメールを送信し、その後、あなたからのコミュニケーションを受け取りたいことをメールで確認したことを意味します)を取得されていますか?

 

4. What is your expected monthly volume of messages?

予想される毎月のメッセージ(メール数)量はどのくらいですか?

 

5. Have you read our Email Best Practices document?

”メールの最善の慣行”に関するドキュメントを読みましたか?

 

6. Please provide a link to your Privacy Policy, Terms of Service, and Sign-up link (if applicable).

プライバシーポリシー、利用規約、およびサインアップ(該当する場合)へのリンクを提供してください。

 

7. Please provide a sample email you would typically send to your users. 

典型的なユーザーに送信するサンプルメールを提供してください。

 

上記に適切に回答し審査が終わるとアカウントを有効にしてもらえます。結果はメールとsupportメニューに表示(ticketがclosedになる)があります。

 

今回はテスト運用のタイミングでしたが、突然サービスがdisabledになると焦ります。

 「Business Verification」(事業の検証)とのことで、mailgunでは通常の対応なのかもしれませんけど。

 

 

セーラー服と機関銃?卒業?

セーラー服と機関銃?卒業?

 

 

さくらのレンタルサーバーでマルチドメイン利用時のDOCUMENT_ROOT

連日さくらネタ。

www.sakura.ne.jp

さくらのレンタルサーバでは「マルチドメイン」といういわゆるバーチャルホスト機能が手軽に使えます。ただコントロールパネルでの設定と実際の稼働環境での認識に差異がありハマったので備忘録です。

コントロールパネルでの設定値

その際コントロールパネルの設定にて当該ドメインに対応するディレクトリを指定します。指定したディレクトリ以下にファイルを配置すると、そこを起点に当該ドメインでアクセスした場合にコンテンツとして展開されます。

 

  • ドメイン設定: site1.hostname.tld
  • パス設定:   /home/user_name/www/site1

 

上記の場合、DNSを設定した後にsite1.hostname.tldへアクセスすると、/home/user_name/www/site1 以下に設置したファイルがドキュメントルートとみなされて表示されます。

 

  • サーバ上パス: /home/user_name/www/site1/index.html
  • アクセスURI: site1.hostname.tld/index.html

 

サーバ上のファイル、この場合マルチドメインで設定したディレクトリの直下に配置したファイルは、マルチドメインで設定したドメインのホスト直下にマッピングされます。

つまり、コントロールパネル上パス設定したディレクトリはそのドメインで稼働させているホストのドキュメントルートとして機能していると理解できます。

環境変数での参照値

しかし、このドメインのホストでApacheから渡される環境変数(例はPHP)を確認すると

 

  • $_SERVER['DOCUMENT_ROOT']:/home/user_name/www

 

という値が返されます。

DOCUMENT_ROOTという環境変数は比較的よく参照される値かと思われますが、これがマルチドメインで設定したディレクトリの指定と異なる仕様というのは少々ツライところです。

詳細は不明ですが、恐らくApache側でのバーチャルホスト設定は初期ドメイン1つであって、マルチドメインについては別の方法でマッピングしているということなのでしょうか…。

 

ただホスト名に関する値はマルチドメインで設定した値になっていました。

 

  • $_SERVER['HTTP_HOST']:site1.hostname.tld

 

こちらはコントロールパネルで設定したものと合致しますので、なぜDOCUMENT_ROOTだけが合致しないのかは不可解です。

 

何が問題だと認識しているのか

この仕様ですと、マルチドメインにて展開したコンテンツ内にDOCUMENT_ROOTを参照する記述をした処理が含まれると、コンテンツ内で正しいパスが把握できなくなってしまいます。

WordPressを標準(クイックインストール)で提供しているのでWordPress本体は問題なさそうなのですが、例えばテーマやプラグインなどでDOCUMENT_ROOTを参照する処理が含まれていた場合には不都合が発生していまいます。

FAQ等事例に記述が見つけれれなかったので公式サポートにて技術の方に確認させていただきましたが、これは仕様(本投稿時点)とのことですのでマルチドメイン機能を使ってPHPCGIを利用する場合には注意が必要です。

 

この環境変数「DOCUMENT_ROOT」はバーチャルホストで稼働させる際には難いものと理解していましたが、そもそもDOCUMENT_ROOTを安易に参照する処理は推奨されないものなんでしょうか。

 

ま、その名の通り環境に左右されるからあまりよくないのでしょうね。

 

 

<追記>

お名前.comのレンサバでもユーザのホームディレクトリよりかなり上位のディレクトリがセットされていたので、レンタルサーバ系では比較的よくある仕様なのかも。

さくらのレンタルサーバーで「SNI SSL」が設定できない時の対処法

さくらのレンタルサーバにてSNI SSLの設定を行おうとして軽くハマったので備忘録です。

www.sakura.ne.jp

状況

コントロールパネルにて「ドメインSSL設定」から該当するドメインに対しSSL証明書をインストール後に「ドメイン設定」>「ドメイン詳細設定」でSNIを有効にしようとするも

 

このドメインでは利用できません

 

という原因を説明する気が一切感じられないエラーメッセージが出るのみ。エラーメッセージは簡潔にしたい気持ちはわかるのですが、これでは何をどうしたらいいのかわからず、さくらのFAQやネットで事例を探すも特に有益な情報が得られず。

 

chunkynews.com

 

上記を参考に「時間」を待ってみたのですが解決せず、仕方なく最終手段でサポートにお伺いを立てました。

解決方法

サポートの方の回答は「このドメインDNSがさくらのサーバを向いていないため」ということでした。

今回、サーバ移行のために事前準備として利用していたので、SSLで利用するドメインは現在稼働している状態でした。そのためコントロールパネル上の設定を有効にできなかったようです。

SNI SSLの設定を有効にするには、DNSのレコードをさくら側に向けた後であれば可能になるそうです。

 

しかしさくらのレンタルサーバのコンパネはなぜ90年代ネット黎明期のデザインなんだろうか。強いこだわり感じる。

 

 

 

ところで今日は「猫の日」らしいですね。 

アンダー・プロトコル: 政財暴一体で600億円稼いだ男の錬金哲学

アンダー・プロトコル: 政財暴一体で600億円稼いだ男の錬金哲学

 

Wordpressの更新で「ダウンロードに失敗しました。:ファイルのチェックサムが期待値と一致しません。」のエラー

Wordpressを4.8にアップグレードを行おうとGUIから実行するも

https://downloads.wordpress.org/release/ja/wordpress-4.8.zip から更新をダウンロードしています…

ダウンロードに失敗しました。: ファイルのチェックサム (6c0797eea5561cdaa9b4edc75ba296dd) が期待値 (d95fd389479bf85939e0b36d9ae1d1a4) と一致しません。

インストール失敗

と表示されてしまい、何度実行しても更新がインストールされません。

Permissionかと考えwp-contents以下のディレクトリを調整しましたが、いっこうに改善されませんでした。

仕方ないので、coreのソースファイルを読んでみると以下の箇所で発生していました。 

github.com

チェックサムのエラーはこの「verify_file_md5()」という関数で出力されています。
それを呼び出している「download_url()」の$responseにて、実際にダウンロードしたファイルのチェックサムと比較するための「期待値」を受け取っています。

検証してみると、Wordpressダウンロードサイトhttps://downloads.wordpress.org)にて該当するZIPファイルをGETで取得する際のheader情報に「Content-MD5」というプロパティがあり、それを「期待値」とする仕様のようです。

wgetコマンドでheader情報を取得してると

$ wget -S --spider https://downloads.wordpress.org/release/ja/wordpress-4.8.zip
Spider mode enabled. Check if remote file exists.
--2017-07-26 11:00:39-- https://downloads.wordpress.org/release/ja/wordpress-4.8.zip
Resolving downloads.wordpress.org... 66.155.40.186, 66.155.40.187, 66.155.40.188, ...
Connecting to downloads.wordpress.org|66.155.40.186|:443... connected.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 26 Jul 2017 02:00:40 GMT
Content-Type: application/zip
Content-Length: 9436096
Connection: keep-alive
Cache-control: private
Content-Disposition: attachment; filename=wordpress-4.8-ja.zip
Last-Modified: Fri, 23 Jun 2017 02:03:03 GMT
X-Frame-Options: SAMEORIGIN
Content-MD5: d95fd389479bf85939e0b36d9ae1d1a4
X-nc: EXPIRED lax 186
Accept-Ranges: bytes
Length: 9436096 (9.0M) [application/zip]
Remote file exists.

「Content-MD5: d95fd389479bf85939e0b36d9ae1d1a4」が渡ってきます。
ですが、この値がWordpressが稼働するサーバ上で実際にダウンロードしたファイルに対してmd5_file()を実行して生成したチェックサム値と一致しません。

「Content-Length: 9436096」と「Length: 9436096 (9.0M) [application/zip]」とheaderは伝えているのだけど、実際にダウンロードされたファイルのサイズをfilesize()でチェックすると「2060288」(1.9M)なので、GETリクエストしているファイルと実際にダウするファイルが違っているように見受けられる。

これってWordpress側のheader情報が間違っているように感じるのだけれど、特に「4.8にアップロードできない」という声を聞かないので自分の環境特有の問題なんだろうか…。

 

調べてみたけど解決策がなくて困ったというお話でした。

 

パーフェクトPHP (PERFECT SERIES 3)

パーフェクトPHP (PERFECT SERIES 3)

 

CKEditorをCDNから利用する時のカスタマイズ方法

WebでWYSIWYGなエディタで使いやすいいCKEdiotorですが、サクッと導入したい時にファイル一式をホストするよりCDN経由で読み込む方が圧倒的に楽です。

CKEditorの特長の一つにカスタマイズのしやすさがあります。公式サイトでもツールを公開していますので、取捨選択・レイアウトも楽です。

Toolbar Configurator

利用サイトに自前でホストする場合はckeditor/config.jsを編集してカスタマイズするのですが、CDN経由の場合のエディタカスタマイズ方法が分からず、いろいろ解説サイトやドキュメントを(さっと)見たのですがすぐにわかりませんでした。

結果としてはCDN経由ではconfig.jsをCKEditorに明示的に指定してあげる必要があるようです。以下のサイトでCDN経由で利用する場合の注意点が書いてありました。

CKEditor CDN

CKEditor本体の読込み

CKEditor CDN setup

上記をhead内に記載し、エディタを適用したい要素にclass名で「ckeditor」と指定するか、別途scriptタグで置換します。注意点としては、このCKEditor.replace();はエディタを指定した要素より後に書く必要があります。

config.jsの指定

CKEditor customConfig setting

config.jsを指定するためのcustomConfigパラメータにファイルのパスを設定します。これもエディタを指定した要素より後に書かないと機能しません。

後は指定したconfig.jsを作成しカスタマイズを行うことでお好みのエディタの利用が可能になります。

カスタマイズ例

CKEditor customized example : 'config.js'

編集用の要素を絞ったのと、エディタ内でCSSやstyleを使えるようにする「config.allowedContent = true;」を追記しました。外部や不特定多数の利用が想定される場合にはこの設定をするとXSSなどのセキュリティリスクが高めてしまうので、利用には注意が必要です。タグの利用には個別の設定も可能なようなので、上記のようなケースでは「config.extraAllowedContent」で制御するべきとのことでした。

blog2.gods.holy.jp

Adobe Creative Cloudが正常に稼働しなくなった場合の対処方法

今まで5年ほどCreative Cloudを使っていますが、ログアウト出来なかったり、「App」の項目が表示されず各アプリのアップグレードができなかったりすることが多々ありました。どうやらアプリをアップグレード中に通信の切断が発生するとレジュームが出来ずに操作不能に陥るようです。

その際Creative Cloudを何度再起動してもダメだったので、Adobeのサポートの方に相談して解決方法を教示いただきましたので、再発の際の備忘録としてまとめます。

1. Creative Cloudアプリケーションの終了

Creative Cloudアプリケーションを開いて画面右上の歯車のマークをクリックし、環境設定>ログアウトのち再度歯車マークをクリックして「終了」を選択します。
終了がクリックできない場合は、アクティビティモニタを起動して「Creative Cloud」と「CoreSync」を選択し終了させます。

2. アンインストールの実行

以下ページのツールをダウンロードし、実行してCreative Cloudをアンインストールします。

helpx.adobe.com

3. 設定ファイル・キャッシュファイルの削除

3-1. ~/Library/の中

デスクトップのなにもないところをクリックし画面上部メニューバー、アップルマークの右側が「Finder」となっていることを確認してメニューバー中央あたりにある「移動」をクリックしOptionキーを押しっぱなしにすると「ライブラリ」という項目が出て来ますのでそちらをクリックします。

  • ~/Library/Application Support/Adobe/OOBE/opm.db ファイルを削除します。
  • ~/Library/Application Support/Adobe/AAMUpdater/1.0 フォルダを削除します。

3-2. /Library/の中

再度デスクトップのなにもないところをクリックし、「移動」をクリックして「コンピューター」を開きます。

  • /Library/Application Support/Adobe/OOBE というフォルダを OOBE.old と名前の変更をします。
  • /Library/Application Support/Adobe/SLCache フォルダを開き中にあるファイルを削除します。

4. Adobe Application Manager設定ファイルの削除

アプリケーションフォルダを開いて、ユーティリティも開き「Adobe Application Manager」というフォルダを削除します。

5. Adobe Application Managerの再インストール

以下ページのアプリケーションをダウンロードして実行し、インストールします。

Adobe - Adobe Application Manager:For Mac:Adobe Application Manager

6. Creative Cloudの再インストール

以下ページのアプリケーションをダウンロードして実行し、インストールします。

creative.adobe.com

一旦上記を実行しCreative Cloudが正常に機能するか確認します。

 

このような回答テンプレートを用意しているということは、サポートの方も問題を認識しているのかと思われます。高額なsubscriptionを組んでいますので、このようなことをせずに普通にアプリが使えて、最新版にアップグレードできるようAdobeさんには品質改善していただきいたいです。

Adobe製品はアップグレードするごとに「重く」なりクラッシュなどの「不具合」が多くなってくる印象があります。新機能やCloud連携など素晴らしい部分も多々あるのですが、バージョンすることで「基本的なところがしっかり動く(It just work.)」ことを大切にして欲しいです。