bitshares
beet hackathon demo - If the authorization is removed re-authorization is not done and also no prompt comes up for it.
OS Linux Ubuntu ~$ npm -v 6.9.0 ~$ node -v v10.14.1
Issue: installation steps need more details for Linux
Resolution below:
Step 1) Need to do a prebuild for Linux:
https://electronjs.org/docs/development/build-instructions-linux
--ensure the below libraries exist
sudo apt-get install build-essential clang libdbus-1-dev libgtk-3-dev \
libnotify-dev libgnome-keyring-dev libgconf2-dev \
libasound2-dev libcap-dev libcups2-dev libxtst-dev \
libxss1 libnss3-dev gcc-multilib g++-multilib curl \
gperf bison python-dbusmock openjdk-8-jre
sudo apt-get install libusb-1.0-0-dev
sudo apt-get install libudev-dev
Step 2)For the node_modules/tiny-secp256k1 -- I was facing an issue with npm install on linux -- Solved it using the below command seems like the library from c++ is not signed
sudo npm install --unsafe-perm=true --allow-root
Step 3) For starting the beet app use
sudo npm run start
Time taken : 2hrs
Now proceed with issue
Re-authentication issue
Steps to reproduce
Step 1) Authenticate beet with a dapp
Step 2) Remove the the dapp authentication from the settings page in beet app
Step 3) Now if authentication request is sent again issue is seen due to:
a) As app in the below code is null and the authentication is false
b) The previously received payload resides in the IndexDB
Observed: a) If the IndexDB from the Chrome app is dropped then the issue is solved. That would also affect the functionality b) If the authentication for the above scenario is made true then the app waits until it throws a time out message
Suggestion:
A) Would need to make a re-authentication variable in beet
B) Beet-js on receiving the reauthentication=true in the payload would update the IndexDB to the new link and would drop the other permissions if ever made in the Index DB table.
- Use the authenticate=true in the payload and if authenticate request is received and the IndexDB is having another key id then that would be updated to the new requested one
I prefer suggestion 1) over 2) Plz let me know your feedback or if you have any other better suggestion/ feedback to solve this issue. @sschiessl-bcp
From beet-js side, this may not be handled differently when signing up.
Option to handle it from Beet side:
When Beet sees an incoming request with a hash given, but can't find the hash in its own database it must display a popup to the user that this happened because it might be a possible security risk. If the user confirms, Beet tries to match the hash with the chains / accounts it has in store, creates the entry in the app database and shows the user the link popup just as normal.
Since this is a strategic change, @clockworkgr s opinion and approval is needed.
Is this still the case with the upgraded client? Or can we now close this issue?
