OAuth Part I: Overview の訳

http://hueniverse.com/2007/10/beginners-guide-to-oauth-part-i-overview/
の訳

機械翻訳(重要でないところ)と見直し部の混在。

--> あいかわらず機械翻訳は、間違いが多い。
and がつながるときは、壊滅である。まあしかし、早く単語の訳がでることはいい。

-----------------------------------------------

Beginner’s Guide to OAuth   Part I: Overview
OAuthへのビギナーガイド

By Eran Hammer-Lahav
Thursday October 4, 2007 2007-10-04

This post contains obsolete or incorrect information. For a more recent update, please visit The Authoritative Guide to OAuth 1.0
With OAuth reaching its final draft (OAuth Core 1.0 Draft 4) last night, it is time for those of you new to the protocol to dive in and learn what it is all about. I have written in a previous post about the history behind OAuth, its use cases, and when it is (or isn’t) applicable. People seems to like my metaphor of a valet key, which John Panzer rephrased “OAuth: Your valet key for the Web”.

この投稿は時代遅れの、または、不正確な情報を含んでいます。 より最近のアップデートには、OAuth1.0へのAuthoritativeガイドを訪問してください。
OAuthが昨夜最終的な草稿(OAuth Core1.0Draft4)に達しています。
だからもう時間です。あなたが新しくプロトコルへ飛び込んで、それが何に関するすべてであるかを学べます。
私はOAuthの背景の歴史を、前の投稿に書きました。その使用の例、それがどこで適切でありまたどこでそうではないかも書きました。

人びとは、ジョン Panzerはキーを言い直してくれた「OAuth:ウェブにあなたの、召使キー。」という、私の召使キーの比喩が好きであるように思えます。

Beginner’s Guide to OAuth   Part I

Introduction

This guide is intended for a technical audience with focus on implementation. I dedicate one section to the end-user perspective which is something I expect many others will address with mockups, user interface designs, best practices guides, and of course working services. To make the most out of this guide, keep the specification handy as I will be referencing it, walking you through the spec and adding color where needed. This guide does not replace the specification nor can it be used alone for implementation as it is incomplete.

(excite機械翻訳)
このガイドは実現での焦点との技術聴衆のために意図します。 私は多くの他のものが実物大の模型、ユーザーインターフェース設計、最も良い習慣で演説する私がガイド、およびもちろん働くサービスを予想する何かであるエンドユーザ見解に1つのセクションを捧げます。 私がそれに参照をつけるとき、このガイドから大部分作るために、仕様を手元に置いてください、必要であるところで仕様を通してあなたを歩いて、色を加えて。 このガイドは仕様を置き換えません、そして、不完全であるので、実現に単独でそれは使用できません。
End-User Benefits

OAuth allows you to share your private resources (photos, videos, contact list, bank accounts) stored on one site with another site without having to hand out your username and password. There are many reasons why one should not share their private credentials. Giving your email account password to a social network  site so they can look up your friends is the same thing as going to dinner and giving your ATM card and PIN code to the waiter when it’s time to pay. Any restaurant asking for your PIN code will go out of business, but when it comes to the web, users put themselves at risk sharing the same private information. OAuth to the rescue.

(excite機械翻訳)

OAuthはあなたに1つのサイトに別のサイトであなたのユーザ名とパスワードを与える必要はなく格納された私用資源(写真(ビデオ)はリストに連絡します、銀行口座)を共有させます。 それらの個人的な信任状を共有するべきでない多くの理由があります。 彼らがあなたの友人を訪ねることができるようにあなたのメールアカウントパスワードをソーシャルネットワークサイトに与えるのは、もう支払うべき時間であるとき、夕食に行って、あなたの銀行のキャッシュカードと暗証番号コードを給仕に与えるのと同じことです。 あなたのPINコードを求めるどんなレストランも、店じまいするでしょうが、ウェブのこととなると、ユーザは、危険な状態に同じ個人情報を共有しながら、自分たちを置きます。 救出へのOAuth。

