まだ重たいCMSをお使いですか?
毎秒 723リクエスト を捌く超高速CMS「adiary

2013/06/12(水)twitter新ウイジェット(埋め込みタイムライン)のデザイン変更方法

API1.0の廃止と共にTwitterウイジェットが使えなくなってしまいました。新しい埋め込みタイムラインは通常の方法では細かいデザイン(配色)を変更することができないので、小細工してデザイン変更したまとめ。

続きを読む

2012/08/30(木)Twitter Cardsの仕様メモ(ドキュメントの適当日本語訳)

Twitter公式webタイムライン中にコンテンツを埋め込めるTwitter Cardsについての自分用メモ。あとで実装する用。

Twitter Cardsとは?

twitter_cards.png

TwitterをWebサイトから見ているときに、クリックするとTwitpicの画像やYoutubeの動画がそのままタイムライン上で表示されたりするあの機能のことです。

このTwitter Cardsは誰でも対応サービスを作ることができます。

大まかな流れ

  1. 公式のドキュメントをよく読んで
  2. 3種類のTwitter Cardsのどれを実装するか決めて
    • summary: デフォルト。タイトルと説明とサムネイルを表示。
    • photo: 写真を表示。
    • player: 動画や音のメディアを表示
  3. サイトに必要なmetaタグを実装して
  4. apply to participateからTwitterにCardsを申請。
  5. Twitterに認可されればカードが表示されるようになる。

申請結果は申請フォームに入力したメールアドレスに送られてきますので、忘れず確認してください。

メタタグ要素

<meta name="twitter:card" content="summary">

以上のようなデータを、そのページの<HEAD>内に出力する。

プロパティ必須要素か説明
su-ph-pl-
twitter:cardYesYesカードのタイプ。「summary」か「photo」か「player」*1
twitter:urlYesYesYesコンテンツのCanonical URL
twitter:titleYesコンテンツのタイトル。最大70文字(70 characters)
twitter:descriptionYesコンテンツの説明。最大200文字(200 characters)
twitter:image:srcYesYesコンテンツを象徴する画像のURL。*2
twitter:image:width画像の横px(アスペクト比を保持してリサイズするために必要)
twitter:image:height画像の縦px(アスペクト比を保持してリサイズするために必要)
twitter:player--YesiframeプレイヤーのURL。コンテンツが混ざってないこと。
twitter:player:width--Yesiframeの横px
twitter:player:height--Yesiframeの縦px
twitter:player:stream--生ストリームのURL。Twitterのモバイル・アプリケーション等でダイレクト再生時に使用する。「MPEG-4 コンテナ format (拡張子.mp4)」でなければならない。
twitter:player
:stream:content_type
--*3生ストリームの「MIME type/subtype」を指定(RFC 6381)。現在サポートしているのはRFC4337(MP4のMIME type)のみ。
twitter:site「@username」形式。WebサイトオーナーのTwiter ID
twitter:site:id上と一緒だが、Twitter user IDの代わりに記述する文字列。
twitter:creator「@username」形式。コンテンツ製作者のTwiter ID
twitter:creator:id上と一緒だが、Twitter user IDの代わりに記述する文字列。

補足

  • twitter:siteやtwitter:creatorはCardコンテンツのフッタに表示される。ここにTwitter IDを指定することで、そのIDのツイートに直接アクセスしたりフォローすることができる。

*1 : 省略時は「summary」を指定したとみなされる

*2 : player指定時はプラットフォームがiframesやインラインプレイヤーをサポートしてない時に表示する画像。画像はプレイヤーと同じサイズであり、縦px×横pxの値が68,600pxを超えないこと。

*3 : twitter:player:stream指定時は必須

Summary Card

  • 画像のサイズが120px×120pxを超える場合はリサイズないしはクロッピングされます。

カードのサンプル。

<meta name="twitter:card" content="summary">
<meta name="twitter:site" content="@nytimes">
<meta name="twitter:creator" content="@SarahMaslinNir">
<meta name="twitter:url" content="http://www.nytimes.com/2012/02/19/arts/music/amid-police-presence-fans-congregate-for-whitney-houstons-funeral-in-newark.html">
<meta name="twitter:title" content="Parade of Fans for Houston’s Funeral">
<meta name="twitter:description" content="NEWARK - The guest list and parade of limousines with celebrities emerging from them seemed more suited to a red carpet event in Hollywood or New York than than a gritty stretch of Sussex Avenue near the former site of the James M. Baxter Terrace public housing project here.">
<meta name="twitter:image:src" content="http://graphics8.nytimes.com/images/2012/02/19/us/19whitney-span/19whitney-span-articleLarge.jpg">

