Month: August 2010

August 23, 2010

Improvements to the OAuth 1.0a and 1.0 protocols…

The last post on Skiyo blog was posted about the HTML web page tutorial

Just use the example to give an example. But I didn’t elaborate on the protocol…

Today Skiyo will introduce the difference and improvement between 1.0a and 1.0.

The premise is that you have already seen the agreement. Have a simple understanding of the deal.

The improvements in 1.0a mainly include advanced HTML tutorial and the following:

1. 0auth_callback parameter is placed in the request Token. The callback parameter is no longer accepted in authorizing. At the same time, when the request Token returns the parameter, the oauth_callback_confirmed parameter is also added. The value must be true.

At 1.0, Skiyo team need to specify a callback address and coding for HTML tutorial. Skiyo Blog need to bring in the callback parameter when requesting authorize. Then use it for user authorization and return.

In 1.0a, the parameter of this oauth_callback becomes a mandatory parameter. And the address must be placed in the first request Request Token. Also as a parameter of base_string if the callback address of the third-party application does not exist or is otherwise impossible An application with a callback address (such as a desktop application). This parameter must be [oob] (the content in square brackets is case sensitive). If the server receives it, you need to add an oauth_callback_confirmed parameter. The value must be [true] (in the brackets).

2. After the authorization is over, increase the oauth_verifier parameter.

After the authorization is successful in 1.0, jump directly into the callback to obtain the Access Token operation.

In 1.0a, after the authorization is successful, the server will return a parameter named oauth_verifier. It is used as the necessary parameter to get the Access Token in the next step.

If the third-party application does not have a callback address, the server needs to display the oauth_verifier parameter and inform the user that it needs to authenticate to the third-party application manually. The service provider needs to ensure that the value is available on some individual devices (such as mobile phones) — manual input.

This parameter is not needed during future request API validation.

Ok. I know the difference is so much. If you have any difference, you can tell me to supplement it or read our HTML web page tutorial.

Also, the 1.0a protocol is now obsolete. Because OAuth already has a formal 1.0 protocol and has become the RFC5849 standard.

August 11, 2010

Deep understanding of HTML classes for beginners

HTML web page tutorial seems to have received too much attention from the industry since birth. Several large wall sites have promoted coding HTML for beginners.

Chatting in the group today. Someone asked me: In addition to Douban everyone Sina Weibo. Which one provides API?

Skiyo suddenly said it. Our team at Skiyo Blog feel a bit bleak for the domestic environment.

Far away. Let’s analyze OAuth today how to use it.

The reason for writing this article is that when I was learning the OAuth protocol. I found some articles that are from a document called [OAuth Development Documentation.docx].

More general.. and not easy to understand.

So Skiyo need to describe the OAuth protocol in my own words.

For a better explanation, let’s use the watercress as an example.

A user A has registered an account on Douban. After logging in, he can perform some actions, such as publishing an HTML tags tutorial and all kind of broadcast.

So good. Now there is a website B.. Skiyo team wants A to post a broadcast on my website.

But there is a problem. Website B is unreliable for User A. User A does not want to put his account password on Website B.

Also, Website B is also unreliable for Douban. Douban does not know whether Website B is a real user.

To solve this problem. These three people (Douban / User A / Website B) sat together and opened a small meeting.

The result of the meeting is the OAuth protocol.

This agreement seems a bit complicated for security. I will simply say the next step. I have some metaphors that are not appropriate. Just let everyone understand the steps.

There are three steps in the big steps.

Before these steps: Website B has to go to Douban to apply for a token 1 (oauth_consumer_key) and a key 1 (oauth_consumer_secret) (a lot of keys. This key is called key 1). It is two people to meet each other.. Then website B again visit Douban. Douban can know: Oh. Is this not B?

First step.

Website B took the key to talk to Douban. Hi brother. I came. Then Douban said: I only recognize the key does not recognize people. Pick up your token 1 (oauth_consumer_key) and key 1 (oauth_consumer_secret) I will identify .

At this time, the website B is wary and come out. After the watercress is verified, it says: Oh, yes. You are B. That’s good. I will give you another key 2 (oauth_token_secret) and token 2 (oauth_token).

Website B took it back.

The second step.

At this time, User A is about to participate. Website B holds the token 2 (oauth_token) and the key 2 (oauth_token_secret) with A to visit the watercress. At this time, the three people stand one. Douban first to verify that user A is not true.

Regarding action, user A needs to log in on Douban. If the verification is successful, Douban needs to ask user A.

Douban says: A, do you know that B? Do you let him move your things?

A said: I know him, he is my good brother. I am moving with something.

At this time, Douban will know. That’s good. That website B can add and delete things from me.

Also, Website B is still provided to Douban a back door. A agrees. Douban requires A user to take the key 2 to the back door to find the website B.

The third step.

If the above is still smooth. Website B will take the key 1 (oauth_consumer_secret) and the key 2 (oauth_token_secret) to visit the watercress.

After the Douban has verified again, it will give the website B a key 3 (oauth_token_secret) and a token 3 (oauth_token).

Although this name is oauth_token, here at Skiyo we call it oauth_access_token.

At this time for the user / Douban, Website B can be trusted.

If website B wants to modify the content of user A in the future, you need to take the key 1 (oauth_consumer_secret) and key 3 (oauth_token_secret) to find the watercress.

This is the end of the process.

The above steps are generally like this.. but some details are different — for example, signature encryption, etc.

This can be carefully understood from my code.

Skiyo Team can take the Douban API to test it.

Get the access_token. If you like to use the open source OAuth library, you can. We at Skiyo understand it for ourself. So we wrote one.

After getting the access_token. Every time you add, delete or change things, you need to sign the URL secret, etc.. Put it in the header.

When you request the API, for example, the URL to publish a broadcast API is http://api.douban.com/miniblog/saying

Every time you request. Douban must check this header.. See what is verified.

For example, when he looks at the header is Authorization: OAuth. Skiyo Blog know that it is OAuth authentication.

At this time he will check the necessary fields, such as oauth_consumer_key.

The rest of you can go to see the OAuth protocol to see my code.

Skiyo Team wrote a double test. You can try it.

You have to apply for an application first. Then modify the address in config.php: