Novice Access Guide

Access process of fan service platform


Access process of fan service platform development mode


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 specifies and authorizes the microblog authenticated user to develop a service for the developer's application KEY, and the APP Secret corresponding to the APPKEY will be used as the generation signature (This 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 service 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 require access_ Token, but there are many other interfaces of the powder server development mode, such as Send passive response message , access is required when calling_ The token parameter is used as a voucher;

About access_ For more information about 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