Photo Card

Twitterで表示される際、画像は次のようにリサイズされます。

媒体最大サイズ
Web横435px×縦375px
モバイル横280px×縦375px
モバイル(retina displays)横560px×縦750px

カードのサンプル。

<meta name="twitter:card" content="photo">
<meta name="twitter:site" content="@examplephotosite">
<meta name="twitter:creator" content="@sippey">
<meta name="twitter:url" content="http://example.com/photo/a/">
<meta name="twitter:title" content="Good Morning, San Francisco">
<meta name="twitter:description" content="Great view this morning">
<meta name="twitter:image:src" content="http://example.com/photo/a/image.jpg">
<meta name="twitter:image:width" content="610">
<meta name="twitter:image:height" content="610">

Player Card

生ストリーム再生時のMPEG-4でサポートするコーデックは以下のとおり。

  • Video: H.264, Baseline Profile (BP), Level 3.0。最大640x480ピクセルの30fpsまで。
  • Audio: AAC, Low Complexity Profile (LC)

カードのサンプル。

<meta name="twitter:card" content="player">
<meta name="twitter:site" content="@foobar">
<meta name="twitter:url" content="http://example.com/watch/a">
<meta name="twitter:title" content="Example Video">
<meta name="twitter:description" content="This is a sample video from example.com">
<meta name="twitter:image:src" content="http://example.com/keyframe/a.jpg">
<meta name="twitter:player" content="https://example.com/embed/a">
<meta name="twitter:player:width" content="435">
<meta name="twitter:player:height" content="251">
<meta name="twitter:player:stream" content="https://example.com/raw-stream/a.mp4">
<meta name="twitter:player:stream:content_type" content="video/mp4; codecs=&quot;avc1.42E01E1, mpa.40.2&quot;">

Twitterクローラー

Twitterはカードの情報を拾いに行く際、robots.txt を参照します。適切に許可がされていないと、Cardsは表示されません。TwitterクローラーのUser-Agentは「Twitterbot/1.0」です。

Twitterにのみ許可を出す場合の robots.txtの記述例。

User-agent: Twitterbot
Disallow:

User-agent: *
Disallow: /

正しく設定できているか確認する 2013/04/11

正しく設置できているか、実際どのように表示されるかは、以下のURLから確認することができます。申請する前に一度表示確認をしておくほうが問題が少ないでしょう。*4

*4 : これを知らず、申請したけどタグが間違ってて登録されなかったことがありました(汗)

画像が表示されない 2014/02/24

"twitter:image" が "twitter:image:src" に仕様変更されたらしい。上のvalidatorでは昔の仕様でも正しく表示するという(紛らわしい……)。

まとめ

ドキュメントをみながら適当にまとめたメモです。実装の際には、一次情報として必ず公式ドキュメントを参照してください。またOpen Graphに関する仕様は省略しました。

記述ミス(勘違い)など発見しましたら、コメントもしくはリプライください。

adiaryなら設定不要でTwitter Cards/Facebook OGPに対応しています。

メモ

TwitterがアクセスするときのUIとIP。

199.59.148.209 - "GET /robots.txt HTTP/1.1" 200 4000 "-" "Twitterbot/1.0"

$ whois 199.59.148.209
NetRange:       199.59.148.0 - 199.59.151.255
CIDR:           199.59.148.0/22
NetName:        TWITTER-NETWORK

2011/02/07(月)さくらのレンタルサーバでメールパスワードに記号が使えない件のまとめ

「さくらのレンタルサーバ」等で、1年~半年ぐらい前は使用できた「@,$,%,!」といった記号がメールパスワードとして使えなくなってました。セキュリティを低下させる仕様変更が信じられないので、それ関連の情報まとめ。

使用できる文字の制限

気づかなかったのですが「Q:パスワードとして設定できる文字は何ですか?」に詳細がありまして、半角英数を除くと

+ - * / = . , _

たったこれだけの記号しか使用できません。

第一、不便とかそういう問題じゃないし、サーバやネットで極めて重要なセキュリティ低下を招くことになるのですが……。

なぜ使えなくなったのか?

セキュリティを低下させて平気でいるさくらインターネットが技術者として信用ならないので問い合せてみました。

お客様にはご不便をおかけする事となり申し訳ございません。[@,$,%,!]等の特殊記号につきましては、サーバ上で誤動作を招く可能性がございます事から、パスワードには使用できない文字といたしておりました。

しかしながら、一部のプランのメールアドレス作成画面においては、これらの文字もパスワードとして設定可能であった事が判明し、現在は本来使用可能であるとご案内いたしておりました記号文字のみが利用可能となっております。

