beet hackathon demo - If the authorization is removed re-authorization is not done and also no prompt comes up for it.

[manikey123]

[manikey123]

Please assign to me @sschiessl-bcp

[sschiessl-bcp]

Can you describe the steps to reproduce?

[manikey123]

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

[manikey123]

#122 is a part of the ticket

[manikey123]

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.

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

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

[grctest]

Is this still the case with the upgraded client? Or can we now close this issue?