Forcing API users to authenticate over websockets will hinder adoption

[ElMato]

@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

Code: [Select]

         _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
 

[monsterer]

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.

[xeroc]

+ 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

[monsterer]

+ 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.

[xeroc]

+ 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?

[monsterer]

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.