つまり、

  • 本来は使用できなはずだったのに、バグで使用可能になっていた。
  • そのバグを修正したので、今は使えなくなっている。

メールの文面からこの制限を解除する気はさらさらなさそうです

問題の本質

問い合わせ結果の文面をみるとさくらインターネットの本音が透けて見えます。

「@,$,%,!」というのは、UNIX*1のシェル上で特殊な意味をもつ記号になります。これらの文字に使用制限をかけるということは、パスワード変更プログラムはサーバ上でshellを呼び出し引数にパスワードを与えてますと宣言してるようなものです。

きちんとサニタイズされない文字列をシェルに与えることは大きな問題が起きますが、サニタイズ等のきちんとした処理を行なっていれば何も問題ありません。危険因子を排除するためにこれらの文字を使用できなくすることは分からないでもないですが、たかがメールのパスワードを保存するだけの比較的簡易な実装・検証のリスクを天秤にかけ、顧客メールアドレスのセキュリティ低下を差し出すというのはあまり理解したくはありません。

だって、どう考えたって「それらの文字列がキケン」なのではなくて「シェルを呼ぶことが危険」なだけでしょう。

*1 : さくらの場合FreeBSD

さくらレンタルサーバのメール仕様と考察

  • サーバOS FreeBSD
  • MTA courier
  • SMTP Auth(cram-md5) / APOP等使用可能

sshログイン可能なので見てみると /home 以下にユーザーアカウント(レンタルサーバアカウント)が羅列され、それぞれのアカウントの /home/account に MailBox/ が置かれています。ここに、作成したメールアカウント(@より左)がディレクトリごとに配置されています。

つまり account という契約のサーバの、useraというメールアドレス(usera@account.sakura.ne.jp)は、

$ cd /home/account/MailBox/usera/
$ ls -Al
-rw-r--r--  1 account  users   64 Feb  1 20:28 .mailpassword
drwx------  9 account  users  512 Feb  1 20:28 maildir

このような具合です。

APOPが利用可能なことからパスワードは平文で保存されているはずですが*2、.mailpassword ファイルはバイナリであり何かしら暗号化されて納められているようです。

このファイルを直接書き換えれば好きなパスワードを設定できると思ったのですが、暗号化方法が分からないので諦めました。

しかし、このファイルがユーザーレベルで書き換えられるということは「@,$,%,!」などの記号をWebアプリ上から制限してもあまり意味のないことではないかと思うのですが。


それにしても、国内サーバ業者の最大手がこれでいいんですかね……? 技術者の端くれとしては納得がいかない。

*2 : APOPの仕様

追記 2011/02/08

記号が使えないことによるセキュリティ低下についてどういう考えですかと問い合わせたら返事が来たのですが……

最長32文字なんだから十分だろボケ。もう問い合せてくんな。(超意訳)

その後 2014/12/02

知らぬ間に改善されてた。2011/11/17以前に改善されていた模様。

2009/11/30(月)CORESERVER、メールの凶悪仕様(Gmailとの不具合の理由)

訳あってレンタルサーバのCORESERVER.JP(Value Domain)の利用を検討していたのですが、メールがらみでひどい素敵仕様を発見したので記録しておきます。GmailとCORE SERVERの相性が悪いという話がネットであちこち書かれていますが、おそらくこれが原因ではないかと思います。

メールの仕組みについて

問題について述べる前にメールサーバについて簡単におさらいしておきます。そんなの分かってるという人は飛ばしてください。

いわゆるメールサーバというのは、SMTPというプロトコルによってメールをサーバからサーバへ転送するサービスをしています。このSMTPというのは元々サーバも受信者も送信者もなにも区別がないプロトコルで、「SMTPサーバからSMTPサーバへどんどんタライまわしをしているといずれ受信サーバにたどりつく」というSPAMなんて存在しない、インターネットが限られた利用者が使用する紳士的な世界だった頃に作られました。その名残から、今もって

  • メール送信時にメールクライアントソフト(メーラー)が自分のメール送信用サーバに対してメールのデータを送るSMTP
  • メールサーバ間でメールのデータをやりとりするときに使われるSMTP

2つには何の差も存在しません。こんな仕様だから、メール設定のいわゆるSMTPサーバ(送信サーバ)として使用するサーバには何かしら制限を加えておかないと、世界中からそのサーバを中継(経由)してSPAMを送り放題になってしまいます。このように「本来想定している人以外からのメールを送ること」を第三者中継といいます*1。第三者中継をしないために通常は次のような制限を加えておきます(いずれかもしくは複数)。

  • 特定のIPからしか送信できないようにする。プロバイダのSMTPサーバが、そのプロバイダの利用者IPのみに中継を許可する。
  • SMTP-AUTH等の認証をする。ID/パスワードを確認するので、正規のID/パスワードを持つ利用者のみに中継を許可できる。
  • POP before SMTPという特殊な方法を利用する。メール送信前に1度メールを受信させることで、そのIP利用者に短時間だけ(1~5分程度)中継を許可する。

