Open Dimfred opened 4 years ago
This file is loaded on startup of the node. To add a new user and make the change available, the node has to be restarted.
I think this can be improved quite easily. Check file modification time and reload upon change.
More specifically some sort of signal, which is emitted when a user tries to log in. The signal destination can then be a plugin for example, we call that external_service, which then verifies the user and logs him in. The external_service itself is not part of the issue.
IMO we should not add arbitrary signals in the vague hope that some plugin might want to use them in the future.
Also, I think a better approach could be to install a proxy before the API port. Existing proxy implementations typically come with a variety of supported authentication schemes. A new plugin would have to re-implement this all by itself.
@xeroc tag
IMO we should not add arbitrary signals in the vague hope that some plugin might want to use them in the future.
We actually have a plugin that gets credentials from SQLite (later also MySQL) databases.
Also, I think a better approach could be to install a proxy before the API port. Existing proxy implementations typically come with a variety of supported authentication schemes. A new plugin would have to re-implement this all by itself.
Bitshares-core has a login API already, why not use that? The advantage (obv) is that it doesn't break any client side implementations
Also, I think a better approach could be to install a proxy before the API port. Existing proxy implementations typically come with a variety of supported authentication schemes. A new plugin would have to re-implement this all by itself.
Bitshares-core has a login API already, why not use that? The advantage (obv) is that it doesn't break any client side implementations
Because bitshares-core is harder or more expensive to extend and/or maintain. The same applies to API servers, it's clear that practically it's better to run API nodes behind a reverse proxies e.g. HAProxy or Nginx which would handle load-balancing and SSL-offloading better.
Found something to work with haproxy.
Still, i think it would be a nicer solution to have it as part of plugin - after all, that's what plugins are good for, IMHO.
User Story As a
bitshares node operator
I'd like to give the users the best experience.In terms of
api_logins
the user is required to verify himself. Therefore thebitshares blockchain
offers theapi_access_info
. This file is loaded on startup of the node. To add a new user and make the change available, the node has to be restarted. That is pretty inconvenient. It would be great if the change could take place dynamically.More specifically some sort of signal, which is emitted when a user tries to log in. The signal destination can then be a plugin for example, we call that
external_service
, which then verifies the user and logs him in.The
external_service
itself is not part of the issue.Impacts Describe which portion(s) of BitShares Core may be impacted by your request. Please tick at least one box.
P.S.
My thoughts on this and a prototype implementation, which just serves testing purposes for myself can be found here: #2051
In my example I used the
external_service
only for the acquisition of theapi_access_info
and tried to reuse as much code as possible, hence I reused thelogin_api::login
code, to avoid duplicate code. Maybe it's a good idea to make the verification also through theexternal_service
, which would allow for custom verification schemes.