<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"><channel><title>Disqus - Latest Comments for agektmr</title><link>http://disqus.com/people/agektmr/</link><description></description><language>en</language><lastBuildDate>Thu, 09 Apr 2009 23:34:58 -0000</lastBuildDate><item><title>Re: content-rewite機能で外部ファイルのキャッシュを制御する</title><link>http://agektmr.disqus.com/content_rewite/#comment-8026392</link><description>ようやく確認できました。確かに、仕様もShindigの実装もinclude-urlのように単数形になってますね。&lt;br&gt;まあ、しょせんキャッシュ制御なのでいいっちゃいいんだけど、今まで動いてたガジェットで不具合が出る可能性はありますね・・・</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">agektmr</dc:creator><pubDate>Thu, 09 Apr 2009 23:34:58 -0000</pubDate></item><item><title>Re: mixiアプリが公開 / はてぶチェッカーをリリース</title><link>http://agektmr.disqus.com/mixi/#comment-8023547</link><description>&amp;gt; OpenSocialのドキュメントに orkut.PersonField とちゃんと記載がありますよ。&lt;br&gt;&lt;br&gt;確かに、ありますね。ただ、MySpaceはMyOpenSpace.Person.Fieldというスタイルで、&lt;br&gt;&lt;a href="http://wiki.developer.myspace.com/index.php?title=MySpace_Specific_Extensions_on_OpenSocial" rel="nofollow"&gt;http://wiki.developer.myspace.com/index.php?tit...&lt;/a&gt;&lt;br&gt;&lt;br&gt;の方が個人的には好みかな・・・&lt;br&gt;&lt;br&gt;どちらも間違いではないと思いますので、余計なお世話でしたね・・・</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">agektmr</dc:creator><pubDate>Thu, 09 Apr 2009 21:38:38 -0000</pubDate></item><item><title>Re: OpenSocialガジェット開発で注意すべきキャッシュ機能</title><link>http://agektmr.disqus.com/opensocial_25/#comment-5795287</link><description>そうですね。確かにProxyURLを使ったやり方の方が汎用性が上がってスマートです。&lt;br&gt;Gadget API Japanグループで伊藤さんがJSを読み込むサンプルコードを紹介されてました。&lt;br&gt;&lt;a href="http://groups.google.co.jp/group/Google-Gadgets-API-Japan/tree/browse_frm/month/2008-09?_done=%252Fgroup%252FGoogle-Gadgets-API-Japan%252Fbrowse_frm%252Fmonth%252F2008-09%253F&amp;pli=1" rel="nofollow"&gt;http://groups.google.co.jp/group/Google-Gadgets...&lt;/a&gt;&lt;br&gt;&lt;br&gt;&amp;lt;script type="text/javascript"&amp;gt; &lt;br&gt;  var url = gadgets.io.getProxyUrl('http://std-ig.googlecode.com/svn/ &lt;br&gt;trunk/std-ig.js'); &lt;br&gt;  document.open(); &lt;br&gt;  document.write('&amp;lt;scr'+'ipt src="' + url + '"&amp;gt;&amp;lt;/scr' + 'ipt&amp;gt;'); &lt;br&gt;  document.close(); &lt;br&gt;&amp;lt;/script&amp;gt;&lt;br&gt;&lt;br&gt;後ほど追記しておきます。</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">agektmr</dc:creator><pubDate>Mon, 02 Feb 2009 21:04:53 -0000</pubDate></item><item><title>Re: Multilingualize your Wordpress blog with WP_Multilingual!</title><link>http://agektmr.disqus.com/multilingualize_your_wordpress_blog_with_wp_multilingual/#comment-5063865</link><description>えーじ様、早速有難うございます。&lt;br&gt;&lt;br&gt;&amp;gt; Admin画面で例えば記事を更新する際に、メモリを使い切ってエラーを出すことがあり、&lt;br&gt;&amp;gt; その後ブログにアクセスするとリダイレクトがループしてブラウザが止めてしまう、という現象が見られます。&lt;br&gt;&lt;br&gt;当方で発生しているのと全く同じ現象です。パーマリンク設定画面を出そうとするとメモリを使い切りますね。&lt;br&gt;以下のように、パーマリンクを新規投稿の際に設定できる補助用のプラグインもあるようですが…。&lt;br&gt;&lt;a href="http://wordpress.org/support/topic/171441?replies=12" rel="nofollow"&gt;http://wordpress.org/support/topic/171441?repli...&lt;/a&gt;&lt;br&gt;&lt;br&gt;URLにenやjaという文字が含まれている場合にも不具合が起きるとか起きないとか、みたいです。</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Urbn</dc:creator><pubDate>Sun, 11 Jan 2009 20:31:44 -0000</pubDate></item><item><title>Re: Multilingualize your Wordpress blog with WP_Multilingual!</title><link>http://agektmr.disqus.com/multilingualize_your_wordpress_blog_with_wp_multilingual/#comment-5060254</link><description>Urbn様&lt;br&gt;&lt;br&gt;えーじです。このブログではパーマリンクを記事番号で行っていますが、今のところパーマリンクで問題が起こってはいません。&lt;br&gt;ただ、Admin画面で例えば記事を更新する際に、メモリを使い切ってエラーを出すことがあり、その後ブログにアクセスするとリダイレクトがループしてブラウザが止めてしまう、という現象が見られます。一度プラグインをはずして戻すと回復するのですが、ちょっと困ってます。&lt;br&gt;&lt;br&gt;いずれにしても、今のところ自分でhtaccessをいじったり、プラグインのソースコードをいじったりといったことをしなくても正常に動作しているようです。何か分かりましたらまたこのスレッドでお知らせしますね。</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">agektmr</dc:creator><pubDate>Sun, 11 Jan 2009 15:09:42 -0000</pubDate></item><item><title>Re: FriendConnect実験中</title><link>http://agektmr.disqus.com/friendconnect_96/#comment-4601051</link><description>ここにコメントを入力</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">agektmr</dc:creator><pubDate>Tue, 23 Dec 2008 21:59:33 -0000</pubDate></item><item><title>Re: OAuthの署名方式を掘り下げる</title><link>http://agektmr.disqus.com/oauth_06/#comment-2931908</link><description>&amp;gt; 公開鍵の扱いが中途半端な実装になっているのは、RSA署名方式自体が、署名の潜在的偽造の可能性があるからかもしれないのか？&lt;br&gt;&lt;br&gt;これは単純に、まだ内輪で話が済んでいるからでしょう。もっと一般的になってくると、厳密に仕様を作り、乗っ取っていなければならなくなると思います。&lt;br&gt;&lt;br&gt;&amp;gt; HMAC方式はお互いに秘密鍵を保有することで、すでに秘匿性が担保されていると考えてもいいのか。&lt;br&gt;&lt;br&gt;秘匿性とはなんでしょうか？署名はあくまで自分が名乗っている通りである事を証明するものであり、リクエストの内容を隠すものではありません。リクエストの内容を隠したい場合はSSLなどを利用します。&lt;br&gt;&lt;br&gt;&amp;gt; コンシューマーがリクエストする際に公開鍵を指定する仕様なら、誰でもなりすましができてしまう。&lt;br&gt;ハードコーディングは、公開鍵を事前に渡しておくことと捉えるなら、それなりに納得できる気もするが。&lt;br&gt;&lt;br&gt;公開鍵は誰が見ても、誰が使っても、なりすましには利用できません。&lt;br&gt;署名の目的は、自分が名乗っている通りの者である事を証明すること。RSA秘密鍵を使って作られた署名は、RSA公開鍵を使ってのみ可逆なので、公開鍵で開けらる署名は秘密鍵の持ち主だと判断できます。また、その公開鍵で開けられる署名は、対となる秘密鍵でしか作る事ができません。&lt;br&gt;&lt;br&gt;というわけで、秘密鍵が漏洩することさえなければ、公開鍵をハードコーディングする事も、動的に公開鍵を渡す事も特に問題はありません。</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">agektmr</dc:creator><pubDate>Wed, 08 Oct 2008 01:37:22 -0000</pubDate></item><item><title>Re: サイト開設１周年記念「第2世代iPod touch 8GB＋おまけ」をプレゼント!!</title><link>http://iphone-ipodtouch-lab.disqus.com/12ipod_touch_8gb/#comment-2919048</link><description>いつも記事を読ませていただいてます。&lt;br&gt;プレゼントに応募します。781</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">agektmr</dc:creator><pubDate>Tue, 07 Oct 2008 12:06:21 -0000</pubDate></item><item><title>Re: オープンなコンタクトリスト仕様、Portable Contacts</title><link>http://agektmr.disqus.com/portable_contacts/#comment-2521417</link><description>OpenSocialに限って言えば、OAuth認証は対で考えるべきです。&lt;br&gt;ただ、公開はされていませんがmixi station等で使われているmixiのAtomPub APIではWSSI認証が使用されています。他にもBasic認証やDigest認証等、方式はいくつか考えられると思いますが、第三者を介してAPIからデータを取得するという意味では、いずれにしても今はOAuthが最も有力なプロトコルになります。&lt;br&gt;ちなみに、JavaScriptでも裏のリクエスト処理はREST/RPCを使って行われています。例えばShindigのガジェット上ではセキュリティトークンというセッションキーのようなものが利用されています。そういう意味では、モバイルであろうとなかろうと、認証は必要です。&lt;br&gt;ただ、OAuth(厳密にはOAuth Core)はユーザーのログイン処理というインタラクションが挟まりますので、少し話は複雑です。OAuth Consumer Request(gumiが利用)ですと、ユーザーの認証処理等が挟まりませんので、割と話は単純です。</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">agektmr</dc:creator><pubDate>Mon, 22 Sep 2008 12:21:13 -0000</pubDate></item><item><title>Re: オープンなコンタクトリスト仕様、Portable Contacts</title><link>http://agektmr.disqus.com/portable_contacts/#comment-2514729</link><description>なるほど、理解しました。&lt;br&gt;&lt;br&gt;REST ful APIをサポートするということと、OAuth認証は対で考えるべきことですか？&lt;br&gt;モバイルの場合、JavaScriptが利用できないので、REST ful APIをサポートすることが必然なのでしょうか。&lt;br&gt;shindigのいくつのバージョンから本格対応するのかは知りませんが、&lt;br&gt;gumiはモバイル対応するべく、REST ful API ＋OAuth認証に対応しているような言い方です。</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">kazu</dc:creator><pubDate>Mon, 22 Sep 2008 01:45:47 -0000</pubDate></item><item><title>Re: オープンなコンタクトリスト仕様、Portable Contacts</title><link>http://agektmr.disqus.com/portable_contacts/#comment-2438876</link><description>そのためにOAuthという仕様が存在します。Social Webのコンセプトは「自分のデータを自分の意思でコントロールできること」にあり、OAuthはプライバシ管理のために使用されます。&lt;br&gt;そのため、mixiでPortable Contactsの仕様がオープンなAPIで公開されたとしても、他サービスがごっそりそれをインポートする事はできません。OAuthにより、ユーザーごとに個別に認証を行う必要があります。&lt;br&gt;そういう意味で危険なリスクと呼べるものはないかも。&lt;br&gt;ただ、誰かが友達リストをインポートする事で、自分のプロフィール写真が他の人の目にさらされた！というクレームはありえると思います。重箱の隅つつきとしか思えませんが。</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">agektmr</dc:creator><pubDate>Fri, 19 Sep 2008 05:22:53 -0000</pubDate></item></channel></rss>