最初の方法だけで済めばよいのですが、どうしてもホテルやモバイルパソコンからメールを送信したいとなったときに必ずしも同じプロバイダを利用できるとは限らないので他の方法が必要になります。SMTP-AUTHがまだそんなに普及していなかった頃*2、過渡的な措置としてPOP before SMTPというものが考えられました。

以上はあくまで送る側の話で、SMTPサーバは送るためのサーバであると同時に受信サーバでもあることが多くあります*3。このままだと何処から送られてくるかわからない自分宛のメールを受け取れなくなってしまうので、自分宛のメールは無条件で受け取るという設定をします。例えば、xxx@foo.com ならば foo.com は自分宛ですよと登録しておきます。

*1 : 199x年頃はこの第三者中継が標準でonになっていたのだから恐ろしいものです。

*2 : いくらその仕組みを用意してもクライアントソフトが対応するまで利用できる人が限られていた

*3 : この2つは分けることもできるが、小規模なケースでは一緒にしてしまうことが多い

CORESERVERのおさらい

  • CORESERVERは送信メールサーバ=受信メールサーバ
  • CORESERVERはPOP before SMTPのみ対応(SMTP-AUTH未対応

CORESERVERの血迷っ…素敵過ぎる仕様

CORESERVERで普通にメールサーバを設定して、設定したサーバ宛にメールを送ろうとしたらこんなエラーメールが帰ってきました。

<test@s1xx.coresv.jp>: host s1xx.coresv.jp[202.172.28.1xx] said: 552 sorry, your
    domain isn't in my list of allowed senderhosts (#5.7.1) (in reply to MAIL
    FROM command)

要するに「あなたのドメインは送信元ドメイン許可リストに入っていません」と言っている。にも関わらず、他のぜんぜん関係ないメールサーバ(メールアカウント)からメールを送るとちゃんと受け取る。さっぱり意味不明。検索すると同じようにハマっている人多数

色々調べてみたところ、原因がはっきりしました。

  • POP before SMTPの設定時間(タイムアウト)が3時間以上!
  • POP before SMTPで「リレー許可リスト」に登録されると、そのIPからのSMTP接続はすべて外部への中継(リレー)として扱われる

どちらの仕様もバカ素敵すぎて言葉もない。

つまり、

  1. SMTPサーバでもあるIPで、CORESERVERからメールを受信する。
  2. CORESERVER側で「リレー許可リスト」に登録される。
  3. 手元のSMTPサーバからCORESERVER宛にメールを送信する。
  4. CORESERVERは「リレー許可リスト」に登録さているという理由だけで、外部から自分宛のメール送信を強制的に内部(CORESERVER)から外部へのメール送信と見なす。
  5. CORESERVERは外部へのメール送信のとき、予め登録された自ドメイン(senderhosts)にSMTPのFROM*4ドメインが含まれないためメールを拒否する。
  6. CORESERVERは自分宛のメールを552のエラーとして受取拒否する

ということです。

そしておそらく「リレー許可リスト」はサーバごとに全ユーザ共有だと思われるので(未確認)、たとえ自分でPOPしていなくても時々メールが送れないサーバが出てくる……と。

Gmailには

Gmailには、Gmailに統合してあるアカウント名義でメールを送信する目的で外部SMTPサーバを使用してメールを送信する機能がありまして、それを使うとバッチリメールが送れなくなるわけです。

これをしないと、GmailではFromの代理送信表示がされてしまいます。

*4 : SMTPにおけるFROMであるのでFROMヘッダとは異なる

総評

VALUE DOMAINのDNS設定も、何行か書くとすぐバグるし(行を入れ替えないとダメとか)、いまいちツメが甘い印象がぬぐえない。所詮、安かろうなんたらでしょうか。サーバスペックはいいんだけど、障害対応も遅いみたいだしねぇ。今回は安定性重視なのでCORESERVERは却下の方向。

どこか、もちょっとマトモなレンタルサーバ知りませんか?(苦笑)

追記

なんかググってたらこの記事のほぼコピペのブログが。せめてリンクぐらいしようや……。*5

*5 : 少し書き換えてあるのがなおたち悪い。どっちにしろ著作権的にはアウトだけども。

2009/07/01(水)メールの添付ファイル名とMIME文字コードと色々メモ

OK キャンセル 確認 その他