Both the valet key and ATM cards are good metaphors for OAuth from a user perspective. Instead of giving your ATM card and PIN code, the card can double as a credit card with a signature authorization. Just like your username and password provide full access to your resources, your ATM card and PIN code provide you with great control over your bank accounts much more than just charging goods. But when you replace the PIN code with your signature, the card becomes very limited and can only be used for limited access.

(excite機械翻訳)
召使キーと銀行のキャッシュカードの両方が利用者の展望からのOAuthに、良い比喩です。 あなたの銀行のキャッシュカードと暗証番号コードを与えることの代わりに、署名承認でカードをクレジットカードの役目も兼ねることができます。あなたのユーザ名とパスワードがまさしくあなたのリソースへの完全なアクセスを提供するように、あなたの銀行のキャッシュカードとPINコードはあなたの銀行口座のかなりのコントロールをあなたにただ商品を請求するよりはるかに提供します。 しかし、あなたが暗証番号コードを署名に取り替えると、カードは、非常に制限されるようになって、限られたアクセサリーに使用できるだけです。

Users don’t care about protocols and standards they care about better experience with enhanced privacy and security. This is exactly what OAuth sets to achieve. With web services on the rise, people expect their services to work together in order to accomplish something new. Instead of using a single site for all their online needs, users use one site for their photos, another for videos, another for email, and so on. No one site can do everything better. In order to enable this kind of integration, sites need to access the user resources from other sites, and these are often protected (private family photos, work documents, bank records). They need a key to get in.

(excite機械翻訳)
ユーザはプロトコルを心配しません、そして、彼らがほとんどより良い経験について気にかける規格はプライバシーとセキュリティを高めました。 これは、まさにOAuthが達成するためにセットすることです。 ウェブサービスが上昇中で、人々は、何か新しいものを達成するために彼らのサービスが一緒に働くと予想します。 彼らのすべてのオンラインニーズにただ一つのサイトを使用することの代わりに、ユーザは彼らのフォト、ビデオのための別のもの、メールのための別のものなどに1つのサイトを使用します。 いいえ1、サイトはすべてを良くすることができます。 この種類の統合を可能にするために、サイトは、他のサイトからユーザリソースにアクセスする必要があります、そして、これらはしばしば保護されます(個人的な家族写真(作業文書)は記録を盛り土します)。 彼らは、入るためにキーを必要とします。

The key used by users is usually a combination of username and password. This can be an OpenID or any other login credential. But this key is too powerful and unrestricted to share around. It also cannot be unshared once handed out except for changing it which will void access to every site, not just the one the user intends to block. OAuth addresses that by allowing users to hand out tokens instead. Each token grants access to a specific site (a video editing site) for specific resources (just videos from last weekend) and for a defined duration (the next 2 hours).

(excite機械翻訳)
通常、ユーザによって使用されたキーは、ユーザ名とパスワードの組み合わせです。 これは、OpenIDかいかなる他のログイン信任状であるかもしれません。 しかし、このキーは、共有できないくらい強力であって、無制限です。 また、それを変える以外に、いったん与えると、それも分配されていないはずがありません(ユーザが妨げるつもりであるものだけではなく、あらゆるサイトへのアクセスを欠如させるでしょう)。 ユーザが代わりに象徴を与えるのを許容することによって、OAuthはそれを記述します。 各象徴は特定のリソース(先週末からのまさしくビデオ)と(次の2時間)定義された持続時間の間、特殊部位(ビデオ編集部位)へのアクセスを承諾します。

Unlike OpenID where users must do something first get an OpenID identity they can use to sign-into sites. OAuth is completely transparent to the users. In many cases (if done right), the end-user will not know anything about OAuth, what it is or how it works. The user experience will be specific to the implementation of both the site requesting access and the one storing the resources, and adjusted to the device being used (web browser, mobile phone, PDA, set-top box).

ユーザが最初に何かをしなければならないOpenIDと異なって、サイトにサインインするために彼らが使用できるOpenIDのアイデンティティを得てください、。
ユーザにとって、OAuthは完全に透明です。
多くの場合(正しくするなら)、エンドユーザは、OAuthについて、それが何であるかまたはどう働くかに関して、何も知らないでしょう。
ユーザー・エクスペリエンスは、サイト要求アクセスとリソースを格納アクセスの両方の実現に特定になるでしょう。そして、使用される装置(ウェブブラウザ、携帯電話、PDA、セットトップボックス)に対して調整されるしょう。

