You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
This repository has been archived by the owner on Nov 9, 2017. It is now read-only.bloomberg / blpapi-http Public archive
This issues is to understand how the Open API authorization service and system works. Section 6 of the BLP API Developers Guide discusses the //blp/apiauth service, but we need a better understanding how this works in practice.
This investigation encompasses setting up our own BPIPE installation and user management to properly test authorization.
The text was updated successfully, but these errors were encountered:
ericvw removed this from the Subscription Support milestone Feb 8, 2015 Contributor yupinghu commented Feb 9, 2015Whoops, forgot this was here. :)
The core part of authorization is the Identity object. It contains the authorization info and is passed into every BLPAPI request; the request will take into account what the Identity is entitled to and the response will reflect that (possibly will result in an error response if the Identity is not authorized properly for that request).
To correctly populate the Identity , you use Session::sendAuthorizationRequest . When this request completes successfully, the Identity object will have been altered to reflect this (and when used in future requests, will do the right thing). The Request object passed to sendAuthorizationRequest needs to specify enough info to be able to authorize the user. This consists of either a UUID & IP address (e.g. for SAPI, this is where the user is logged in to the Terminal), or a token (e.g. for BPIPE).
The UUID/IP address mechanism assumes you're logged into the Terminal and know how to get that info, which is not the use case for the http server. So we'll want to use tokens. I'll get to token generation below, but the high level point is that authorization basically boils down to getting a valid token. I'm working on changes that, given a token, will take care of the rest.
(Currently the developer's guide (2.54) has conflicting info. The BPIPE examples use tokens to authorize the user, but the schema section suggests that this is deprecated. Given that we plan on using this token mechanism, we should investigate what the replacement for this is, if it's deprecated, or update the dev guide to not call it deprecated.)
Right now, the only ways I can see of getting a token are using Windows login info, or by generating a MSG to the user containing the token string. The first one obviously doesn't work for us, and the latter is not a good user experience. In the short run, it's good enough for developing the authorization code in the http server, but we'll need to think about how the user will actually input the token.