「LINODE」を含む日記 RSS

はてなキーワード: LINODEとは

2018-08-09

なんか定期的に出るんだね

anond.hatelabo.jp/keyword/Linode

検索すると定期的に似たようなネタで出て来るんだな

2018年にもなって 2chないわー

2017-01-31

【開発】アンテナサイトのジェネレーターを作った

しがないWebエンジニアをしています

今年の1月からチマチマ作っていたアンテナサイトのジェネレータを公開しました

アンテナサイトメーカー

http://antena-mk.com/home

サービス説明

お好みのRSS登録するだけであなただけのアンテナサイトの完成です。

自身広告掲載できるので、お小遣い稼ぎもできます

Google Analyticsコードを使ってアクセス解析もできます

ダッシュボードにて、アクセスランキング、逆アクセスランキングなんかも見ることができます

今後はアクセスに応じて調整するような機能などを追加していく予定です。

使用技術

作ってみた感想


ぜひ使って感想ください!

2016-04-26

anond:20160426145507 の続き

anond:20160426124418anond:20160426145507 の続きだゾ。てか長えよ

(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数動画アップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシSaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)

(略: 個人ユーザ向けのAPI設計ばかりで、雇用者上司アカウント管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuth活用しているが、Google Apps for BusinessはOAuth以外のシステムを使っている。)

(略: 主要な設計ミスは、外部サービスすべてを同等に疑うところ。管理者が各サービスの信用性を判断して権限を調節できるようにしないところ。これまでどれほど多くの製品OAuthの面倒さのために失敗してきたことか。)

普通実装における」OAuth代替

適切な OAuth ベース設計とはどのようなもの

ここまでで「普通実装における」OAuth がまったくおかしいということはわかりましたが、OAuth が実際うまくいくのはどういうときでしょうか。

初期の OAuth 規格および概念におおよそ付き従っているシステム一般的に言って、新しい規格ベースのよりもセキュアで、マシです。OAuth 1.0 の実装がすべてセキュアだというのではありませんが、たいてい問題は少ないです。こうしたシステムは通常、次のふたつのアプローチのどちらかに従っています:

はいえ、このように設計されている OAuth ベースシステムはごくごく希少で、しか一般的にこうしたシステムは、他のところで使われている OAuth とは似ても似つかぬものです。OAuth 1.0 規格の方に寄って頑張っていますが、公式には 1.0 は非推奨ですから、こうしたアプローチを使っているシステムはそのうち「アップデート」されて OAuth 2.0概念や追加機能すべてを加えて再構築され、セキュリティユーザビリティをだめにしてしまうことになります。これこそ筆者があらゆる OAuth ベースのものを見逃したくない理由です。もっと古く、もっと機能的な形式OAuth を使っていても、システムに「改善」が必要だという素敵な考えを管理者のだれかが閃いて台無しにしてしまうからです。ご迷惑をおかけしてすみませんと言うぐらいなら、まったく別のものを使うほうが良いですよね。

他の選択肢

他に手はないかと探すとき、人々はよく他の「フレームワーク」にはどんなものがあるかを知ろうとします。しかし、考え抜かれたセキュアな設計を実現するためには必ずしもフレームワーク必要というわけではありません。現状、OAuth とはどのようなものかについての意見サービスごとに異なっていますので、承認の具体的な動作の仕組みもまったく一定ではありません。そんな中でフレームワークを探しまわるのは、簡単にできることをいたずらに複雑化しているだけのことが多いです。唯一ほんとうに難しい要素、しっかりした規格の必要な要素は、使用する鍵パラメータ改竄を防ぐため変数署名する方法だけであり、この点に関して、ほとんどの OAuth ベース実装は一切何もしてくれません。

ウェブサービスの最大手である Amazon は、世界中企業サービス提供する一流プロバイダで、合計 30% 以上という途方もない市場シェア他者を圧倒していますAmazonアプローチは、自分アプリ認証情報を生成できるコントロールパネルへのアクセスを、すべてのアカウントおよびアカウント管理者提供することです。この認証情報で、どの Amazon サービス作業できるか、そのサービスでどの操作を実行できるか、どの権限作業しなければいけないかを指定できます。この認証情報必要に応じて「アカウントホルダ」の人が破棄することもできます

AmazonAPI における認証承認技術には、本質的制限が多く潜在的危険性のあるリダイレクトを一切必要しません。Amazonプロトコル認証情報は、直接送ることは一切なく、データ署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。

Amazon設計アカウントの利用状況を API の利用まで適切に把握できますし、API認証承認もすべて Amazonからスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています

ひとつ言及せざるをえない短所は、Amazon権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計問題であって、承認プロセス自体の失点ではありません。さらに、Amazonコントロールパネルはかなりキビキビ使えて、それ自体API でも使えます。この点たとえば Google場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。

Amazon認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされていますGoogle 自身企業向け製品の一部でこれを利用できるようにしていますGoogle 自身純粋OAuth 設計企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています

JWT はサービス間の SSOAPI 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやす方法で一切の面倒なく達成しています。HMAC 実装ひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。

ただ Google場合典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求していますGoogleコントロールパネルではアカウント管理者自分企業サービス用に新しい鍵ペアを生成でき、API ログイン署名するために使う秘密鍵ダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Googleプロセス全体を本当に無駄に複雑化していますコントロールパネルしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例必要なら他をあたるようお勧めします。

他に使われている技術は、サードパーティがどんな権限必要としているかをある種の XMLJSON ファイル定義してウェブサイト送信できるようにするサービスのものです。ユーザがあるページを自分アカウント訪問し、ファイルURL (あるいは中身) をそこに貼り付けると、その外部サービスあるいはアプリが求めている権限の一覧やそこに含まれ説明などが表示されるようになっています。それを見て認可したいと思うユーザは、認証情報を生成してそのサードパーティアプリあるいはサービスに貼り付けますユーザは後で無効にしたくなったら認証情報を破棄することができます。これも、開発者おかし負担を強いることなく、すべてのアカウントAPI サービスがあり、権限管理を備え、サービス自体からフローが始まる、実にセキュアな設計です。

承認管理のためにサービスから提供してもらう必要が本当にあるのは、適切な役職 (管理者アカウント所有者など) を持つユーザ自分に割り当てられた権限や (望むなら) 期限を持つ認証情報API 利用のために生成できる何らかのパネルだけです。こうした認証情報はその後、お好みのセキュアな認証システムを通して利用することができます。たとえば HTTP Basic Authentication over HTTPS のような単純なもの、これは事実上どの HTTP ライブラリにも入っていますし、HTTP Digest Authentication、これはもっとセキュアでありながらほとんどの良質なライブラリサポートされていますし、その他 HMAC, RSA, 楕円関数など認証情報ネットに通す必要のない暗号学的テクノロジー活用した認証プログラムに基づくものなら何でも使えます特に HMAC は、承認認証実装するほとんどすべての人 (Amazon や、一部の OAuth 実装も含む) によって既に使われています