A typical example offered by the spec (Appendix A) is when a user wants to print a photo stored on another site. The interaction goes something like this: the user signs into the printer website and place an order for prints. The printer website asks which photos to print and the user chooses the name of the site where her photos are stored (from the list of sites supported by the printer). The printer website sends the user to the photo site to grant access. At the photo site the user signs into her account and is asked if she really wants to share her photos with the printer. If she agrees, she is sent back to the printer site which can now access the photos. At no point did the user share her username and password with the printer site.

仕様(付録A)によって提供された典型的な例は、ユーザが別のサイトに保存されたフォトを印刷したがっている時です。 相互作用はこのように進んでいます:
ユーザはプリンタウェブサイトにサインインして印刷の注文を置きます。
プリンタウェブサイトは、どのフォトを印刷したらよいかを尋ねます、
そして、ユーザはサイトの名前を選びます。そこでは、彼女のフォトが保存されています
(プリンタによってサポートされたサイトのリストから) 。
プリンタウェブサイトで、アクセス権を与えるためにユーザをフォトサイトに送ります。
フォトサイトでは、ユーザは、彼女のアカウントにサインインして、彼女が本当にプリンタとフォトを共有したがっているかどうか尋ねられます。 彼女が同意するなら、彼女は現在フォトにアクセスできるプリンタサイトに送り返されます。
どんなポイントでも、ユーザは彼女のユーザ名とパスワードをプリンタサイトと共有しません。

Scope

What is publicly known as ‘OAuth’ is really the ‘OAuth Core 1.0’ specification. The Core designation is used to stress that this is the skeleton other extensions and protocols can build upon. OAuth Core 1.0 does NOT by itself provide many desired features such as automated discovery of endpoints, language support, support for XML-RPC and SOAP, standard definition of resource access, OpenID integration, a full range of signing algorithms, and many other great ideas posted to the OAuth group.

(excite機械翻訳)
‘OAuth'として公的に知られていることは、本当に‘OAuth Core1.0'仕様です。 Core名称は、これが他の拡大とプロトコルが当てにすることができる骸骨であると強調するのに使用されます。 OAuth Core1.0自身は終点の自動化された発見や、言語サポートや、XML-RPCのサポートやSOAPなどの希望の多くの特徴を提供しません、リソースアクセスの標準定義、とOpenID統合、最大限の範囲の署名アルゴリズム、および他の多くのすばらしい考えがOAuthグループに投稿しました。

This was intentional and is viewed by the authors as a benefit. As the name implies, Core deals with the most fundamental aspects of the protocol:

(excite機械翻訳)
これは、意図的であり、利益として作者によって見なされます。 名前が含意するように、Coreはプロトコルの最も基本的な局面に対処します:

Establish a mechanism for exchanging a username and password for a token with defined rights (Section 6).
Provide tools to protect these tokens (Section 9).

(excite機械翻訳)
定義された権利(セクション6)でトークンのためのユーザ名とパスワードを交換するためにメカニズムを確立してください。
ツールを提供して、これらのトークン(セクション9)を保護してください。

It is important to understand that security and privacy are not guaranteed by the protocol. In fact, OAuth by itself provides no privacy at all and depends on other protocols to accomplish that (such as SSL). With that said, OAuth can be implemented in a very secure manner and the specification includes a good amount of security considerations to take into account when working with sensitive resources. Just like using passwords together with usernames to gain access, sites will use tokens together with secrets to access resources. And just like passwords, secrets must be protected.

(excite機械翻訳)
セキュリティとプライバシーがプロトコルによって保証されないのを理解するのは、重要です。 事実上、それ自体でOAuthは、それ(SSLなどの)を達成するためにプライバシーを全く提供しないで、他のプロトコルによります。 それが言われている状態で、非常に安全な方法でOAuthを実装することができます、そして、仕様は機密のリソースで働いているとき考慮に入れる相当量のセキュリティ問題を含んでいます。 まさしく、アクセスを得るのにユーザ名と共にパスワードを使用するように、サイトはリソースにアクセスするのに秘密と共にトークンを使用するでしょう。 そして、まさしくパスワードのように、秘密を保護しなければなりません。

