Identity Requests Approval Regardless of Access Level about identity HOT 11 CLOSED

If your code is public I'm happy to take a look but I have never seen this behavior

from identity.

Thanks. I added you to the repo here: https://github.com/AdonousTech/clout-starter-web-client

One thing I am doing differently is bypassing local storage and storing the Identity credentials in an encrypted DB table. Could this be causing the problem? Any way to work around this, as I would prefer to avoid all the local storage issues by simply using a DB for the Identity credentials?

I have some test calls in the AppComponent.

Please look at line https://github.com/AdonousTech/clout-starter-web-client/blob/05e567332aff2811aec3393daf56062696b4d00b/src/app/app.component.ts#L329

This is where I am signing a post request. The response always returns approvalRequired = true, regardless of the access level.

Please look at https://github.com/AdonousTech/clout-starter-web-client/blob/05e567332aff2811aec3393daf56062696b4d00b/src/app/app.component.ts#L405

This is where I am requesting the JWT from Identity. Again, it always prompts for approval.

I suspect I am doing something wrong with the handling of the cookies. Is it possible to simply rely on the Identity credentials instead of a cookie? This is the way typical OpenId implementations work.

from identity.

I updated the code in the repo linked above to ensure all values required by identity were being added to local storage. I checked and double-checked, but still getting the same behavior.

I am actually confirmed the following values in localstorage:

10.1.10.209:4200

lastIdentityServiceURL: 'https://identity.bitclout.com'
lastLocalNodeV2: '10.1.10.209'
identityUsers:

accessLevel: 4 accessLevelHmac: "****hidden***" btcDepositAddress: "****hidden***" encryptedSeedHex: "****hidden***" hasExtraText: false network: "mainnet"

https://identity.bitclout.com

users: [single user object]
levels: shows public key for my active user and access level 4

Note: I can successfully submit a post (only action I have tried so far), but it ALWAYS asks for approval.

What the heck am I doing wrong? This is one of the most complicated authentication flows I have implemented!

from identity.

It's not obvious to me why this isn't working for you. Here's the line where things are failing:

https://github.com/bitclout/identity/blob/main/src/app/identity.service.ts#L197

You're either failing the access check or your encryption key is missing. What OS/browser are you using? Do you have third party cookies fully disabled? I would suggest debugging that line and seeing if your accessLevel data is wrong or if your encryption key is missing.

from identity.

@maebeam - Thanks for looking into this.

1. I am using Edge Chromium browser
2. I confirmed 3rd party cookies are not being blocked

I'm currently stepping through the code. However, I'm not running a separate node, just hitting api.bitclout.com.

Can you tell me when seed-hex-key-${hostname} is set/ when this method is called?
https://github.com/bitclout/identity/blob/edb81bb0925134414a50eb508c19dff2dd500335/src/app/crypto.service.ts#L43

I checked in local storage for identity.bitclout and I do not see seed-hex-key-${hostname} || seed-hex-key-10.1.10.209 set anywhere. There are 2 objects set in LS for Identity.Bitclout: users and levels.

The levels' object contains the appropriate hostname as a key (10.1.10.209): 10.1.10.209: {BC1YLgQMDskGR7m7fjgkgjdkd62wFCZsPgVWH5BFHijArSRLJyPCVo9AuR: 4}
BC1YLgQMDskGR7m7V3uRqh62wFCZsPgVWH5BFHijArSRLJyPCVo9AuR: 4`

However, the users object does not contain the hostname. There is no reference to hostname or the seed-hex-key-${hostname} LS key anywhere in my LS values.

If seed-hex-key-${hostname} is required to be set in LS, that could be the problem. I just need to know why its not being set.

from identity.

I dug around some more, and I see this is where storageKey is supposed to be set:

https://github.com/bitclout/identity/blob/a822c722b3850b67a4bbe58b0ec81c94e9ee0997/src/app/crypto.service.ts#L73

However, I don't understand why this is not being set when I log in via Identity as shown here in the selectAccount method:

https://github.com/bitclout/identity/blob/9a639726dab09ed3becc62c6c2bb23fa0abf6136/src/app/log-in/log-in.component.ts#L74

You can see that the login method of the Identity service calls getEncryptedUsers on the accountService

https://github.com/bitclout/identity/blob/9a639726dab09ed3becc62c6c2bb23fa0abf6136/src/app/log-in/log-in.component.ts#L77

Within the getEncryptedUsers method on the accountService, I assume my users are all "Public" users (I don't know what a 'Private' user is).

https://github.com/bitclout/identity/blob/9a639726dab09ed3becc62c6c2bb23fa0abf6136/src/app/account.service.ts#L28

Next, I can see that getEncryptedUsers sets the encryptedSeeHex

https://github.com/bitclout/identity/blob/9a639726dab09ed3becc62c6c2bb23fa0abf6136/src/app/account.service.ts#L40

Now, in the encryptSeedHex method, the seedHexEncryptionKey method is called. This is where Identity attempts to fetch the storageKey. However, the key is not present in my LS for Identity.Bitclout:

https://github.com/bitclout/identity/blob/a822c722b3850b67a4bbe58b0ec81c94e9ee0997/src/app/crypto.service.ts#L43

I thought that was the problem, but then I saw that this situation is handled:

https://github.com/bitclout/identity/blob/a822c722b3850b67a4bbe58b0ec81c94e9ee0997/src/app/crypto.service.ts#L71

Unfortunately, I never get the seed-hex-key-${hostname} written to my local storage.

from identity.

Okay, so I checked in cookies, and I see the value is being set there. However, Identity is not checking cookies for the value. Why didn't Identity set the value in local storage? That's what I need to figure out next:

from identity.

I confirmed this is a bona-fide bug in Identity.

Identity relies on the experimental web API Document.HasStorageAccess(). According to browser compatibility on MDN, Chrome has this feature disabled, while Edge has full support.

https://developer.mozilla.org/en-US/docs/Web/API/Document/hasStorageAccess#browser_compatibility

Identity checks mustUseStorageAccess here:

https://github.com/bitclout/identity/blob/edb81bb0925134414a50eb508c19dff2dd500335/src/app/crypto.service.ts#L34

• In Chrome, the hasStorageAccess web api is disabled, so Identity properly stores the storageKey in LS along with all the other required values
• In Edge, 'hasStorageAccess' is supported, so Identity erroneously stores ONLY the 'storageKey' in a cookie, instead of LS. When using Edge, Identity is looking in LS for the 'storageKey' value, which is not there.

This appears to be a bug, as we have different behavior in different browsers, and, there is no way to control it from the app developer perspective.

Is it possible to use a different method to check for storage access (considering the experimental nature of hasStorageAccess)?

Maybe something like:

if (window.localStorage) {
  // Code for localStorage
} else {
  // No local storage
}

https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage

Alternatively, try to set a dummy value in localStorage, then handle the exception.

I think we need a uniform way to deal with this.

Thanks again!!

from identity.

Ah, so this is an Edge issue. Thanks for all the helpful debugging. I think the solution is to try writing and reading to/from both places. I can make this change

from identity.

Sounds good. Thanks!

from identity.

Fixed in #50

from identity.