こういった種々の実績あるテクニックは、セキュアなプラットフォームを作るために CSRF 対策など複数フレームワーク同士の相性を勉強する必要があるという重荷を軽くしてくれますし、一般的に、既存アーキテクチャワンタッチで装着できるようなモジュール化の実装が可能です。ユーザアプリ認証情報が盗まれる可能性をなくしてくれます。ややこしい CSPRNG を常に使用する必要もありません。このようなシステムOAuth の生まれるずっと前から存在しており、現在でも一般的です。OAuth は、ユーザ認証情報要求したり他に弱点があったりするような一部の劣悪な設計システムよりはセキュリティが良いかもしれませんが、既にある真の設計を置き換えるものではありません。OAuth が解決すると主張する問題点は実のところ、既存の良く設計されたシステムには存在していませんし、「普通実装における」OAuth は実のところ、解決すると主張する問題の多くを招き入れるばかりか、最初存在していなかった問題まで生じさせています宣伝文句と違って、OAuth にすれば自然と驚くほどセキュアになるというわけではなく、むしろ数々の短所実装の困難さを考えれば、他の考え抜かれた選択肢のほうがはるかに優れています

これからサービス設計をして API アクセス提供することになっている方はどうか、ご自分が実現しようとなさっているのが何なのかを本当に考えてください。他の人がやっていることをコピーするだけで済ませたり宣伝を丸呑みしたりしないでください。どうしてもコピーしなければいけないなら、Amazon (これが最善です) や Rackspace, IBM SoftLayer, Linode, VULTR, Zoho, Zoom ほか、API の素直で健全認証システムを構築する方法について現時点で多少なりとも理解のあるところをコピーするようにしてください。

2016 年 4月 Insane Coder

http://no-oauth.insanecoding.org/

OAuthのことを1ミリも知らない俺が

OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324

http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html

OAuth がうまくいかない理由と、既存サービスゼロデイ攻撃方法

OAuth とは

認証 (authentication: 本人確認) と承認 (authorization: 権限付与) のシステムを設計し、API を規定し、複数の異なるシステムを統合するために用いられる提案をまとめたものです。

OAuth には色々な種類があり、version 1.1a や 2、その各部の上に他の規格を乗せたものなどが存在します。世の中に出回っている数々の実装によって、具体的な利用状況は大きく異なります。

おことわり

前にも OAuth について書いたことがあり、たくさんの反響をいただきました。前回の記事に対する批判の一部を避けるため、今回の記事について先に断っておきたいのですが、この記事は OAuth の使われる典型的な場面に焦点を当てており、論じられる点のほとんどは、何らかの方法OAuth を利用する大手サービスのほとんどすべてに当てはまるということです。

言いかえると、OAuth を用いているあらゆるプラットフォームが壊れているとは限りません。OAuth にはバリエーションが多いうえに、2.0 だけに限っても 76 ページに渡るパターンがありますので、OAuth に基づいた何かに適合していながらもセキュアであり、使っても問題ないものは存在しうると言えます。ですから、あなたお気に入りOAuth 実装や設計が、ここで論じられる問題の一部または全部を免れていることもありえます。確率は低いですが。

また、OAuth を使っているものの中には規格を誤用しているものがあるとか、OAuth はその使い方を強制しているわけではないとか言う人もいるかもしれません。どちらにせよ、ここでは特定の OAuth ベースの規格について述べるのではなく、現状で大手が OAuth をどう利用しているかについてを、それが規格に適っているかどうかに関わりなく論じるつもりです。こうすることで、多くの読者に影響を与えることになるでしょう。危険な方法OAuth を使っているサービス利用者であっても、また自ら OAuth ベースサービスを管理していて、他のみんなが作っているのを真似てプラットフォームを作ろうと思っている人だとしても関係があるのです。

記事の構成

この記事は長くなりますし、言ってみればほとんどの章はそれ自体でひとつの記事として十分なほどの話題を扱いますので、大まかな流れをご説明しておきましょう。

この記事は、現在 OAuth 業界でおこなわれていることを調査した結果のまとめです。OAuth を使う製品のすべてにこの記事のあらゆる点が当てはまるというのではなく、危険だったり無価値だったりするサービスの背後に見つかった慣例や根本原因を紹介する記事です。

この前書きのあとは、まず OAuthセキュリティ欠陥を分析することから始めるつもりです。こうした欠陥の中には、セキュリティコミュニティでよく知られていて、書籍などですでに分析されている一般原則が当てはまるものもあります。しかしこの記事では書籍化されていないケースも扱いますし、有名な欠陥についても、平均的な開発者および責任者に理解しやすく、対策の必要性がはっきりするように工夫するつもりです。

その後は、OAuth の主要素が一般的に言ってどのように実装されており、そうした普通の実装がどのようにサービスを使いものにならなくするのか、すなわちそのサービスで達成できることを極度に、不適切に、かつ意図に反して低下させてしまうのかを分析します。ごく一部のケースでは回避策の足がかりになるかもしれないテクニックについて論じますが、そういうのを実装する馬鹿らしさにも注目します。こうした記述の中では繰り返し何度も、OAuth を使う人たちがどれほど自分と自分のビジネスにとって損なことをしているのかが説明されます。

最後に、OAuth が適切に使われうる数少ない場面と、すでに利用されている OAuth の代替品を簡単に取り上げます。代替技術に関する調査の結果を提供するつもりですが、その中には Amazon のような大企業がセキュアで使いやすく信頼性の高い API を実現するために何をしているかの報告も含まれるでしょう。

責任ある情報公開

いま普通に使われているかたちにおける OAuth の欠陥の幾つかを悪用すれば、大手サービスに対して強力な攻撃を仕掛けることができます。OAuth に対する攻撃は何も新しいものではありません。IBM や Oracle を含め、懸念した IETF メンバーOAuth ベースサービスに対する攻撃を 50 クラスも記述した 71 ページもの文書を 3 年以上前に出したように、また筆者も前回の記事でこうした点のいくつかを議論したようにです。それにも関わらず、OAuth ベースシステムの主要なセキュリティ欠陥は非常に蔓延しています。

筆者は、いくつかの大手企業の役員や開発者に、そこの OAuth ベースシステムが抱えるセキュリティ欠陥を指摘したことがあります (そのうちのひとつは 4 年前のことです) が、全員、自社システムを修正するために一切何もしませんでした。まるで、OAuth の人気度からして、他の現実的な解決策をひとつも聞いたことがなく、それゆえに OAuth が最もセキュアな選択肢に違いないと決めてかかっているようです。どうも、OAuth のコア原則に対する攻撃のデモを文書化した情報も、聞いたことがないか、肩をすくめて無視するかしているようです。そこで、この情報をもっと広く拡散することによって、影響のある人たちの尻を蹴りとばしてあげたい、そしてサービスを設計あるいは管理している人たちにモーニングコールの役割を果たしてあげたいと願っています。

というわけで、OAuth ベースの何かを提供あるいは利用するご自分のサービスを調べて、こうした欠陥の一部あるいは全部が存在することに気づいたなら、どうぞ責任をもってこの情報を取り扱ってください。ご自分のサービスを適切にアップデートしたり、関係する問題に対応するようビジネスパートナーに適切な圧力をかけたりしてください。

ここで言及されている情報やリンクされている情報は今のところ既存のサービス悪用できるかもしれませんが、どうぞ責任ある行動をとり、他人のもの破壊するのではなく改善することを目指してください。この記事は、自社サービス不適切に実装している人たちへのモーニングコールのつもりで、その改善を促すために書いているのであり、悪用したがっているハッカーたちのハウツーもののつもりではないのです。