Specification Structure
仕様構造

OAuth Core 1.0 includes 13 sections which are ordered in a way that allows a single pass through the spec without the need to go back and forth many times. If you want to dive right in, start with Appendix A, then read sections 3, 4.1, 6, 7, and 5.4. Read sections 5 and 9 when you are ready to implement.

(excite機械翻訳)
何回も前後に行かずに、OAuth Core1.0は仕様に単一パスの通ることを許す方法で注文される13のセクションを含んでいます。 右に飛び込みたいなら、Appendix Aから始まってください、そして、次に、セクション3、4.1、6、7、および5.4を読んでください。 道具に準備ができていたらセクション5と9を読んでください。

Section 1.   List of authors.
Section 2.   General notations used by the spec.
Section 3.   Definitions of important terms used throughout the spec. While most are simple to understand, it is important to read this section a couple of times as it sets the framework for the rest of the document.
Section 4.   Protocol preparations. Before using OAuth, sites must follow a few steps to prepare for the protocol. The spec does not specify how this is done but does provide guidelines as to what information should be documented and established before the first OAuth request is made.
Section 5.   Implementation details on formatting parameters and interaction with the HTTP protocol.
Section 6.   Defines the mechanism for exchanging user credentials with a token. It is the heart of the specification and describes the entire flow including user interaction.
Section 7.   Defines how tokens are actually used to access resources. This short section is where most of OAuth takes place.
Section 8.   technical details about creating nonce and timestamp values. Note that OAuth definition of timestamps does not necessarily means real time is used.
Section 9.   While section 6 covers the first goal of the protocol, to exchange user credentials for a token, this section defines tools to protect the token from abuse. The signature process provides a working prototype and support for future extensions.
Section 10.   Suggested HTTP response codes. OAuth Core leaves much open for individual implementations.
Appendix A.   A complete example for sections 4 to 9. This is a good place to start reading if you intend to implement OAuth. It lets you dig right into the actual requests and see how they work.
Appendix B.   Is an incomplete (as is true for most security papers) list of security considerations. It is absolutely critical that any OAuth implementer reads this thoroughly to understand the risks involved. Deciding on how to address this list is up to each implementation and depends on needs.
Section 11.   List of references and links to external documents.

(excite機械翻訳)
セクション1。 作者のリスト。
セクション2。 仕様によって使用される一般表記。
セクション3。 仕様中で使用される重要な用語の定義。 大部分は理解しているのが簡単ですが、ドキュメントの残りのためにフレームワークの用意をするとき、一度か二度このセクションを読むのは、重要です。
セクション4。 準備について議定書の中で述べてください。 OAuthを使用する前に、サイトは、プロトコルの用意をするために数ステップに従わなければなりません。 OAuthが要求する1番目が作られている前に、仕様は、これがどのように完了しているかを指定しませんが、どんな情報が記録されて、確立されるべきであるかに関してガイドラインを提供します。
セクション5。 形式パラメタに関する実現の詳細とHTTPとの相互作用は議定書を作ります。
セクション6。 ユーザ資格証明書をトークンと交換するためにメカニズムを定義します。 それは、仕様の心であり、ユーザ相互作用を含む全体の流れについて説明します。
セクション7。 トークンがリソースにアクセスするのに実際にどう使用されるかを定義します。 この短い部分は、OAuthの大部分が行われるところです。
一回だけを作成することに関するセクション8技術的詳細とタイムスタンプ値。 タイムスタンプの定義がするOAuthが、必ずリアルタイムが使用されていることを意味するというわけではないことに注意してください。
セクション9。 セクション6は、ユーザ資格証明書をトークンと交換するためにプロトコルの初ゴールをカバーしますが、このセクションは、乱用からトークンを保護するためにツールを定義します。 署名プロセスは将来の拡張の実用試作機とサポートを提供します。
セクション10。 HTTP応答コードを示しました。 OAuth Coreは多くの戸外を個々の実現に出ます。
セクション4?9のための付録のA.のA完全な例。 これは、あなたがOAuthを実装するつもりであるなら読み始める良い場所です。 それで、あなたは、丹念に実際の要求をまさしく調べて、それらがどう働いているかを見ることができます。
付録B.Is、セキュリティ問題の不完全な(ほとんどのセキュリティ書類には、そのままで本当の)リスト。 どんなOAuth implementerもかかわった危険を理解するためにこれを徹底的に読むのは、絶対に重要です。 このリストを扱う方法を決めるのは、各実現まであって、必要性によります。
セクション11。 参考文献一覧と外部のドキュメントへのリンク。

