Fix errors after change REST API to support self hosted version

[mesilov]

REST API go to Bitrix24 self hosted version (such wow)

1. The app can't tell your client_secret to the data server (portal/box)
2. The application can't trust the payment status received from the data server (portal/box)

To address these issues, the authorization server OAuth 2.0 is now separated from the server data (i.e., portal) and shall be made on an individual resource https://oauth.bitrix.info/

Obtaining and renewal of authorization
In existing queries should be in all the calls to /oauth/token at the portal to replace the address of the portal on https://oauth.bitrix.info/. As a bonus: you can (and should) be removed from the request scope - tokens will now always be issued for the full set of application permissions. The first step is sending the user to /oauth/authorize portal - remains unchanged, but in one of the next updates will be made the ability to send the user to https://oauth.bitrix.info/oauth/authorize/ there he chose the portal that he needs to log in.

In response, upon receiving the token, the additional fields appear:

array ( 'access_token' => 'ejruymyaqc4y6ctf4gs742bqokh1ca9j', 'expires_in' => 3600, 'scope' => 'im,log,user', 'domain' => 'sigurd.bitrix24.com', 'server_endpoint' => 'https://oauth.bitrix.info/rest/', 'client_endpoint' => 'https://sigurd.bitrix24.com/rest/', 'member_id' => 'a223c6b3710f85df22e9377d6c4f7553', 'refresh_token' => 'n2k23ubc07us4ppnwbwmyifojvuvl77f', 'ts' => 1463567261, )

Client_endpoint parameter contains the full url of the entry point to the REST on the portal, together with the Protocol and the path.
Server_endpoint parameter contains the full url to an entry point to REST on the authorization server. Yes, the authorization server also has its own REST API, but more on that below.

Requests to the REST with authorization for client_id+client_secret
After updating these requests to the portals to work longer. Introduced this feature was recently used poorly, and decided for her not to make a fuss.

Payment application status on the portal/box.
Previously, the app could update it, pulling the REST method /rest/app.info. You can now do the same thing, but using the REST API of the authorization server.

The application can make requests to the methods https://oauth.bitrix.info/rest/ using the authorization token as issued to any portal and authorization for client_id + client_secret. While two methods are available:

• /rest/app.info

When you call with a valid token issued by any portal/box, the response will contain data about the token (the application code and the expiry time) and installation information (version, status, resolution, address, member_id):

{
"result": {
"client_id": "local.573afbb2db36b4.30304560", 
"expires": "2016-05-18T14:29:42+02:00", 
"install": {
"installed": true, 
"member_id": "a223c6b3710f85df22e9377d6c4f7553", 
"scope": "disk,im", 
"status": "L", 
"uri": "http://b24.sigurd.bx", 
"version": "1"
}, 
 "scope": "app"
}
}

• /rest/app.stat

When you call with a valid token and client_id + client_secret the application can obtain the filtered list of units with their own versions and statuses.

{
"result": [
{
"CLIENT": "b24.sigurd.bx", 
"DATE_CHANGE": "2016-05-17T13:08:34+02:00", 
"DATE_FINISH": "", 
"DATE_INSTALL": "2016-05-17T13:08:34+02:00", 
"INSTALLED": true, 
"STATUS": "L", 
"VERSION": "1"
}
], 
"total": 1
}

Information on their payment status in the portal, obtained from any of these methods, the application may be trusted, unlike similar data portal.

[mesilov]

47d779e