想定する利用形態

この記事では、ふたつのシナリオに注目して、その場面でどのように OAuth が組み合わされているのか、そしてなぜうまくいかないのかを検討します。記事を通して何度もこれらのシナリオに戻ってきますので、頭に入れておくことは大事です。

まず、Exciting Video Service (略して EVS) というサービスを思い描いてみましょう。ユーザが動画をアップロードしたり友人と共有したりできて、完全公開にしたりアクセス制限を設定したりできるようになっています。また EVS は動画のアップロードや削除、およびだれが視聴できるかの権限管理に OAuth ベースの API を提供しています。

ただ、例としてこの想像上のサービスに焦点をあてますが、論じられる問題はあらゆるサービスにも当てはまります。ファイルであろうと文書ストレージであろうと、カレンダー管理やオンライン会議、ディスカッショングループ、はたまたリソース管理であろうと OAuth ベース API を提供する他のいかなるものであろうとです。また、筆者は本当にどの特定の動画サービスのことも言っていないということを覚えておいてください。問題点の一部あるいは全部は、OAuth を使っている既存の動画サービスに当てはまるかもしれませんが、EVS がそのサービスのことを指すわけではありません。どれが当てはまるかは読者への練習問題ということにしてもいいですね。

ひとつめのシナリオとして、ビデオカメラの製造会社を想定しましょう。そのビデオカメラには、録画した内容を EVS にアップロードする機能のあるソフトウェアを付属させたいと思っています。つまり、ユーザビデオカメラを自分のコンピュータに接続して、その独自ソフトウェアを開き、ビデオカメラからアップロードしたい動画を選んでしばらくすると、それが EVS にアップロードされているというものです。

ふたつめのシナリオとしては、ある中小企業が職員用に EVS で 50 アカウントを購入し、全職員が動画をアップロードして同じ部門の職員と共有できるようにする、ということにしましょう。この会社は A Friendly Custom Platform (AFCP) というソフトウェアで職員と所属部門の管理をしており、この AFCP サービスを EVS に統合したいと考えています。望んでいるのは、管理者が AFCP を使ってだれかを営業部門に配置したら、その職員が自動的営業部門メンバー所有の動画すべてに対するアクセス権を取得するということです。営業部門からいなくなった人には逆のことが起こるようにもしてほしいと思うはずです。

問題点

セキュリティ関連
認証情報の盗難 / アクセス権の詐称

トークンベースの認証システム (OAuth のコア) が現在よく利用されている最大の理由のひとつには、「適切に実装されれば」サードパーティアプリサービスに各ユーザの認証情報 (パスワード等) を提供しなくて済むという点があります。サードパーティに個人ユーザの認証情報を渡すのは、以下の理由から望ましくありません:

上記の問題点は、OAuth だけでなくあらゆるトークンベースの認証システムでも回避できます。よく OAuth の強みとして挙げられていますが、独自というわけでは全然なくて、他にも同じ強みを実現しつつ OAuth の弱点のない選択肢はあるのです。

さて、確固とした土台に基づいてはいるものの、「普通の実装における」OAuth は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:

  1. ユーザサードパーティアプリ/サービス (たとえば AFCP) を訪ねて、特定のサービスと統合したいことを知らせる。
  2. AFCP は、EVS でホスティングされた特別なログインページを出してユーザに EVS の認証情報を入力させる。
  3. EVS は、その指定したアクセスレベルユーザが本当にサードパーティ (AFCP) へ与えたいのか確認する。
  4. EVS は AFCP に一種のトークン (複数の場合もある) を提供し、各種 API コールに使えるようにする。

このトークンユーザの認証情報ではありませんから、そしてひとりのユーザひとつアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。

この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。

(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)

(略: そうした詐欺を企業自体が後押ししているような風潮もある)

(略: スタンドアロンアプリなら、ログインを詐称する必要すらない)

この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザ組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は?

クライアントアプリユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。OAuth は悪意あるアプリに対していかなる防御策も提供していないので、エンドユーザインストールするネイティブアプリすべての信頼性に自分で責任を負う。

さらに

クライアント開発者は、ユーザから直接に認証情報を集めるようなクライアントアプリを書くべきではなく、システムブラウザのような信用できるシステムコンポーネントにこの役目を移譲すべきだ。

基本的に言って、OAuthセキュリティガイドラインは、OAuth を利用する開発者ユーザを攻撃しようとすべきではないとか、悪いことをしてはならないと言っています。外部の開発者が悪いことをしないことに頼るというのは、正気のサービス設計者が依拠するセキュリティモデルではありません。

私の知る主要な OAuth ベースサービスはほぼすべて、ここに概説した手法で攻撃可能です。

OAuth こそセキュリティの新たな金字塔だとお考えの皆さん、目を覚ましてください! 「普通の実装における」OAuth は、始まる前から負けていますよ。OAuth が存在するよりずっと前に実装された数多くのシステムはセキュアで、この問題を効率的に回避しています。残念なことに、あまりに多くのサービスが、せっかくセキュアだったのにインセキュアな OAuth モデルに移行してきました。だれかが開発者管理者に「OAuthもっとセキュア」「先取り思考」「将来への投資」とか何とか素敵な (しかし具体性の皆無な) バズワードを並べたてたからでしょう。ほとんどの場合、こうした変更は本当に既存の問題に対応しているのか、あるいは以前のシステムより幾らかでも良くしてくれるのかどうかをレビューすることさえなく実装されています。

OAuth サービスに偽装

OAuth ベースサービス設計でよく見かける間違いは、ブラウザ用に、パラメータひとつとして client_secret (あるいは同様のもの) を受け取るエンドポイントを提供することです。OAuth の client_id と client_secret パラメータは、基本的に言ってサードパーティプラットフォーム固有の API ユーザ名とパスワードと等価ですから、EVS の API を利用する開発者だけにしか知られるべきではありません。パスワード同然のものなのですから、client_secret パラメータは「絶対に」ユーザブラウザを通して送信すべきではありません (ヒント: パラメータ名の中に secret という言葉が入っているよ)。アプリサービスユーザがその client_id と client_secret を見つけることができる場合、そのユーザはそのサービスのふりをすることができ、潜在的には何かイケナイことができてしまうということになります。さらに注意すべき点として、client_secret パラメータを別の名前にするサービスもありますから、ご自分の関係するサービスをよくチェックして、他のパラメータも秘密にする必要があるのかどうかを調べてください。残念ながら、重要な変数が自分の素性をいつも表に出しているとは限らないため、この問題は意外と多く存在しています。加えて、client_id だけ使う認証フローOAuth の上に乗せるサービスも出てくるでしょう。これには用心してください。特定の状況では、そういう client_id はまさしく client_secret 同然の働きをするのですから。

「普通の実装における」OAuth は、ウェブブラウザを使ってユーザを複数のウェブサイトに移動させるわけで、ひとつサイトから別のサイトに client_id と client_secret (あるいは同様のもの) を送ってもらう必要があります。そうやって、たとえば AFCP と EVS の間でこれらをやりとりするわけですから、ユーザブラウザの HTTP ログをモニタリングすれば、本当に見えてしまいます。これはアプリに組み込まれた独自ブラウザ各種でも、単に右クリックすれば何らかのネットワーク・ログ機能を持つ何らかの inspector にアクセスできてしまう場合などには可能です。