Definitions
定義

Section 3 contains definitions to fundamental protocol concepts referenced throughout the spec. Because understanding OAuth depends on these terms, they deserve some explanation:

(excite機械翻訳)
セクション3は仕様中で参照をつけられる基本的なプロトコル概念に定義を含みます。 OAuthを理解するのがこれらの諸条件でよるので、何らかの説明に値します:


Service Provider.   The Service Provider controls all aspects of the OAuth implementation. The Service Provider is the term used to describe the website or web-service where the restricted resources are located. It can be a photo sharing site where users keep albums, an online bank service, a microblogging site, or any other service where ‘user’s private stuff’ is kept. OAuth does not mandate that the Service Provider will also be the identity provider which means the Service Provider can use its own usernames and passwords to authenticate users, or use other systems such as OpenID.

(excite機械翻訳)
Service ProviderはOAuth実現の全面を制御します。 Service Providerは、制限されたリソースが位置している、ウェブサイトかWebサービスについて説明するのに使用される用語です。 ユーザがどこにアルバム、ネット銀行サービス、microbloggingサイト、またはサービスを、いかなる他のも保管するかは、‘ユーザの個人的なもの'が保たれるところの写真共有サイトであるかもしれません。 OAuthは、また、Service ProviderがアイデンティティプロバイダーになるのをService Providerがユーザを認証するのにそれ自身のユーザ名とパスワードを使用するか、またはOpenIDなどの他のシステムを使用できることを意味する強制しません。

User.   The user is why OAuth exists and without users, there is no need for OAuth. The users have ‘stuff’ they don’t want to make public on the Service Provider, but they do want to share it with another site. In OAuth, the protocol stops without manual interaction with the user at least once to receive permission to grant access.

(excite機械翻訳)
ユーザはOAuthが存在する理由です、そして、ユーザがいなければ、OAuthの必要は全くありません。 ユーザには、彼らがService Providerで公表したがっていない‘もの'がありますが、彼らは別のサイトとそれを共有したがっています。 OAuthでは、プロトコルは、アクセサリーを与える許可を受けるためにユーザとの手動の相互作用なしで少なくとも一度止まります。

Consumer.   This is a fancy name for an application trying to access the User’s resources. This can be a website, a desktop program, a mobile device, a set-top box, or anything else connected to the web. The Consumer is the one getting permission to access resources and the Consumer is where the useful part of OAuth happens. OAuth defines ‘Consumer Developer’ as the entity writing code to interact with the Service Provider. ‘Consumer Key’ and ‘Consumer Secret’ will be explained later.

(excite機械翻訳)
これはUserのリソースにアクセスしようとするアプリケーションのための高級名前です。 これは、ウェブに接続されたウェブサイト、デスクトッププログラム、モバイル機器、セットトップボックス、または他の何かであるかもしれません。 Consumerはリソースにアクセスする許可を得るものです、そして、Consumerは、OAuthの役に立つ部分が起こるところです。 OAuthはService Providerと対話するためにコードを書く実体と‘消費者Developer'を定義します。 ‘消費者Key'と‘消費者Secret'は後で説明されるでしょう。

Protected Resources. The ‘stuff’ OAuth protects and allow access to. This can be data (photos, documents, contacts), activities (posting blog item, transferring funds) or any URL with a need for access restrictions.
Tokens   are used instead of User credentials to access resources. A Token is generally a random string of letters and numbers (but not limited to) that is unique, hard to guess, and paired with a Secret to protect the Token from being abused. OAuth defines two different types of Tokens: Request and Access. This are explained later in greater details.

