Novice Access Guide

Access process of fan service platform

 97580f43jw1eu2giorp4aj20hi01omx2.jpg

Access process of fan service platform development mode

 97580f43jw1eu2gippjcuj20d001hwec.jpg

Step 1: Application message interface

For media, enterprises and personal authentication accounts, click "Management Center" on the profile page of the account, and then click "Advanced Functions" in the "Fans Service" menu, where you can choose to open "Edit Mode" or "Development Mode".


When the "development mode" is selected, you need to fill in the URL and APPKEY, where the URL is the interface URL used by the developer to receive data from the microblog message server. APPKEY designates and authorizes developers who want to develop services for Weibo authenticated users to apply KEY. The APP Secret corresponding to the APPKEY will be used to generate a signature (the signature will be compared with the signature contained in the interface URL to verify the security of the request).


Step 2: Verify the URL validity

When developers use the event push service for the first time, they need to establish the first connection with the microblog server through a verification first, specifically:


After the developer submits the information, the microblog message server will send a GET request to the filled URL. The GET request carries four parameters:


Verification parameter field Field Type Field Description
signature string Weibo encryption signature, signature combines the developer's appsecret, timestamp parameter and nonce parameter in the request
timestamp string time stamp
nonce string random number
echostr string Random string


After receiving the request, the developer first verifies the authenticity of the GET request through the encrypted signature parameter. If the GET request is confirmed to come from the microblog server, the first connection can be successfully established by returning the echo parameter content as is, otherwise the connection fails.


The encryption rules for the signature parameter are:

After dictionary sorting the developer's appsecret, timestamp and nonce parameters, splice the three parameter strings into one string for sha1 encryption Verification parameters:

appsercret=xyz123xyz        timestamp=1397022061823        nonce=57155157

Encryption result:

The concatenated string is 139702206182357155157xyz123xyz

The result of sha1 signature is: 90e4c22c90a58f26526c2dd5b6c56c8822edeaa1

An example of a request to verify the validity of a url is: http://yoururl?nonce=57155157&timestamp=1397022061823&echostr=dnPdpTZz85&signature=90e4c22c90a58f26526c2dd5b6c56c8822edeaa1

At this time, if the value returned is the echostr value (dnPdpTZz85 in this example), it passes the url verification.


PHP code example:

 function checkSignature() { $signature = $_GET["signature"]; $timestamp = $_GET["timestamp"]; $nonce = $_GET["nonce"]; 	 $appsecret= appsecret;  // Developer's appsecret $tmpArr = array($appsecret, $timestamp, $nonce); sort($tmpArr, SORT_STRING); $tmpStr = implode( $tmpArr ); $tmpStr = sha1( $tmpStr ); if( $tmpStr == $signature ){ return true; }else{ return false; } }


PHP sample code download: download

Download java sample code: download

 

Step 3: become a developer and obtain access_token

After the URL validity is verified successfully, the access takes effect and the user becomes a developer. After that, every time the user sends a message to the Weibo authentication account or generates a custom menu click event, the response URL will be pushed.

In addition, after the first connection is established, the three parameters of signature, timestamp, and nonce will also be brought with each subsequent Weibo event push. Developers can still judge the authenticity of this message by verifying the signature. The verification method is the same as that of the first connection. In addition, please note that the development interface of the pink server platform only supports 80 interfaces.


After the URL is verified successfully, the powder server platform will automatically return an access_token, as shown in the following figure:

Used by developers receive messages and Send passive message The function does not need access_token, but there are many other interfaces of the powder server development mode, such as Send passive response message , the access_token parameter is required as a voucher when calling;


For more information about access_token, see:

Attachment: Long connection mode

In addition to the above Push access mode In addition, we also provide additional Long connection access mode This mode has the same function except for different access technologies.


The feature of the long connection mode is that the third party developer actively establishes a connection request. After the long connection is established, new messages and events will be returned to the third party developer in real time, instead of passively waiting for the GET request of the microblog message server. The third party developer has more control autonomy, but the corresponding development difficulty will also be greater.


For those who prefer the long connection mode, please refer to the following documents for access:




Document update time: July 14th, 2015