EVS と連携した AFCP にこの欠陥があると、AFCP に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に FacebookGMail 用の OAuth エンドポイントを利用しているとして、client_id と client_secret の両方がブラウザを通して送信される場合、Facebookユーザは全員 GMail に対して Facebookのもののふりをすることができてしまうということです。

この問題は、OAuth エンドポイントユーザウェブブラウザから平文で client_secret を送ってくることを期待するときにはいつも存在します。あるいはそうする必要があると誤解した API 利用者が、埋め込むべきでないところに secret を埋め込むときもです。この脆弱性が存在している可能性が高いのは、エンドポイントが client_secret (または同等品) と redirect_uri の両方を期待する (あるいはオプションとしてでも受け付ける) 場合です。redirect_uri パラメータは、今回のケースで言うと EVS がユーザログインさせたあとでそのブラウザをどこに送るべきか指示するために使うよう設計されています。そうやって redirect_uri がエンドポイントへの転送に使われている場合、その処理はユーザブラウザで実行されることが期待されているわけです。主要な OAuth 文書はどちらも、client_secret と redirect_uri の両方をこうした用途に使うようなケースを指示したり求めたりはしていません。

ざっと検索してみたところ、残念なことに、潜在的に違反の可能性があるそういった OAuth ベース API がたくさん見つかります。GoogleOAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローひとつあります:

client_secret: 開発者コンソールで取得したクライアントパスワード (Android, iOS, Chrome アプリとして登録した場合のオプション)

Citrix もこんな間違いをしています:

(略: 以下、実際に脆弱だと確認したわけではないが、secret と redirect を併記しているサイトが列挙されている。)

Google で 2 分検索しただけでこのリストができました。皆様がもうちょっと労力をかければ、ずっと多く見つかることでしょう。ただし、上記リストは、こうしたサービスのどれかが脆弱だとか、誤用しやすすぎるということを直接に示すものではありません。色々な要素があり、たとえば Zendesk は特にこのケースでは redirect_uri パラメータリダイレクトに使わないと明言していますし、アプリからエンドポイントを呼ぶときはフル機能版ブラウザではなく curl を使うべきだとさえ書いて、開発者が危険なことをするような誤解を極力避けようとしています。それでも、経験の浅い開発者はこうしたエンドポイントを独自ブラウザで読もうとするかもしれません。さらに、この組み合わせが世に出回っているというだけで開発者の警戒心が下がっていき、経験を積んだ OAuth ベースサービス開発者でさえも似たような状況で潜在的ヤバイ誤用を気にせず適用するようになってきています。特に client_secret が別の名前になって、「秘密を守る」という概念が失われている場合はそうです。

サービスがこの点に関して壊れている指標となるのは、人気のある複数の OAuth ライブラリがこのサービスでうまく動かないときです。そういうサービス一般的にいって独自の「SDK」を提供しており、サードパーティ開発者が選んだライブラリではこのフランケンシュタイン的な OAuth が使えないと苦情が来たときにはその SDK を使うよう指示します。こうしたカスタマイズは気付かれないまま進行することも多くあります。開発者の大多数は、SDK が提供されているなら、わざわざ手元のソフトで頑張らずに済ませたいと思うものですから。

この種の攻撃は前述のセキュリティ文書で「4.1.1. クライアント機密情報を取得する脅威」に分類されています。しかしサーバウェブブラウザを使用を要求し client_id と client_secret (または似た用途のもの) を同時に渡させるという具体的な攻撃パターンには一言も言及がありません。おそらく、その文書の執筆陣の予想では、こんな馬鹿げたサービスはだれも設計しないだろうし、その API を使う開発者もそれを独自のウェブブラウザや SDK で使ったりはしないだろうと思っていたのでしょう。こうした開発者OAuth の規格からバラバラに取り出した要素をグチャグチャに混ぜて接着しておいて、自分のプラットフォームOAuth 本来のセキュリティを保持していると思っています。そのツギハギのせいでどんな新しい問題が入り込むかもしれないのに、そこは一顧だにしません。残念ながら、これが近年の OAuth 業界によくあるやり方で、この既に猛威をふるっている問題は、パレード参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。

おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。GoogleOAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントウェブブラウザベースアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフロー標準的ブラウザ用のエンドポイントコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。

前掲のセキュリティ文書は、 Permalink | 記事への反応(3) | 12:44

2013-03-03

RailsとTwitterBootstrapでエロ動画ソーシャルブックマークWebサービス作った

Rails + Twitter bootstrapでエロ動画ソーシャルブックマークWebサービスソーシャルオナニー=ソシャニーを作りました


こちらです http://www.socianie.com


【なにこれ?】

かっこつけた言い方をすると、

「いっぱいエロ動画あるけど結局みんなどんなお宝動画で抜いてるの?という日常的な疑問への答え」

とかでしょうか。

実際どんな事が出来るサービスかというと、基本的には、はてなブックマークのようにエロいページをブックマークする(その時に、コメントを付記することができる)というものです。

サイト内の他のユーザーフォローすることができ、TwitterのようにTimelineのようなものがあってそこにフォローしている人がブックマークしたページが表示されます(そのページが、xvideos,fc2などの有名サイトならば埋め込みプレーヤーですぐ再生出来ます。)

まりフォローしてる人の最新お気に入りエロ動画がチェックできます

ブックマークされたページはそれぞれが固有のページを持っており、タグを付ける事ができます

ユーザーブックマークしたもの動画一覧で横断的に見ることができ、並び替え・検索などが出来ます

ブックマーク数で今日ランキング今週のランキングなどが見れます

あと、累計ブックマーク数によってユーザーランクが上がったりします。

TwitterOAuth認証ログインが出来ますTwitterツイート投稿などはしません。また、サイト内の名前アイコンTwitterのものを流用するかどうかも自分で決められます。)



他のエロサイトとの違いは、3つあると思っています

ソーシャル機能。他にも世の中に色々素晴らしいエロサイトがありますがそれらはソーシャル機能を持つものが少ない。

②上記の話とちょっと被ってますが、他のサイトは基本コンテンツ自体を自動クローリングするけれどソシャニーはそこをユーザー自身に委譲しているため、集まってくる動画の質はそれに比べて上がるんじゃないかというのと、

エロサイトありがちな出来るだけごちゃっと感を無く広告も無しでTwitter bootstrap使って小綺麗な感じ


作成後記】

Webサービス作るならRailsかな楽で便利らしいしというざっくりとしたイメージからRailsで作り始めましたが、

ネット情報入門書に取り組んでもサンプルと同じモノは作れても実際自分が作りたいモノになると、で、どうやるの?となりなかなか進みませんでした。

Railsは色々と勝手によろしくやってくれる機能が多すぎて実際何が起きてんの?というのがわかりづらいというのが第一印象でした。