(excite機械翻訳)
‘もの'OAuthは、保護して、アクセスがそうするのを許容します。 これは、データ(フォト、ドキュメント、接触)、活動(基金を振り込んで、ブログ項目を掲示する)またはアクセス制限の必要性があるどんなURLであってもよいです。
トークンは、User資格証明書の代わりにリソースにアクセスするのに使用されます。 一般に、Tokenは、ユニークであって、推測しにくくて、乱用されるのからTokenを保護するためにSecretと対にされる手紙と数(他)の無作為のストリングです。 OAuthはTokensの2つの異なったタイプを定義します: 要求とアクセサリー これは後でよりすばらしい詳細に説明されます。

Continue to Beginner’s Guide to OAuth   Part II : Protocol Workflow ≫

"The last will keeping place" 英語版の検索順位

遺言預かり所の英語版
"The last will keeping place" でぴったり入れると
Google はさすがに、割と上位 10 位 以内に
好試力研究所の "The last will keeping place"
つまり英語版を検索で見つけてくれる。

がクリックしてみると、
おっとこれは自分が
入れた google-docsで作った問い合わせフォームではないか。
これ廃止の予定だったのに、、、

教訓かな

"The last will keeping place"
一ヶ月もすると流石に検索で出るようになってきた。
しかし、、、、ヒットが真芯でない。

どうすればいいかなあ。
ということで、 google-docsでいろいろ作り公開文書にする。
また、このプログ(googleのプログだから)にいろいろ書く
こうすると、検索エンジンも見つけやすいのかなあ。

OAuth http://oauth.net/ の訳

OAuth

http://oauth.net/
の訳
An open protocol to allow secure API authorization
in a simple and standard method from desktop and web applications.

安全な APIの認承を許可するオープン プロトコルです。
デスクトップとWebアプリケーションのシンプルかつ 標準的なメソッドです。

For Consumer developers...

消費者向け開発者のため...

If you're building...

もし開発中なら

desktop applications
dashboard widgets or gadgets
Javascript or browser-based apps
webpage widgets

デスクトップアプリケーション
ダッシュボードウィジェットまたはガジェット
Javascriptやブラウザベースのアプリケーション
ウェブページのウィジェット

OAuth is a simple way to publish and interact with protected data.
It's also a safer and more secure way for people to give you access.
We've kept it simple to save you time.

OAuthは保護されたデータを公開そして対話する簡単な方法です。
また、より安全な方法であり、人々があなたにアクセス権を与えることになる。
私たちは、あなたの時間を節約するために単純さを守ってきました。

For Service Provider developers...

サービスプロバイダの開発者のため..

If you're supporting...

あなたがサポートしている場合...

web applications
server-side APIs
mashups

Webアプリケーション
サーバー側のAPI
マッシュアップ

If you're storing protected data on your users' behalf, they shouldn't
be spreading their passwords around the web to get access to it.
Use OAuth to give your users access to their data
while protecting their account credentials.

もし、あなたがユーザーの利益に代わる保護されたデータを格納している場合は、
かれらは、それへのアクセスを得るためにウェブ上でかれらのパスワードを
広めてはならない。
OAuthの使用は、あなたのユーザーが、
かれらのアカウントの資格情報を保護しながら
かれらのデータへアクセスことを提供する。

まずは、ここまで。

遺言預かり所と遺言メールの違いは何ですか

「好試力研究所の遺言預かり所といわゆる遺言メールの違いは何ですか」
と疑問に思われる方も多いと思います。

決定的に違うのは、「遺言預かり所の安全性は、ほぼ完璧」
ということでしょうか。

いわゆる遺言メールは、遺言を平文のままサーバに送信します。
つまりサーバの管理者であれば、
あなたの遺言を読めてしまうのです。

遺言が読まれてしまうとまずいことが沢山出てきます。
だから遺言の預かりができる職業は、弁護士さんとか司法書士さんしか
許されていないのです。

もし、弁護士さんとか司法書士さん以外の普通の
ITのサーバの管理者が、あなたの遺言を読んでしまったら、
ITのサーバの管理者は、一般の人ですから
悪い誘惑に駆られるかもしれません。

また、その人がいい人でも良くない人がその人に狙いをつけて
あれこれ秘密を探るよう依頼してくることも考えられます。

これに対して、遺言預かり所の方式では、
あなたの遺言(パソコンのパスワードなどを含む)を
ブラウザの中(つまりパソコンやiPhoneの中)だけで
暗号化してしまいます。

遺言預かり所のサーバには、暗号化された遺言だけが
送信され保存されますから、
サーバの管理者でさえも、あなたの遺言がなんであるか
まったく判りません。

さらに慎重な方からは、
「では、本当にブラウザの中だけで暗号化していることを証明してくれ」
といわれます。
はい、これも簡単にできます。
ここからが、htmlやjavascriptのすばらしいところで、
暗号化していることの技術・仕組みつまりプログラムのソースコードが、
丸見えなんですね。
遺言預かり所、遺言を暗号化するところと暗号化した遺言をサーバへ送信するところ
のページに行き、ブラウザの右ボタンを押してページのソースを見る
ということをしてください。

そうすれば、丸見えで事実(本当にブラウザの中だけで暗号化している)がわかります。

-----------------------------------------------
あとの「好試力研究所の遺言預かり所といわゆる遺言メールの違い」
は、無償で利用できることでしょうか。

遺言預かり所について

遺言預かり所とはまた大げさな名前です。

とこで、パソコン、iPhoneや携帯電話は皆さんを

ご利用になっていると思います。

当然パスワードをかけてご利用されていると思いますが、

どうでしょうか。

(パスワードをかけておかないと、

 家族に勝手に使われてしまうことがありませんか。

 勝手に使われるとまずい場合がありますよね。)

では、パスワードをかけてしまうと、

このパスワードは大切な秘密ですから、

誰にも教えられません。

たとえ家族でも自分の身に何かあるまでは、

パスワードを教えられません。

もし、あなたの身に万が一のことがあると、

そのパソコンやiPhoneは、だれも使えなくなります。

#######################################

自分の身に万が一のことがあれば、

パスワードだけは最愛の家族に連絡したい。

#######################################

そいう願いを実現するためのサービスが

「遺言預かり所」です。

「遺言預かり所」のご利用は、無償です。(ビジネスの話は最後にて)

十分に時間と手間をかけて作りました。

秘密を守る安全性は、暗号技術を使い、

現代の技術水準では最高レベルに仕上げてあります。

あなたの秘密の遺言を、ブラウザだけで暗号化して

それから、暗号となった遺言文だけをサーバに保管します。

だから安全です。

定期的(3日に一度)にあなたに電子メールを送信します。

(この期間は自由に変更できます。)

あなたは、この電子メールに応答してください。

もしあなたの応答がないと、

問い合わせメールを予備のメルアドにも

送信して確認をとりつづけます。

確認を4回しても応答がないと、

あなたの身に万が一のことがあったと判断して

暗号となった遺言文をご家族へ送付します。

ご家族は、暗号となった遺言文を解読して、

あなたのパソコン、iPhoneや携帯電話の

パスワードを知ることができます。

暗号となった遺言文を解読の鍵は、どうするのという

質問があると思います。

回答は、

「この解読の鍵は、あなたから、ご家族に事前にお渡ししておく」

です。

その他の疑問は、ここをみてください。

https://www.majin-z.com/last-will-ja/faq_ja.html

----------------------------------------------------

ビジネスとして、どうするのかという興味をお持ちの方が

いると思います。

いずれ沢山の人がご利用されるはずのシステムなので

システム内に広告を出したりすることで

収益をあげるしかないと考えています。

弁護士さんや司法書士さんなど

遺言周りでビジネスをしている方が

お得意先お客様への特別サービスとして

月額500円程度で利用できるといいかなと考えたりもしています。

twitter と連携しようかな

好試力研究所の小さな成果を、世界の皆さんに伝えるには

どうしたらいいのだろうか。

twitter や facebook mixy などにサービスを統合させるといいかもしれない

と考える。

まず、twitter(自分の赤運度はshinx55)がいいかと考え調査開始

twitterの「設定」メニューの中に「外部アプリ」がある。

ここに「開発者の方へ こちら」というリンクがあるのでクリック

