BitShares Forum
Main => Technical Support => Topic started by: monsterer on October 13, 2015, 08:40:54 am
-
Authenticated access to the Graphene API has been restricted to websocket use, arbitrarily (other chains, and even bitshares 1.0 had authenticated access over HTTP).
http://docs.bitshares.eu/api/access.html
This will slow adoption because there is a greater amount of effort required to build a client side websocket interface, especially when all the other blockchains an exchange will likely encounter have HTTP APIs, so they will have already built HTTP wrappers.
edit: Websockets are good for callbacks and data streaming. API calls suit HTTP better.
-
+ you can call the daemon with RPC-JSON calls via HTTP (no login at all ... state-less)
+ AND you can have a keep-alive (authenticated) connection with websockets (including web notifications)
+ different websocket APIs (sub set of calls) can be configured to require different logins
So, what exactly is the problem?
-
+ you can call the daemon with RPC-JSON calls via HTTP (no login at all ... state-less)
+ AND you can have a keep-alive (authenticated) connection with websockets (including web notifications)
+ different websocket APIs (sub set of calls) can be configured to require different logins
So, what exactly is the problem?
HTTP API doesn't let you perform authenticated operations.
-
+ you can call the daemon with RPC-JSON calls via HTTP (no login at all ... state-less)
+ AND you can have a keep-alive (authenticated) connection with websockets (including web notifications)
+ different websocket APIs (sub set of calls) can be configured to require different logins
So, what exactly is the problem?
HTTP API doesn't let you perform authenticated operations.
got it ... but now the full node deamon uses less memory for blockchain read operations .. and only requires to store a state for authenticated users ..
sometimes "what is useful" and "what makes sense" is not the same
-
got it ... but now the full node deamon uses less memory for blockchain read operations .. and only requires to store a state for authenticated users ..
sometimes "what is useful" and "what makes sense" is not the same
IMO it would be a completely trivial change to allow HTTP API to access authenticated methods when a user/password combination is supplied inside the request.
-
@monsterer I agree with you, authenticated http access should be available.
For the time being i'm using a little hack in
https://github.com/cryptonomex/graphene/blob/29cc90ba99b3e317ced330a90f502e33c4f59f1f/libraries/app/application.cpp#L173
_websocket_server->on_connection([&]( const fc::http::websocket_connection_ptr& c ){
auto wsc = std::make_shared<fc::rpc::websocket_api_connection>(*c);
auto login = std::make_shared<graphene::app::login_api>( std::ref(*_self) );
auto db_api = std::make_shared<graphene::app::database_api>( std::ref(*_self->chain_database()) );
auto network_api = std::make_shared<graphene::app::network_broadcast_api >( std::ref( *_self ) );
auto history_api = std::make_shared<graphene::app::history_api >( std::ref( *_self ) );
auto node_api = std::make_shared<graphene::app::network_node_api >( std::ref(*_self) );
wsc->register_api(fc::api<graphene::app::database_api>(db_api));
wsc->register_api(fc::api<graphene::app::login_api>(login));
wsc->register_api(fc::api<graphene::app::network_broadcast_api>(network_api));
wsc->register_api(fc::api<graphene::app::history_api>(history_api));
wsc->register_api(fc::api<graphene::app::network_node_api>(node_api));
});
This will give you deterministic api number:
database_api = 0
login_api = 1
network_broadcast_api = 2
history_api = 3
network_node_api = 4
Long term solution:
* Put HTTP headers in websocket_connection
* Validate user/pass, give access to api based on api-access