色々試行錯誤した結果、一番参考になったのはRails tutorial( http://ruby.railstutorial.org/ruby-on-rails-tutorial-book )でした。

英語ですがバージョンは新しいしBootstrapの使い方もわかるしサンプルがTwitterクローンサービスを作ろうというなかなかおもしろものなので途中で飽きること無く取り組めました。

何かを学ぶ時は、モチベーションが続く形の学び方が一番いいと思いました。

僕はエロ動画が大好きなので、エロサイトというのもモチベーションの1つです(ただ、作業中に脱線して気づいたらキーボードではなく下半身に手が伸びているという事もありました。)

また、上記のチュートリアルテスト駆動開発なのでSpecテストをモリモリ書いているのですが、とりあえずはテストに関しては何をやってるのかざっと眺める程度で精読しませんでした。

まずは全体像を把握して何が必要か把握したかたからです。結果的に最後までやりきれたので良かったと思います



あとは、Rails固有の知識ではなくWebサービス全般の知識で足りないな、と思ったときネット上や本屋立ち読みで済ましました。

ネットで細切れにお勉強している場合本屋で体系的にまとまっている本をざっと読むと意外に抜けてる知識が保管されたり脳内インデックスが作れるのでいいと思いました。


バージョン管理gitを使いました。

理由はみんなが良い良いというので乗っておくかという安易なものです。

実際のところgitの良い所を使い倒せているのかというと全くそんな事ないですね。

せいぜいstash位でしょうか。あとbisectとか。


リポジトリ最初DropBoxに作ってたのですが、途中からBitbucketを使いました。

GitHubを使わなかった理由はBitbucketプライベートリポジトリ無料で持てるからです。

また、恥ずかしがり屋なのでGithubで公開は敷居が高いと感じたからです。

初のRailsプロジェクトというのもありソースがイケてないので恥ずかしいのです。

いつかイケメンコードGithubで公開してオレツエーしたいものです。


サーバーエロOKのところを探すのがなかなか難しく結局海外VPSを使いました。

Linodeというところですが、他との違いを挙げるとiPhoneアプリ経由で再起動などが出来たりします。あまりこの機能使ってないですが。

OSベタCentOSです。

構成はpassenger+apacheで、DBSQLite特にLBなどはないです。

諸々構築後に人気が出た時困らないように負荷分散のお勉強なんぞもやりかけましたがまずは不要かなということで辞めました。

ちなみにサーバーがUS西海岸なのでSSHで作業するとエディタちょっともっさりすることがありました。


プロジェクト管理は、会社でも使ってるのでRedmineかなと思ったのですがどうせ一人だしRedmineのUIきじゃないのでTrello( https://trello.com/ )を使いました。

TODO,Doing,Done,Bug,Suspendのリストを作ってやること忘れないように管理しました。

ふと出先で思いついた機能とかをiPhoneでスイっと追加など出来て便利でした。


正月に公開してお友達界隈で見てもらったんですが、よかれと思って作ったChrome拡張CSRFの対策が不備あり結局ブックマークレットにしたり、

ソースを見てもらったら設計RestfulじゃないとかControllerがfat過ぎるModelに押しこめなどアドバイスをもらえたり無知な僕には色々とお勉強になりました。

出来たものはしょぼいものですが、「Webサービス作ったことないコンプ」は少し解消出来た気がします。


以上、月19ドルも払ってるのにお友達だけで使われてるのも寂しいので増田でまとめついでに宣伝してみました。

叩かれるんでしょうか。怖いです。いじめないで。

2011-08-04

独学のプログラムエロ動画検索作ってみた

【お知らせ】2011/09/07

新しいエロWEBサービス作りました

http://d.hatena.ne.jp/uniqueweb/20110906/1315285545

プログラムは全く得意じゃないけれど最近よく見かけるようになったエロ動画検索自分でも作ってみたくて頑張ってみました。

近年、インターネットの普及によりエロ動画が自宅で簡単に見れるという素晴らしい時代になりました。

自分が若い頃はインターネットなんてものはなくエロビデオが主流でドキドキしながらレンタルビデオ屋に行き、可愛い女の子レジにいない隙を見計らってお兄さんにパッケージを伏せて空箱を渡しビデオを借りたものでした。

お兄さんにビデオ空箱を渡そうとした時に可愛い子がレジに戻ってきて焦って渡すのをやめてものすごく変な動きをしながらエロビコーナーに引き返していくなんてことも多々ありましたw

僕のお気に入りといえば「白石ひとみ」や「あいだもも」といった女優でよく借りてました。エロビを借りるということがものすごく恥ずかしい時代?年頃?でカモフラージュ普通ビデオと一緒に借りるということもしていました。それはそれは大変な思いでオナニーしてたんです

しかも、ビデオデッキ自体が貴重な時代でリビングに一台しかないのが当たり前でした。

深夜家族が寝静まってからヘッドフォンビデオを抱えリビングに行き暗がりの中でヘッドフォンテレビ差し込んでビデオ再生ボタンを期待に胸をふくらませながら押したものです。いいシーンを何回も見るためにビデオを巻き戻すんですが、ビデオを巻き戻すガチャガチャンという機械音で家族が起きてこないか?とかそれはそれはドキドキしながら見てました。一仕事終えたあとヘッドフォンを外したらジャックが外れていて大音量で喘ぎ声が響き渡っていたなんてこともありました。誰も起きてこなかったのは優しさなんでしょうか?w

さて、大分前置きが長くなりましたがエロというものものすごい技術発展させるものだと思いますエロのおかげで日本ビデオは普及しエロのおかげで日本インターネットものすごく普及したと言っていいと思います自分エロを通して技術の発展に貢献し自分自身のスキルアップになれば。という高い志を持ってこのサイト制作しました。決して自らのオナニーライフの充実と性癖を充たすため作ったわけではありません・・・

※2011.08.07 利用中のサーバーに障害が発生しているようで現在サーバー接続できない状態となっています・・・

※2011.08.07 23:53 復帰した模様です

サイト名:ヌキネーター

サイト名の由来は抜きネタからきています。抜きネーター、ヌキネーターという感じです

エロサイト制作工程日記にしてみたんで良かったら読んで下さい。そしてこのサイトを使って夜いろいろと励んでくれたら嬉しいです

では制作日記を書いていきたいと思います

サーバー選び

まず前提条件としてお金ほとんどかけたくない。アダルトサイトであるということから

サーバー選びからはいりました。

月の予算は5000円以内で考えていたのでけっこう探すのが大変でした。

日本アダルトサイトを許可している所はかなり限られていてさらにやりたいことができるのは

専用サーバーVPSしかないのでそうなると専用サーバー予算オーバーなので

VPSで探すことになり検索しまくってはじめに見つけたVPSはKAGOYAのVPSだったのですがβ版で募集を締め切っていて泣く泣く諦めました。

KAGOYAはかなり評判がいいみたいなので使ってみたかった。

次に見つけたのが○○○VPS海外サーバー日本語サポートがあり転送量の制限なしディスク容量100G

月1300円程度で借りれるということで初期設定費用に5000円程度かかりましたが借りてみました。

結果、ここは最悪でした。

  • 通信が頻繁に切れる
  • 激重
  • 借りて一ヶ月もしないうちにサービス継続が困難になりそうなのでIPが変わるとかメールがくる
  • まりに通信環境が悪すぎるとメールすると環境調査に協力してくれとメールがくる
  • 時間をかけて沢山の項目を調べて返信するも全く返答がない。

まりの酷さに1ヶ月で解約。

よく調べてみたら評判がものすごく悪い某VPS再販らしいです

お金時間をドブに捨てました・・・

もう失敗したくないと思い今度は比較的有名な海外サーバーLINODE

日本語サポートはないけれど抜群のサポートです

iptablesの設定でどうしてもうまくいかなくて拙い英語メールしてみたら

10分しないうちに返信がきました!

メールに書かれているとおりにコマンド入力したらあっさり解決。

素晴らしい!はじめからLINODEにすればよかった。

担当ブライアンはなぜか分からないけどとてもフレンドリーで親切に感じましたw

サーバー設定

LINODEは複数のディストリビューションから好きなものを選択できるので

とりあえず、64bit版を選択。

サーバー設定はほんとに面倒ですね。

一番面倒だけど重要だということで

SSH

Tripwire

chkrootkit

Clam AntiVirus

iptables

Apache

SSL

その他各種監視ツールの導入をしました。

ほんとに面倒でした。

データベース

はじめはmysqlストレージエンジンgroongaを使おうと思ったのです

初めに借りた最悪なVPSOSが32bit版だったのでgroongaがのソースが見つからずなぜかと思っていたら

どこかで見つけた記事で32bit版ではgroongaの性能を発揮しきれないということで32bit版の提供をやめてしまったらしいと書いてたので

じゃあ、sennaにするかということで最悪VPSsennaインストール

その後LINODEに変更したのでOSに64bit版を選択し念願のgroongaをインストール

しかし、調べてみると

などが理由で、結局sennaに戻して2度手間に・・・

プログラムもそれに合わせてその都度書き換えたので2度手間どころか3度手間4度手間でした・・・

senna導入はrpmでさくっといけるので簡単です

依存関係で少しはまりました。

まず

# rpm -qa | grep -i mysql

mysqlインストールされてたら削除

perl-DBIが必要なのでインストール

# yum install perl-DBI

そして下記の順番でインストール

rpm -ivh mecab-0.98-tritonn.1.0.12a.x86_64.rpm

rpm -ivh mecab-ipadic-2.7.0.20070801-tritonn.1.0.12a.x86_64.rpm

rpm -ivh senna-1.1.4-tritonn.1.0.12a.x86_64.rpm

rpm -ivh MySQL-shared-5.0.87-tritonn.1.0.12a.x86_64.rpm

rpm -ivh MySQL-client-5.0.87-tritonn.1.0.12a.x86_64.rpm

rpm -ivh MySQL-server-5.0.87-tritonn.1.0.12a.x86_64.rpm

rpm -ivh MySQL-devel-5.0.87-tritonn.1.0.12a.x86_64.rpm

my.cnfの設定をして終了

で肝心の全文検索ですデータ件数が5万件程度で少ないせいなのか、あいまい検索と比べてそれほど速さを実感できなかったです・・・

でもきっとすごく速くなったはず!

ちなみに「麻美ゆま おっぱい」で検索した場合、0.01 secで結果が返ってきました。

動画データ作成

さて、動画データ作成ですがいくつかのエロサイト制作記事でもあるようにスクレイピングということをします。

スクレイピングとはWEBサイトから特定の情報だけを取得することでネット上にあるサイトクロールして必要なデータだけを拾ってデータを作るといった感じでしょうか。

スクレイピングプログラム自体は以前にTidy関数を使って為替データ10分おきに取得するような物を作ったことがあったのでそれほど時間はかからいかなと思ったのですがけっこう時間かかりました。

スクレイピングにはTidyhtmlSQL、それにPHP Simple HTML DOM Parserを使いました。

下記のサイトを参考にしました。

phpによるスクレイピング処理入門

SQL みたいな文法で HTML を抽出する PHP のライブラリ

htmlSQLよりアツい!?jQueryみたいにセレクタでHTMLをparse(解析)する「PHP Simple HTML DOM Parser」

つの中で抜群に使えるのはPHP Simple HTML DOM Parserだったんです

ループ処理させるとメモリがすごいことになって今回のようなスクレイピングに向いてないみたいで

結局、htmlSQLTidyの両方を使ってスクレイピングしました。

両方ともPHP Simple HTML DOM Parserに比べるとうまくデータの取得ができないことが多く残念な感じなんですが他に選択肢がないので・・・

使える順に並べると

PHP Simple HTML DOM Parser

htmlSQL

Tidy

といった感じかもしれません。

おおまかにデータを取得して正規表現で特定データを抜き出しました。

広告との連携

広告にはDMMアフィリエイトを利用しています

http://affiliate.dmm.com/link.html

利用可能な物はパッケージ画像、サンプル画像(縮小)と書かれていたのでそれに従い画像を利用。

注記に※ユーザーレビュー引用いただけません。とだけ書かれているのでそれ以外は引用ありと判断して説明文とタイトルなどを利用

女優データジャンルデータDVDデータ、を紐付けたデータベース作成検索ワードに応じて検索結果に関連する商品を表示させるようにしました。

現状、売り上げ0で意味があるのか分かりませんけどw

負荷対策とか転送量とかDOS攻撃対策とか

エロサイトということで多少はチューニングとか設定とかしないとまずいかもと思い色々調べて設定しました。

やったこと

KeepAlive On

MaxKeepAliveRequests 60

KeepAliveTimeout 3

<IfModule prefork.c>
StartServers       7
MinSpareServers    5
MaxSpareServers   10
ServerLimit       30
MaxClients        30
MaxRequestsPerChild  4000
</IfModule>

様子見ということで2日間で設定してみました。

query_cache_limit=1M

query_cache_min_res_unit=4k

query_cache_size=16M

query_cache_type=1

とりあえずこんなところを設定してみましたが、爆発的なアクセスがあるわけでもないので有効なのか今のところ分かりません(-_-;)

Apache Benchでテストはしてみましたけど問題はない感じですが実際にチューニングができているか分かりません。

サイトデザイン

プログラマーとして有名なゆうすけさんのサイトgoogleを参考にしました。

シンプルで使いやすいようにしようと思いこのデザインしました。

3カラム中央可変となっています

クロスブラウザIE7、firefox3、chromeで行いました。

可変ものって作ったことなかったんですがけっこう面倒なんですね。

サイト機能

ブックマーク機能とメニューの折りたたみ機能検索結果の表示方法切替を作りました

まず、ブックマーク機能ですログインなしで気に入った動画ブックマークできるようにしました。

ブックマークに追加した動画ブックマークページで確認できるようにしました。

cookie機能を利用したらいけると思い色々調べてjquery.cookie.jsを利用。

保存したクッキー情報を呼び出してphpに渡して処理し指定要素にブックマーク一覧をloadメソッドで表示させるという感じです

$(function(){
$("#youso").load("xxx.php");
});

メニューの折りたたみ機能は人気AV女優AV女優別、人気タグなどをそのまま表示させるとずらっと長くなって邪魔だったのでつけました。

これには同じくjquery.cookie.jsを利用しました。

参考サイトhttp://blog.caraldo.net/2009/03/newjqqookiemenu.php

検索結果の表示方法切替にはZoomer Galleryを利用しました。

参考URLhttp://phpjavascriptroom.com/?t=ajax&p=jquery_plugin_zoom#a_zoomergallery

検索結果ページで表示される

[ここの画像]

××× の検索結果

44件中 1~10件目を表示

ここの画像の部分をクリックするとgoogleイメージ検索みたいに一覧でイメージ表示できるようにしてみました。

動画表示ページ

基本的に動画の埋め込みを許可しているサイトのみプレイヤー表示をしそれ以外は画像を表示し動画データリンクするようにしました。

埋め込み部分はあらかじめそれぞれのサイト対応したプレーヤー部分のコード記述しVIDEOIDの部分に置き換えるような形にしました。

XVIDEOSを例にすると

XVIDEOS場合かならず動画urlhttp://www.xvideos.com/videoXXXXXX/のようになりますのでXXXXXXの部分を

VIDEOID部分に置き換えるようにプログラムを組みました、

埋め込み部のソース

>||<object width="510" height="400" classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=8,0,0,0" ><param name="quality" value="high" /><param name="bgcolor" value="#000000" /><param name="allowScriptAccess" value="always" /><param name="movie" value="http://static.xvideos.com/swf/flv_player_site_v4.swf" /><param name="allowFullScreen" value="true" /><param name="flashvars" value="id_video=VIDEOID" /><embed src="http://static.xvideos.com/swf/flv_player_site_v4.swf" allowscriptaccess="always" width="510" height="400" menu="false" quality="high" bgcolor="#000000" allowfullscreen="true" flashvars="id_video=VIDEOID" type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/go/getflashplayer" /></object>
||<

その他の動画サイトURLの一部分のデータを使っているので同様の処理をしました。

まとめ

実際の作業は2、3週間ですが色々調べる時間が多くて制作に2ヶ月くらいかかりました。

自分エロ動画検索を作ってみて有名プログラマーさん達がいかに優秀なのか思い知らされました。

皆さん思いついて数日で作ってしまうのでびっくりです

全くWEBの知識がない人で4、5ヶ月ですごいの作っちゃう人とかもいるみたいですし世の中広いな~と思います

しかし、エロサイト作りで勉強になりますね~

大分、色んな知識を得ることができました。

これからプラグラム勉強しようと思う人はぜひエロサイトから入ってみて下さい。

きっと楽しいですよ!

そんなこんなで?頑張って作ってみたエロ動画検索、良かったら使ってみて下さい。

これで少しは技術の発展に役立てたでしょうか?w

アダルト動画検索ヌキネーター

P.S エロサイトを作っていてはじめは楽しくて興奮しながら作ってたのです最後の方はエロい物を見ても全く反応しなくなりましたw

  不能ではないんですけど・・・現在も性欲が著しく減退しております・・・

  そしてスーパーpre記法がうまういかないのはなぜ?はてな匿名ダイアリー投稿全然からない・・・

  そしてそしてプログラマーさんとかデザイナーさんとかエロい人とかお気軽にお声をおかけ下さい。

【お知らせ】2011/09/07

新しいエロWEBサービス作りました

http://d.hatena.ne.jp/uniqueweb/20110906/1315285545

2010-12-19

ヌケるWebサービスを作ったのでeHubインタビューズっぽく宣伝してみる

あなたウェブアプリケーション/サービスは何ですか?

エロ注意】eroino http://eroino.net/

eroinoは毎日更新される大量のアダルト動画を、AV女優キーワードで分類して表示したり、お気に入りリストクリップできるサイトです現在動画数は、約28万件。

このプロジェクトを始めた理由は?

製作にかかった時間は?また、本業がありますか?

チームの規模はどれくらいですか?また、あなたの素性および経歴は?

現在使用しているインフラ技術は何ですか?

技術的な特徴があれば、紹介してください。

お気に入りリスト

開発の際に気を付けたことはありますか?

データの取得元、動画投稿サイトに迷惑をかけない」

プロジェクトは次の半年でどこへ向かうと思いますか?

アクセス増への対策」
広告
「機能追加」
  • まったくの白紙です。まずは安定稼働。

自分Webサービスを作りたいと思っている人に向けて何かありますか?

利用者に向けて何かありますか?

  • 自分では、かなり実用的だと思っているのですが、実際の所、どうなんでしょう。使ってみて、ダメ出しでも何でも良いので、感想を聞かせてもらえると嬉しいです

元ネタ

自分WEBサービスを作りたいと思っている人へ

http://anond.hatelabo.jp/20101203150748

eHub Interviews

http://emilychang.com/ehub/app/category/ehub-interviews/

eHub インタビューズ - Last.fm翻訳

http://d.hatena.ne.jp/brazil/20051102/1130901002

2010-12-13

[][][][][][][]

Heroku | Ruby Cloud Platform as a Service

http://heroku.com/

Amazon Elastic Compute Cloud (Amazon EC2)

http://aws.amazon.com/jp/ec2/

Virtual Dedicated Servers - Highly Configurable Plans Low Prices

http://www.godaddy.com/hosting/virtual-dedicated-servers.aspx

Linode - Xen VPS Hosting

http://www.linode.com/

Slicehost - VPS Hosting

http://www.slicehost.com/

Dedicated Server, Managed Hosting, Web Hosting by Rackspace Hosting

http://www.rackspace.com/index.php

SoftLayer® Technologies - About CloudLayer

http://www.softlayer.com/cloudlayer/

BULK SERVER|全プラン初期費用0円 最低利用期間1ヶ月 月額費用5,800円からの専用サーバAtomプラン

http://bulkserver.jp/service/atom

専用サーバーレンタル|即席サーバー - プラン案内 - サービス - 専用サーバレンタルならメガファクトリ

http://www.megafactory.com/html_service/s_sokuseki.htm

【基本構成】ライトプラン : マイティサーバーの専用サーバー

http://www.mtsv.jp/server/light/

専用サーバーヘリオスアルファ 特徴・料金|専用サーバーVPSのSaaSes

http://www.saases.jp/hosting/hos_001.html

さくらVPSVPS(仮想専用サーバ)はさくらインターネット

http://vps.sakura.ad.jp

http://server.sakura.ad.jp/dedicated/index.html

クラウドならニフティパブリックコンピューティングサービス

http://cloud.nifty.com/

IIJ クラウド(クラウドコンピューティング)サービス - IIJ GIO

http://www.iij.ad.jp/GIO/

共用サーバーVPS)|専用サーバーVPSのSaaSes

http://www.saases.jp/vps/index.html

ゴヤクラウド/VPS|カゴヤクラウド

http://www.kagoya.jp/cloud/vps/

prgmr http://prgmr.com/xen/

RapidXen http://www.rapidxen.net/

RapidKVM http://www.rapidkvm.net/

Arpnetworks http://www.arpnetworks.com/vps

Quickweb http://quickweb.co.nz/

NordicVPS http://nordicvps.com/

Thrust::VPS http://www.thrustvps.com/

Curlhost http://www.curlhost.com/

BudgetVM http://www.budgetvm.com/

neosurge http://www.neosurge.com/

NFOservers http://www.nfoservers.com/order-virtual-dedicated-server.php

EliteDataHosting http://www.elitedatahosting.com/vps.html

PhotonVPS http://www.photonvps.com/

http://www.webhostingtalk.com/

http://hibari.2ch.net/hosting/

2008-09-15

[][][][][][][]Slicehost入門

Slicehost


Slicehost VPS Hosting is now Rackspace Cloud Servers hosting

Slicehost Article Repository - VPS setup, servers, Ruby on Rails, Django, PHP, DNS, Slicemanager and more

Slicehost Articles: IP failover - High Availability explained

All requests for the website come to the front end Slice.

That Slice then proxies the request to larger Slices running in the backend of the network.

Slicehost Articles: IP failover - Slice setup and installing Heartbeat

sudo aptitude install heartbeat

sudo apt-get install ubuntu-xen-server

sudo apt-get install dnsmasq

wiki [Slicehost]

Monitoring Ubuntu Services Using Monit | Ubuntu Geek

$ sudo apt-get update

$ sudo apt-get upgrade

$ sudo tasksel

$ sudo apt-get install build-essential


google:Slicehost Ubuntu

Slicehost Articles: Ubuntu Hardy setup - page 1

Slicehost Articles: Ubuntu Hardy setup - page 2

Automatic Rails on Ubuntu 8.04 LTS « Enjoying Rails

joerichsen's gist: 16225 — Gist

Setting up Ubuntu Jaunty for Ruby and Rails development | Joe Ocampo's Blog

5-minutes to Rails // Slicehost VPS Hosting is now Rackspace Cloud Servers hosting

slicehostでRails2.2.2を動かすまで - なんとなく日記

Slicehost Articles: Ubuntu Hardy - Ruby on Rails

Slicehost Articles: Ubuntu Gutsy - Django installation

UbuntuにLAMPサーバを手早くインストールする方法 - builder

LAMPLinuxApacheMySQLPHPサーバを手早くインストールする最も簡単な方法

google:Slicehost CentOS

cat /etc/redhat-release

Slicehost Articles: CentOS setup - page 1

Slicehost Articles: CentOS setup - page 2

CentOSのPHPにはマルチバイト対応入ってませんのであとから入れましょう (技術メモ)

タグ「slicehost」を含む新着エントリー - はてなブックマーク

naotaka blog » Blog Archive » Slicehostに申し込み

slicehostでUbuntu8.04の設定1 初期設定 - delab

Slicehost : Tag Archives - delab

ホスティングサービス Slicehost のドキュメントがすばらしい : 僕は発展途上技術者

SlicehostへのRedmine導入手順(Ubuntu Gutsy)

rootでsshできないように設定する

つくるぶガイドブログ: 失敗しない Rails が動かせるホスティングサービス選びと環境構築

具体的にどこがおすすめかという質問を受けた場合、共用サーバーならば海外Slicehost、専用サーバーならさくらインターネット

Slicehost には、OS を一度まっさらに戻し、

OSの種類やバージョン

用意されているものの中から

簡単に選択し直すことができる機能管理メニューに付いています

naotaka blog » Blog Archive » Slicehostに申し込み

インストールも、やはり2分以内で完了しまから

好きなだけインストールし直しましょう。

なげやり日記: Slicehost

[Rebuild] でOSを簡単にリストアできるのも、試行錯誤のためには便利だったりします。

Slicehost に移行しました - milk1000cc

Web 管理画面で、OS 再起動・再インストール、コンソール操作DNS 設定などができます

あと、プラス $5 で毎日自動イメージごとバックアップ

バックアップ入れても月額 $25、

さくらと違って OS インストール直後は最小構成になっている、設定ミスってもすぐに OSインストールできる


共有サーバー

XREA.COM

CORESERVER.JP:コアサーバー

レンタルサーバはさくらインターネット | 「さくらのレンタルサーバ」「さくらのマネージドサーバ」

ポケットサーバー ★ 月額80円からのレンタルサーバー

格安レンタルサーバーならステップサーバー | 高機能で格安なレンタルサーバーTOP

レンタルサーバーNSF - 月額100円〜容量無制限可の格安レンタルサーバー

ロリポップ!レンタルサーバー - 月額105円~容量最大30GB 初期費用半額キャンペーン中!

チカッパ!レンタルサーバー - ご利用中のユーザー様へのご案内

レンタルサーバー「heteml」 - 大容量・高機能のレンタルサーバー

VPS

Slicehost VPS Hosting is now Rackspace Cloud Servers hosting Slicehost Login

Linode - Xen VPS Hosting Linode Login

Linode.comのVPSホスティングを契約してみた - m-kawato@hatena_diary

Webbynode Hosting - Host and Deploy Ruby on Rails, Django, Node.js, PHP and more

QuillHost - Shopping Cart

VPS Hosting � Virtual Private Server Hosting | DataRealm.com

The New York NOC - New York Colocation, Cloud, Dedicated Servers, and Virtual Private Servers at affordable pricing

Coupon codes, promotions and special offers - CheapVPS

VPS :: VPS Hosting :: VDS :: Virtual Private Servers :: Virtual Dedicated Servers :: Server Axis

RootBSD - FreeBSD and OpenBSD VPS Hosting - Welcome to RootBSD

ProVPS.com - Xen VPS Hosting

VPS仮想専用サーバーならCPI | Linux VPS

レンタルサーバーならVPSレンタルサービス|VPS stock


専用サーバー

激安の専用サーバ:ServerPronto なんと月額$29〜 | 海外サーバ.jp

サーバ本体無償提供、ホスティング向きハウジングサービスを月額7,780円で

デルタ1 - 専用サーバーの【ファーストサーバ】

専用サーバの料金と仕様 | 専用レンタルサーバ(ホスティング)のさくらインターネット

クララオンライン clara

Dedicated servers | Windows and Linux dedicated web servers

Google

Dedicated Servers, Self-Managed Dedicated Server, Dedicated Hosting at ServerPronto

MegaNetServe - Value Driven Dedicated Servers on Linux, Windows 2008, Windows 2003 & FreeBSD

Domain Names, Web Hosting and SSL Certificates - Go Daddy

Dedicated Servers, vSERVERs – SERVER4YOU

Web Hosting | Dedicated Hosting | Domain Registration |

海外の安い専用サーバプランをいろいろ並べて検討してみた - GIGAZINE

再度、レンタルサーバ(共有ではなく「専用」です)で、国内外を.. - 人力検索はてな

Website Hosting in the Yahoo! Directory

Google

サーバー購入

デル株式会社(Dell Japan)の公式サイト | Dell 日本

Dell PowerEdge タワーサーバ

日本HP へようこそ

HP-ProLiant-ML115 G5まとめwiki - トップページ

各メーカーの最安サーバを比較検討してみた - GIGAZINE

server

バックエンドアーキテクチャーのおかげで、2テラバイトの画像を、$1000のLinuxサーバー1台で賄うことができる。だから、年間わずか20万ドル程度の設備投資で、現在サーバー500台を保有している。

ドメイン登録 - VALUE DOMAIN:バリュードメイン

Whois

Domain Names, Web Hosting and SSL Certificates - Go Daddy

サイトチェック - ドメインチェック

有名なウェブサイトの文字コード一覧

JPIXNAGOYA

Amazon S3をWindowsにマウントできるJungle Disk Kawanet Tech Blog/ウェブリブログ

Online storage and backup | Secure file sharing | Unlimited online storage | Jungle Disk

Alexa Top 500 Global Sites

Amazon.co.jp: 現場が教えるホスティングサービスの勘所―立ち上げから運用管理までのノウハウ (NEサポートシリーズ): 合阪 省: 本

Amazon.co.jp: レンタルサーバをはじめよう!―ホスティングのためのサーバ構築術: 斎藤 高洋: 本

Heroku | Cloud Application Platform

 
ログイン ユーザー登録
ようこそ ゲスト さん