中を見てみる。

「ようこそ開発者のみなさん! Twitterアプリケーションプラットフォーム

・ベータ版へ。連携アプリケーションはまだ始まったばかりですが、

開発を手助けするいくつかの機能を公開しています。

今すぐにユーザの皆様をTwitterの世界につなげましょう!

ここでOAuthを使ったアプリケーションを登録することができます。

OAuthは新しい外部アプリケーションの認証システムです。

OAuthがどういったものか、開発者とユーザにとってどう助けに

なるのかはhttp://oauth.netを参照してください。

」

とある。

「新しいアプリケーションを追加 ≫」もある。

どうやら、

アプリケーション登録申請とかあるが、ユーザ認証を統合できる模様

である。

そうか、認証がtwitterまかせであれば、

自分はアプリに専念すればいいことになる。

これはいい。

ということで、「http://oauth.net」をさらに調査することにした。

php に SOAP をインストール

レンタル仮想サーバ CentOS の php に SOAP をインストール

これで、動けばありがたいのだが、、、。

[root@majin-z ~]# yum install php-soap

Loaded plugins: fastestmirror

Loading mirror speeds from cached hostfile

* addons: mirrors.versaweb.com

* base: mirrors.versaweb.com

* extras: mirror.its.uidaho.edu

* updates: mirror.hosef.org

addons | 951 B 00:00

base | 2.1 kB 00:00

extras | 2.1 kB 00:00

updates | 1.9 kB 00:00

Setting up Install Process

Resolving Dependencies

There are unfinished transactions remaining. You might consider running yum-complete-transaction first to finish them.

The program yum-complete-transaction is found in the yum-utils package.

--> Running transaction check

---> Package php-soap.i386 0:5.1.6-24.el5_4.5 set to be updated

--> Finished Dependency Resolution

Dependencies Resolved

===================================================================================================================

Package Arch Version Repository Size

===================================================================================================================

Installing:

php-soap i386 5.1.6-24.el5_4.5 updates 136 k

Transaction Summary

===================================================================================================================

Install 1 Package(s)

Update 0 Package(s)

Remove 0 Package(s)

Total download size: 136 k

Is this ok [y/N]: y

Downloading Packages:

php-soap-5.1.6-24.el5_4.5.i386.rpm | 136 kB 00:03

Running rpm_check_debug

Running Transaction Test

Finished Transaction Test

Transaction Test Succeeded

Running Transaction

Installing : php-soap 1/1

Installed:

php-soap.i386 0:5.1.6-24.el5_4.5

Complete!

[root@majin-z ~]#

[root@majin-z ~]# yum install libxml2

Loaded plugins: fastestmirror

Loading mirror speeds from cached hostfile

* addons: mirrors.versaweb.com

* base: mirrors.versaweb.com

* extras: mirror.its.uidaho.edu

* updates: mirror.hosef.org

addons | 951 B 00:00

base | 2.1 kB 00:00

extras | 2.1 kB 00:00

updates | 1.9 kB 00:00

Setting up Install Process

Resolving Dependencies

There are unfinished transactions remaining. You might consider running yum-complete-transaction first to finish them.

The program yum-complete-transaction is found in the yum-utils package.

--> Running transaction check

---> Package libxml2.i386 0:2.6.26-2.1.2.8 set to be updated

--> Finished Dependency Resolution

Dependencies Resolved

===================================================================================================================

Package Arch Version Repository Size

===================================================================================================================

Updating:

libxml2 i386 2.6.26-2.1.2.8 base 795 k

Transaction Summary

===================================================================================================================

Install 0 Package(s)

Update 1 Package(s)

Remove 0 Package(s)

Total size: 795 k

Is this ok [y/N]: y

Downloading Packages:

Running rpm_check_debug

Running Transaction Test

Finished Transaction Test

Transaction Test Succeeded

Running Transaction

Updating : libxml2 1/2

Cleanup : libxml2 2/2

Updated:

libxml2.i386 0:2.6.26-2.1.2.8

Complete!

[root@majin-z ~]# service httpd restart

Stopping httpd: [ OK ]

Starting httpd: [ OK ]

[root@majin-z ~]#