Giter Club home page Giter Club logo

identity's Introduction

Identity

DeSo Identity Service

Development server

Run ng serve for a dev server. Navigate to http://localhost:4200/. The app will automatically reload if you change any of the source files.

Code scaffolding

Run ng generate component component-name to generate a new component. You can also use ng generate directive|pipe|service|class|guard|interface|enum|module.

Build

After proper configuration of environment.ts and environment.prod.ts, run ng build to build the project. The build artifacts will be stored in the dist/ directory. Use the --prod flag for a production build.

Format

Formatting will happen upon commit. Developers can also run npm run format or npx npm run format if npm isn't installed to format all source files

identity's People

Contributors

aeonsw4n avatar andyboyd avatar bloated-devish avatar chrisjacob avatar desodog avatar diamondhands0 avatar farsadf avatar gogofujita avatar imekinox avatar ipaulpro avatar jackson-dean avatar lazynina avatar maebeam avatar mattfoley8 avatar mosster avatar onurklngc avatar redpartyhat avatar stas-kh avatar summraznboi avatar superzordon avatar thehappypenguin avatar tholonious avatar tijno avatar trevormil avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

identity's Issues

`derivedSeedHex` and Messages throws `Incorrect HMAC` error

As the Derived Key implementation is not clearly documented, I thought derivedSeedHex would be interchangeable with seedHex; thus, I copied the implementation provided in this repository (including src/lib/ecies/index.js) and configured it on a React Native project running on top of Expo.

After fiddling around to make the crypto, buffer, and stream implementation load correctly, I tried it with my own seedHex (directly out of my browser's localStorage).

Everything seemed to be working; however, as soon as I replaced the seedHex with the derivedSeedHex (given by doing the derived authorization flow on the identity), the implementation started to throw the following error:

[Unhandled promise rejection: Error: Incorrect MAC]
at src/lib/ecies/index.js:26:1 in kdf
at src/lib/ecies/index.js:170:2 in decrypt
at http://127.0.0.1:19000/node_modules/expo/AppEntry.bundle?platform=ios&dev=true&hot=false&minify=false:192892:18 in decryptShared
at src/pages/Inbox/index.tsx:41:20 in useCallback$argument_0
at [native code]:null in flushedQueue
at [native code]:null in invokeCallbackAndReturnFlushedQueue

The error comes from the following section, and removing it, will cause invalid encryption.

assert(hmacGood.equals(msgMac), "Incorrect MAC");

With that said:

  1. Does the Derived Keys support decrypting messages? (or in other words, Am I doing something wrong?)
  2. If they don't support decryption: when will this feature be available?
  3. If they do support decryption: is it only from the messages encoded using Derived Keys?
  4. All and all, how should I proceed to implement such a feature?

Using 'jwt' method with read-only access

As I understand it, this method was added to verify from the server side that the token is signed by an authorized user.

But this method requires passing 'encryptedSeedHex' in the payload. And 'encryptedSeedHex' is not available with read-only access (empty string).

I suggest to make this method without the requirement to pass 'encryptedSeedHex'.

Brave / Edge not supported

Running into an issue with member.cash identity login - all requests are returning {approvalRequired: true}

The issue seems to be -

In the login window, a value, 'seed-hex-key-member.cash' is set in localStorage.

The iframe expects to be able to retrieve this value but finds that localStorage is empty so creates a new value.

localStorage is both get and set in the identity 'seedHexEncryptionKey' method.

Not sure why this issue is present on member.cash but not on bitclout.com - maybe to do with third party domain restrictions.

Issue can be seen and tested on current member.cash site.

Issues is consistent across Windows 10 Brave, Windows 10 Edge, Android Brave

Questions about approved transactions

Hey,

I'm checking the feasibility of signing transactions but only submitting them conditionally. For this use case I have two questions:

  • When the user signs a transaction, he receives a TransactionHex that can be submitted to confirm the transaction on chain. Does this TransactionHex has any kind of expiration or can be used forever and still work as long the user has the necessary clout to perform the operation?
  • Once I received a signed TransactionHex from the user, is there a way to check if the code is valid without confirming the transaction?

Problems with accessLevelRequest

Hi :),

I'm trying to use Bitclout Identity on my application and I'm having some problems/concerns about security:

1 - When I try to send accessLevelRequest I don't notice any change in the interface or the final access level authorization. I'm opening the following URL: https://identity.bitclout.com/log-in?accessLevelRequest=2.

  • It doesn't show any message that explicit to the user the level of access and after the user authorizes it always return me the access level 4.
  • I also tried using accessLevelRequest=AprovaAll. Am I using the wrong URL or this feature isn't complete yet?

2 - When I'm logged on many user accounts at the same time and use the identity window, it returns me access level 4 for all the logged accounts. Even when I'm selecting just one account. Shouldn't return only the requested level access for the only selected account?

uint64 overflow sometimes

I've seen this a few times after login, not sure why:

ERROR Error: uint64 overflow
    kd https://identity.bitclout.com/main-es2015.ef005e59100a802a3388.js:1
    read https://identity.bitclout.com/main-es2015.ef005e59100a802a3388.js:1
    fromBytes https://identity.bitclout.com/main-es2015.ef005e59100a802a3388.js:1
    fromBytes https://identity.bitclout.com/main-es2015.ef005e59100a802a3388.js:1
    getRequiredAccessLevel https://identity.bitclout.com/main-es2015.ef005e59100a802a3388.js:1
    handleSign https://identity.bitclout.com/main-es2015.ef005e59100a802a3388.js:1
    handleRequest https://identity.bitclout.com/main-es2015.ef005e59100a802a3388.js:1
    handleMessage https://identity.bitclout.com/main-es2015.ef005e59100a802a3388.js:1
    e https://identity.bitclout.com/main-es2015.ef005e59100a802a3388.js:1
    invokeTask https://identity.bitclout.com/polyfills-es2015.f888aaa0bd730994945c.js:1
    onInvokeTask https://identity.bitclout.com/main-es2015.ef005e59100a802a3388.js:1
    invokeTask https://identity.bitclout.com/polyfills-es2015.f888aaa0bd730994945c.js:1
    runTask https://identity.bitclout.com/polyfills-es2015.f888aaa0bd730994945c.js:1
    invokeTask https://identity.bitclout.com/polyfills-es2015.f888aaa0bd730994945c.js:1
    f https://identity.bitclout.com/polyfills-es2015.f888aaa0bd730994945c.js:1
    h https://identity.bitclout.com/polyfills-es2015.f888aaa0bd730994945c.js:1
main-es2015.ef005e59100a802a3388.js:1:746903

Sometime I get it over and over again. Sometimes it goes away and I can login fine!

Using Identity from a native mobile app

As far as I can see, the only way to interact with the identity service such as receiving data after a successful login or to request the signing of a transaction is to post/receive a message on the window event listener. Presumably the intent is for web apps to run Identity in an iframe and communicate through that event listener.
In a native mobile app, if we navigate the user to identity.bitclout.com in an iOS WKWebview or Android CustomTab so that they have a secure environment to login then there is no way to interact with the window event listener.
Similarly when we want to sign a transaction there is no mechanism to post an event to have identity sign the transaction hex.

Am I missing a mechanism that exists for native mobile apps to interact with Identity?

Thanks

Someone else generated the same private seed phrase with "sign up with Deso seed"

I have a couple of alt accounts and anonymous accounts in my DeSo identity on my mobile phone. 2 days ago i noticed that one of my anonymous accounts became active 43 days ago as the account @mayadoesart (the daughter of @VindictiveTJ according to the profile info).

It looks like she generated the same private seed phrase as my anonymous account. I'm so lucky I didn't ever used this account to hold my DeSo or NFT's in it, and no one was harmed by this event.

Getting error while doing submit-transaction after using signTransaction function

I am getting an error

SubmitTransaction: Problem processing transaction: VerifyAndBroadcastTransaction: Problem validating txn: ValidateTransaction: Problem validating transaction: : ConnectTransaction: : _connectBasicTransfer: Problem verifying txn signature: : RuleErrorInvalidTransactionSignature

I am doing it by access level 4 identity login approach:

Am I not supposed to sign transaction with encryptedSeedHex & TransactionHex while attempting from fetch API? Like in service worker, I can't use deso sdk directly rather I can have signTransaction function.. so what I did is made a function named sendDiamonds where I put payload for sendDiamonds and got response of TransactionHex & more from it. Used that TransactionHex with encryptedSeedHex to sign the transaction & made a POST request to submit-transaction endpoint

This is what I am attempting to do: https://www.github.com/whoisanku/CHROME_EXT/blob/service/src/background/background.jsx

cc @lazynina @jackson-dean

JWT iframe request returns TypeError

When sending the below postMessage an error is returned. Probably hit this snap on the JWT request as I was building the internal service...

TypeError: Cannot destructure property 'service' of 't' as it is undefined.

Request

  let jwtReq = {
    id: 'XXXX',
    service: 'identity',
    method: 'jwt',
    payload: {
      accessLevel: user.accessLevel,
      accessLevelHmac: user.accessLevelHmac,
      encryptedSeedHex: user.encryptedSeedHex
    }
  };
  vLog('JWT request', jwtReq);
  let iFrame = document.getElementById('SOMEID').firstChild.contentWindow;
  iFrame.postMessage(jwtReq, '*');

Returned Error

main-es2015.7fd4f7fb2e638fd391c6.js:1 ERROR TypeError: Cannot destructure property 'service' of 't' as it is undefined.
    at e.handleMessage (main-es2015.7fd4f7fb2e638fd391c6.js:1:1661185)
    at main-es2015.7fd4f7fb2e638fd391c6.js:1:1657249
    at u.invokeTask (polyfills-es2015.f888aaa0bd730994945c.js:1:20709)
    at Object.onInvokeTask (main-es2015.7fd4f7fb2e638fd391c6.js:1:1417062)
    at u.invokeTask (polyfills-es2015.f888aaa0bd730994945c.js:1:20630)
    at a.runTask (polyfills-es2015.f888aaa0bd730994945c.js:1:16118)
    at l.invokeTask [as invoke] (polyfills-es2015.f888aaa0bd730994945c.js:1:21759)
    at f (polyfills-es2015.f888aaa0bd730994945c.js:1:33720)
    at h (polyfills-es2015.f888aaa0bd730994945c.js:1:33965)

Traces back to this

                handleMessage(e) {
                    const {data: t} = e
                      , {service: r, method: n} = t;
                    "identity" === r && (n ? this.handleRequest(e) : this.handleResponse(e))
                }

Send BitClout Approve Message is All Wrong

Issue: Approve message for window.open("https://identity.bitclout.com/approve?tx=abc123....") is all wrong for basic transactions of sending bitclout.

At the file identity/src/app/approve/approve.component.ts in generateTransactionDescription(), when the case is a TransactionMetadataBasicTransfer, the display message is all wrong.

  1. It shows total amount of nanos in the transaction including ChangeAmountNanos which is misleading. It should only be SpendAmountNanos.
  2. The public key displayed is the sender's whereas it should be the recipients

When I use the /v0/send-bitclout api route to send 0.1 bitclout worth in nanos from BC1YLiXsLZvrySthVJPJozLr3rMSo2BARZ4VG525bhbsAJCTvwJQJCe to BC1YLh4R1ewSLphyWncnUsRmJ5okAn4xjRMUHD5Q6vVd5ZAYgf8zWZo, I get the following message:

localhost wants to send 0.203897603 bitclout to BC1YLiXsLZvrySthVJPJozLr3rMSo2BARZ4VG525bhbsAJCTvwJQJCe

Identity requests Approval for every transaction after cookie expires

I originally posted this in /frontend, but it was the wrong place. We're having an issue on Safari desktop with approvalRequired on the React web app we're building. I understand that Identity needs to request access again 1 week after login, but we are finding that even after approval is given, and the cookie is updated, Identity continues to request access for every transaction thereafter. i.e.:

Given that I'm using Safari
And I logged in 1 week ago with access level 4
When I attempt to buy a coin
Identity requires me to Approve transaction
And when I Approve transaction, then it is successful
But when I attempt another transaction
Then Identity asks for approval again
Despite the fact that the seed-hex-key in Cookies was correctly updated to last another week (i.e. now to expire 2 weeks from when I originally logged in)

We'd appreciate if you could look into this or provide some insight.

Error trying to change profile picture.

Getting this error 414 Request-URI Too Large when changing profile picture and signing the transaction.
Error occurs when image is more than 150 kb.

Issue similar to #85

Questions about permission expiration

Hi, I have some questions:

When an application uses Bitclout Identity to get user access, it receives some kinds of tokens that can be used to access user info or depending on the access level, makes transactions for the user with/without his permission.

  • Does these tokens ever expire?
  • Is it easy for a user to check all the tokens he generated?
  • Can a user revoke these tokens at any moment?

Identity fails to load window content

I am facing a weird issue! Somehow identity fails to show the window and the only console log I have is this

DevTools failed to load source map: Could not parse content for https://identity.deso.org/vendor/bootstrap.min.css.map: Unexpected token < in JSON at position 0

It would on occasion show the window content but usually the window is blank. I do get port messages and I see them in the console window but can't interact with identity at all Any ideas?!

image

Clear saved accounts

Users should be able to clear the logins saved in Identity & wipe localStorage.

Especially when using on a shared computer.

I added a PoC - let me know if you would like me to PR this.

image

Issue with get free deso and public keys

Trying to make the free Deso link work with a public key on https://nftz.me/signup but getting some errors.

What is the idea here? To make the button get free Deso work as a window.open()

Used some variants of:

https://identity.deso.org/get-deso?derive=false&derivedPublicKey=BC1YLiqkZMS9jA1k9PtGgaKG3fra84cegjEGg5XY2fiYo1tCupy9rwK

How should we format that link?

`decrypt` Only decrypts received messages, not the ones the user has sent

Not sure if this is a bug, a limitation, or a design decision. When using identity to decrypt DMs, it only seems to decrypt the received DMs, and not the ones that the user has sent to the conversation.

bitclout.com seems to be storing the sent messages in local storage before they get encrypted, and that's how they're able to be rendered in the conversation.

My gut is telling me this is probably because they get encrypted using the receiving user's public key, and therefore require that user's private key to decrypt, and because the sender doesn't have that private key, they can't be decrypted?

Just wondering if there's anything that can be done about that, or is the only option to cache the unencrypted messages client side before they get sent? This would mean that if the browser storage (or app storage if using a native app) was cleared, those messages would be lost forever to the person who sent them.

"transactionSpendingLimitHex" is undefined when creating a derived key and user is not logged

  1. Launch a window asking for derived keys permission:
    const transactionSpendingLimit =
    {
      "GlobalDESOLimit": 1000000000,
      "TransactionCountLimitMap":
      {
        "SUBMIT_POST": 1000000,
        "AUTHORIZE_DERIVED_KEY": 2
      }
    };

    identityWindow = window.open('https://identity.deso.org/derive?transactionSpendingLimitResponse=' + encodeURIComponent(JSON.stringify(transactionSpendingLimit)));
  1. Click on "Log in with seed"
  2. Enter the seed phrase of a user
  3. Click on "Load Account"
  4. In the returned payload, the "transactionSpendingLimitHex" is undefined, all other properties contain correct data:
function handleDerive(payload)
{
  if (identityWindow)
  {
    identityWindow.close();
    identityWindow = null;

    var publicKey = payload.publicKeyBase58Check;
    var derivedPublicKey = payload.derivedPublicKeyBase58Check;
    var derivedSeedHex = payload.derivedSeedHex;
    var expirationBlock = payload.expirationBlock;
    var accessSignature = payload.accessSignature;
    var transactionSpendingLimitHex = payload.transactionSpendingLimitHex;

If on step 2 you click on an already logged user, the payload contains the correct "transactionSpendingLimitHex" data

Associate old accounts with Google Login

Hi :), I would like to confirm a couple of questions about the Google Login:

  • Is it possible to associate old Bitclout accounts with the Google Login or only new ones?
  • If not, is this feature planed to be launch soon?

414 URI Too Large on Tx signing

@maebeam @lazynina

Ive been running into this lately when trying to buy creator coins.

Had it a week or so ago when trying to buy HighKey

And now it showed up when trying to buy another coin.

20211022-maSecjwq

Looks like the tx-hex appended to URL is just too long and nginx throws a 414

https://identity.bitclout.com/approve?tx=a6013966079870ae0326c4740bf39a7de3ac561ceeb364641ce84e253a9c038b6e13005cb3e8442f2b32edbde870c70f5083ebe3c3d98df45171ef6b33e733dc4b225b00b0b60be8eacff7390a7a32f1807159c35a0b38f88b64be6cb562cb599d338ed20113de59906cab306afd0cb049a7943cbb04063baa26f0ab1a3656e25b64b39ddf015ef259dc7c42ba692f14dba49b123e86cf870cf724d00dcdad56ed1fb639bcdf01f3bf4becd1d22b439909fd1f6a54f71e167218d40b2a7940603b73873070b4ef0173062fa31fc4070c11660c45c5a0af423ae9bcb774abb54ddc8f69d6f5a2d80701277564a3606969118063a809d6d0544935da295701675bed520c05c6f71488d20171a0541776c97da3047ec138816919faf12d59376ea3d311eee24612fe59b923011d61ad7385a84692756cd97a41f28285d55c8a48fc1a6948bdb9b5d7bc8159f5013b003ac934a2c5dcb624b386cea57c5f1344f41290ccbbfcd96413dfdbe96c8101660f0dcde9b6464f62de738840825062925f08b157e0e471cf2776e1463603a401b60e94880ed3b8ff1f3d54cbd8dc37829c175d5bc0ef28c0d1319572c92693dd01cff9022ad4d3586201783b8e82bb0d0dc07d084bb42e25f70b731518ebe0945a01c9438e55ef70437230ad9c12da9a8d311a9ada65777576f3690e04cb758d1aa6012fd375f29583a996b770945db201fd0ec96e927ce855884856429843d9b186b501e23d2583123daea74d85222eaa6c1549f1e1efed76a7002b08e3ddd66c916584016e3566d9857ece99427e5524aa149a16719fb71a6d0e92f99e3a906cc4697c21019ceaab284509bdd8483d309bd60ed5860a79fff664527c91eff7ab2e68b6ab6c01f7e7b33e8ba0da2b30f84922f77dec0d448620687d21816efcd00d602af8f18a0111bb0f7f0383ef33bdfdf9343c03ef3fa8fabec2a0ccb2cbe8a5cd42029fc2be01dd4ddf5bc961de39c1e150ed01530ad4551e29b71980eb9f4a849dd77ce76c83014c7d6f9acd502fed5d912482125855507ed155e821b33b2d0cec6b4d583af62600f754b8536f92cfe26601676fb7ed83d011870e9c7fcb7d1f8d92624b6cdf2c3100b0a5ac7d50307cfeea1eecdc92f9de75d33ac2a14b3501c5087588a7277478a600069793ec1e1706dee8f41da75cc9302314627d602d29c0328a49894724a63646008e1885127118418f8dae1833531512bb7827d7875878ca04d59c0533d5cdda8e009125d90ca2314d2f739e1643456827667ec6e8dda1275d4bbd35cd5879530a1a0028f94bca803a4a3323789699bb4fdb029581db89e5a48b881714e1eaea348cd4004f47ec29e32363eb7a70de54b4f74c2854dde0bb5cce8ea48744dc472073755e00c617aa73ed1e7fbb72580c4fbe583c9692e5eed2cf4acd5fda193049681d58be002d43f57c573139d850513dede5529f3321a376257c40a312421ab63b8e0b216b007c5331b9e4c87182a863b6ce4065dbd095bb8a303a419b1563b01caede81d95b0060e77ba6018222339a23a12505fd86d741200275e22cc2a6ada1ffa517b73c54004352b99e12184be92c41d690b89a227129ccd62ae6964ebbc72269493ff1e7d3007cf3c6145836b83796d051b2d2a7da482f958c0ad3b2e3c2f78737a1d593ef2a0055a1c42401adb7c63dccfab051740685476fa9a90be6cf209e570667447d67c500445c624d8197894b007ad505558f990f0636d581d29ada37b1473b3f3f08c5bb006bf57deaf8d262bb29588ed2296e31b2eabd1b27164ca11b7865ee1b3a70cfaa009f36f031b81f87aa9a66fd5e5707e934554221bd73150e102f2defb0becd2bca00fe75e56fc68cf5206cdf05228fc64ce077cd32001ef5003e3a66753cb7ca259b00526128f5f061fe52c520c8f077efb201890e73da052858aa619bb8e8ad717888003e8771d45568e564d7e72680db045253b2e995cb603fe7e1f05970d822ed789b00c107f88563607491860fd8b7522490412b01f49ade21fda18d85ef9874979d73007fde03e59315a6c490be26a5f8374f677e43181d5c1569c2ff4a8740482a1de700b6130d0cd3cec914699e4efcfc2b5c887c4ba08eff7c0143e4b5f481e8fffbe600adf54d13e556e1d27240b83d4c02a6f3c0513ea7e908c55c044ffb30eefb8400009b7e949e1d561d324b8a1c74749dcfd455b973e6452eb5d01ef55b8684a47fc8007029405ea1930652ae85b92d06c70889093568e25c7dff639e44b412086c065c00c39cfb4a4336bd23ed3b380beb89dd36faa23a61956719891b0dd82137bd86fd003b789779e46d2c1e6fb99d2e360c55241ce94df0d753615126307ea0ee7f165800eb7cd629e97aef2cd1985d2d1f55969d6c7ba21371e41f848cbeeaaba163d2db0085f4eac2d2770775d6af1bd245a2ef0c672fb10812321b4150170127758c78830099f1b069a86b5d71aebe0ca5f1924e06b4db514774ca68e82bfe29b1816a2d6e0070f6facb3230956f4f43c52b462367142fefe25b41a8843aaad0738d94f0d66f006c06099bba3970a875117fb65eb1a40c4c471e5f8745ab716727ed2d030a61db005fcaa9bf188ac48320ed9ea4b2dbf981feb61cd2a0dcdc6559e68bd1b3db043500bbb1df78bf63eb5945615f39232ae41737e394d6c0eac260f0f479eed33c88a70077a1abbb6be83ed2ce6b8b1dcd5eafa69cb409cf185565e36ed0c078acc571b5003422c462e2fb8fd679aaa0d32215c49c1175155ffb07b99ac00140f6a2c2d8d9000acb1fd1d7500cde2702d0d4086bb14647458a238772e6d2678a92ac56032375005385c815834828fc3665bea0fc7aae5df2acb9f7201ae1811beff3bd904e6ab000087646c05f1d4286698ac0496a02356e4767f11acc4c808f83bfaacbb424ad5f001d5ec89aa6657a72b5c3e489567bf9fb58c63c3e2c21870f3eec843e844848a300f36f4f59cbcaadeb769e84560a6f0bb1cd1e95926156d8539a103bd55b8cf01600b9225074e1bfe5db3afcff767918b2c019aeec220fa127d315b05c8c446c25d000a25bc848eff8dadeb6a0b4ac65f6f496f55da147761d28182c71f6c77cb93874003978f5ff685fe0875bd254a3841bfb666376b9755a368592151f571ef253f3ce003643dc9e3fd98774908186d10ef2398448e34e23c260ba83663d8ccb99ee1c080036553368c93b31f3f0308b259e7af831674cb5c6e3d44c98f77e64465e51337d00b3d81e5cdbab0596512f75f5e0447a13eea5f8e9da54d66d09f72b24d452b76b009abdde73a60d8da08e36b61cc2e9b9a77091e2fe99fdbc2919f7605c1a9dc09e0077b2d186931a3e3dd311a7d4bccb45742aba4167c9afd01e9d63961d4383047000adce086e23f389c534dccef437e1f328d0188d5ee85c9ea8ddf6c9627b9950be00008d5ce2cb04494f456c27ed9938920489ba59d7ba11131a30d488d71908555500c5025604e83b9518d459cad15c8154c5658a550ed7e48a996bc0f421ec98028b00dfa608162d4ac35355f8de70c9d1168d08a5fb8f13c9551b89dac477bfd3a6040026c92f07515972d68246463417c7f6a2611afd15848c4b190216d8a58463b110000356101fef4e84a01be0635e047dcf260667970890f8edb6479b4ed201007ed400c6fdd66a400fd7da24cf64f83bf975375cf401927c2f5515d1d902f4ac790f90001d59a4d5c60eeec7fc0a1f65811dc0691a62b8cab22db9a6b0413197fe39f2c900faad2dc395484b70fdf6b0827ed50defbee292e949db72b92babefbce7d0914f00ee87865f9ca3a018c7db81ca2c907df0ed6e8056aaf25cc252be325de68ee1d100388d692b2cc7145b8012428c5748a433ade1d7a7f9e13addc5382503526cf468006d599e4192997b31c36dad39a4831c651e9d2d455c39eca1d75d63b1dfec9fd00008489c5bdf99643151d74cec80059548bee613440fd7b5639e6f2039d7edde950046986fca5bddbfb8e4d658fa92181f0af4ca7d5164f2f170d065163c94acfedf0020b8438797e6e103af3b52fa1c1132dffc8e44ac67a44851ccfcfb2be029b8950044871eb2e5e6783742b0eefcbdd28f1dd3bfa1f059c2467c3c7f062e7831ae4900b1fb70ef5d0884f181fb8393d5e245cccdba9f5e57933071cea06924a6132ed9008a8de46df45726c9080bf3669a93f3c84db43e07be84df730c9b47cb12e1ea350041293304ce1977d3f9d104e57c4352c27190966d2652cc3756fa672d2da105430004ae4952fef7a84b90dace59e073c6edca988ccaf7dd869f6c9be91c3d8343cf012baf06fc22ce1fff9a62b232ce1cfe127b3bbdb80692cf0ac0bb068bfbc1918a0112fe3d2d671f9d9ea6908b0911396bf32e46dc06c6b95b1b20082733a18d4e510284aa0a79f037d57a31b10cba60423cb152dee580594bcf759e747f37931ba10801f7a13b0e8ecf99c91735b30654c7c0b99380be48e30f4be1f9d1a85a2022f94c018809b0c60ac107a4e2aa1353f43b07ecfe3f29a5b7b81026045c37b6b56eb7630119812c06f4b525d5ce243e7d640a47294fdb99ac19b7e0c1b7d89f45f8dad6540162ec48682b1e5a22696f4e5d3bdc619dd6dad4cdf5b4ff34c481809507d4eeb801603e13302d0b45f40ec2a1542af4bc989191c484c4f6d0a012275351010c0a7701047c41f9d0237292544a4288b95eb3c6688f0398a1509f87ae4c4f2391ac91c90148cae89c7445f525d9886db3ca183a92090b45581c16b8c24546ce7fd3a187a60113f78e138fd9950f359488e7603fca91b223ee715844e2fdeefe4be396c06ca0011c8b6827a91bf8a90810f69cfce87d681e83f198a39f397bf3b669dda659c093011f6a600ca1353b2a689dafc8f918c10ebddaacf6a3831a2ccdf81a937641c1bf0182f071b60f19e6864ed3bfe11c2f6a4bf63cdcf1c4b53fc84015d778a11ec91001130bb79b0a7439413612247b03ec3348ff28d70b37b84be931facc70fa39d33701196486f4f6c6725215a8cf29f997137deaa19e6b4d68a24f7256fb93cfa5560e01d7b85d3cd96958034b2f1b79eedb4fc6d2a2de0a10aaddac77d4d001b65197da0187cd090b32f1dbb815c9a4c09c5f4ceba00d8fc178c6236897d189928e29b91a01335923d43b34ebb41511a0cc7a70a402a7d8d11c4aab6254d22deb9ae74ec43d0167fce1b72aa26a5ef20c521368fa53675834a584afcebca15b0a8593e99805ce01562e93ac7b16fd5d008478868ec1448185ab0e507fd83a204dce429684a7b49e010c56cb22f56deeece860e932031f1d6bc3cf413226eaa5d1c8c3c448fa489af4012bf289cec52b8e793ade2dd333f1b85738f20f254338134cd67032b0ceca49df013ea543719fa7383f6a814d859d94fcd75f14d0b4ba7377aa66b53b80e1f87c6c011609edd41baf6530548267268972bab122cbfe6e8991d15054b17d222b65fb6301332fcb44437732328f90d0958aeec50300ee1ddf5ae3979800c49c7a210df7e1018b22c9e768db2cf02e85054b17a65ac7841c764e326545cf6dd471e3844f50f301b2e351f4a07564768f9fa0e95cd3322638b465362687a5230cdcfd9db49b48cf011beeb7f33b2fcf9c1ededb8878d9afe32699276e20b3f879d1c95fa886b454830143caf59bc17b91fa0db692e2856b57782f4a3e164d6ace2e918b214e49c4b8b801fb680e3c0514c2dec8dcf19eb1df0ea00d215fa70fa1627938c0302bcb1679d4014582770e390f635a7305b536a031ddcbc90dd209d7935cebfeb99cf42eec2a020139bac897366c1953dba7b664b7b628831dcc97bfacac71938335f42236ed65a501aff52ff0880e30dddea48d8f150b0cc3d382fc373f16bbc74d7d5943312d1b3e01c3fa9e3236b1c447ae5244ff496da376255a08a867571d3cfd153713b01c2e9a0138afd5ae0448779d31b05abcfe01a158ce96c6030eb3dff349acab46a1f13dfa01178b0d0ca172a46807554c8d6381bc9955cddba01e4e583ee3fe06dfe9c1fad70191c75cfafc249cffca30cddc3cb617e6d96cb7f3b899a419657f9f7e52aae9b101084f082adc84fbf1e39b56a7b9d5cabb37e6517926476e7599d3790a7e22d95d01bb2f8926430d3374313f1ba0956f9fc770efaa6115e63e5083b5ce626643ac6a01ceb05d218be84763bd9e9f285a11087a90e39c858f9fd3ab6a8db1cf9d68c1f5015fd9060a70b041e5cf14c8659f02ae2dd699c5657bf3c4bd74c1ec55375f35010161024368684221985f1bb0b0dfb9e6508dd2aee2fc832eb1df5f902baa4289b3002ff930967ef1f53a23dd37169e65dc527eea3a3e99ac0da95d2a1c7d455ae77f01ef35a80e1584c3ac487c0d052d1ddfc0b435327a80af34a554d65ff3c71f1c0501a877320d603e853013a8256a509c9c18af9a17f7ac143d1af4c512294d98ca4e003a15ea6ddc1aa81cc266789589af8a7b4693e0c55e99ffc833fbc61926e5d22b00cefa20c4398f68a306dc7e1eda2a786273fdaf6aa58f2a15505721c3a69986b4006fee9eaaa0ae0629705f309180d2c13a26f8d8ca67a2f72a0dd58d40d8edd01d00bf2205680c3c1f5bf695982f6417162f201a352aa2727504b3c18cf28b4decb000ecec523298ab1ce0f054197cc4d0785b0fa6c9240fb2cb901c6113b39c754f1e0031649a9ed6dba92f5c960a4609774315e0e2b6f3b23a5acde599731e400d6d4700f81c391d69662aed242ca6522a31757fb5c213c310e0535bc1cdab29d12e26ef00e47d6f21eaaaafb33d49ed2d7a65cf50498ea8c51498b1337b162125badbf2db00fc71d04b06062a7963fe5c6851e809f41559e9cec51a4e4d2853dc7317cd689100c25c8d69263f7e5ded2c98b7a1eafddbff0069932eb5f34ce1441a5fbdb6545c0035eea4292ee469561c9e90944f2996b49f3e56e01f95bd071545ba08f7c222d10036179bc309ae72c024485fdaed3469b98456cca8ccf14da34a52ce281956bba500e9a41ad7576056894f2c96ffb9500a022f03dcdd7aff9034734ed9c0476be1fd00e3d53e66a25e28a66287488e538cec0bedae877d7c6746275add79762769fdd100d0a7976e5179ef2dedf4a4d8fbbbc850b2ad33fe42d1b575d2b714258358590800844adb1a8e65ad3fd8e72ec452da8ab571382d3ade462dd30eb0c10a0353ed6701c209d0e1abdf159ce98470a9dab1550d89f1331e893f5d702d7e36ff5e4635e5009c98a20b9b5eaaa1823ce01a2135feef441891799150ee6052ebe3165a62864e03736afd0eca01926cc35e36f0314aa0c31a936c055cf900db9b7140b2c45ad76d031900a86e120e80e46830e4708a83ff62ae19378939324029a0b5a9c8511b692902137e6765a625310e2edce4dd146040761f37db4215fbac476872e92e4d5811de018c242333aec670f729f08e223ef8d8815bff1d9c3d093d064db13ad873ea1f2a02b4d8e8a1904e196d9c2c5910e9d99ba8b09aa687586db874ae2cd61dc3a19add0178182f618849d33740155fdef27d3e6c4dcb0c86235ce6df9e9782fbcac5e94a000b6d1be50d7ac891d79485b5cd4351b2b6fb610dde3e756556885c060de28a23000ef8496e0757f19fab76075e377377ed5e43cfe36a926ee319fb3c569360e8f4003a0465742184a9b65ab4396bae54aa43a00ab5800af149f30de9f5f611f0984a000102a9192d6d3fdf38347606e58e96960b4126b6f3c1fb53244032700cdc97a00b18a2c6e8680b302102436bf488c40e25c54fdfb5f9bc3e48b177bff592e535df1f5d773f145cf76b2f00a6a5a48917000000d6c0efb0052102a9192d6d3fdf38347606e58e96960b4126b6f3c1fb53244032700cdc97a00b180000

Increasing Nginx setting large_client_header_buffers can resolve this

https://nginx.org/en/docs/http/ngx_http_core_module.html#large_client_header_buffers

default is 4KB

Identity Requests Approval Regardless of Access Level

I switched from localhost to my private IP address to get the issue resolved where access levels were not showing properly. In localhost, all access levels are set to 4 by default.

Even when testing from an IP address with permission level set to 3, Identity is prompting for approval for everything, even non-monetary transactions (e.g. posts).

In addition, Identity is prompting for approval when requesting a jwt token for the user. The jwt token is necessary for any type of image upload. However, Identity will not return a jwt, it only returns {approvalRequired: true}.

Has anyone else experienced this??

Identity sometimes asks for approval when decrypting even with access level 4

Not sure under what circumstances this happens, but it seems to be related to how long it's been since access was originally granted. But sometimes when sending a decrypt message to identity, it's returning approvalRequired: true, even though AccessLevel: Full was requested and granted. This shouldn't be happening, full access should mean full access, and approval should not be required for anything.

I'm using this in a native mobile app with URL: "https://identity.bitclout.com/embed?accessLevelRequest=4&webview=true" and the decrypt message being sent is:

{
  id: <some uuid>,
  service: 'identity',
  method: 'decrypt',
  payload: {
    accessLevel: 4,
    accessLevelHmac: <stored hmac from login>,
    encryptedSeedHex: <stored encrypted hex from login>,
    encryptedHexes: [<array of encrypted hexes>],
  },
}

Sometimes bitcloutToSellNanos is a negative number

I'm using bitclout/transaction.ts to parse raw transaction data into metadata using Transaction.fromBytes(txBytes)[0];

I'm converting transaction.ts into .js using command:

tsc bitclout/transaction.ts

It is mostly going very well. However, when parsing CREATOR_COIN transactions, I'm sometimes getting negative numbers.

For example for this transaction

https://explorer.cloutangel.com/tx/3JuEUYJmCwdXq9XtqAUZ9YLaEdz4HVbCmZEUKeMtJvN9jUd1tjz5Bg

The following values are produced -

bitcloutToAddNanos:0
bitcloutToSellNanos:-359050958
operationType:0
minCreatorCoinExpectedNanos:11479892781
minBitcloutExpectedNanos:0
creatorCoinToSellNanos:0

I'm guessing it's some problem with large numbers wrapping around -
Maybe related to this - https://github.com/bitclout/identity/pull/6/files ?

Any thoughts?

Running deso identity in ng serve vs ng build

Deso identity works when I use ng serve command.
But when I use ng build --configuration production and copy the dist folder to my server and then use Deso identity from there, I get the below error
https://myDesoIdentity.com/embed?v=2 not found.

Login with google issues on iOS native app

I'm using identity in a WKWebView on a native iOS app running on iOS 14.5.

When using login with google, the behaviour seems a little strange. I've been able to sign in ok, but when trying to use the Login with google button again to log in to a separate google account, it just hits an infinite spinner and never progresses. The only way to resolve the issue is to uninstall and reinstall the app (which clears any storage associated with the browser inside the sandbox, so it's a clean slate). I've attached a screen recording to demonstrate the issue.

Screen.Recording.2021-05-31.at.14.58.00.mov

The recording was taken using a simulator, but things get even worse on a real device. On device, I just get the following error message from Google:

IMG_C96B059A7B33-1

Additionally, the App Store review guidelines state:

4.8 Sign in with Apple
Apps that use a third-party or social login service (such as Facebook Login, Google Sign-In, Sign in with Twitter, Sign In with LinkedIn, Login with Amazon, or WeChat Login) to set up or authenticate the user’s primary account with the app must also offer Sign in with Apple as an equivalent option. A user’s primary account is the account they establish with your app for the purposes of identifying themselves, signing in, and accessing your features and associated services.
Sign in with Apple is not required if:
Your app exclusively uses your company’s own account setup and sign-in systems.
Your app is an education, enterprise, or business app that requires the user to sign in with an existing education or enterprise account.
Your app uses a government or industry-backed citizen identification system or electronic ID to authenticate users.
Your app is a client for a specific third-party service and users are required to sign in to their mail, social media, or other third-party account directly to access their content.

It's possible that it might be ok on the basis that bitclout is a 3rd party service, but it will probably at least be a debate. I could see Apple digging their heels in and saying that since the google sign in is optional, and not required, that sign in with apple must also be presented as an option. I understand why it's not, but I'd rather not have to fight that battle in order to push a bug fix out.

A potential solution to all of the above might be to allow apps to specify a query parameter to the identity URL, e.g. allowGoogle=false to simply hide the log in with google button, which would let us opt out of that functionality until such a time as we can fully get it working. Currently we're not going to be able to update our app without adopting this.

Username and profile pic

I'm trying to add a BitClout login functionality to our web application.

So far I'm able to use the window.open context and send messages to "https://identity.bitclout.com/".

I'm getting the JWT and the public key of the user, but I need at least a username and profile picture.

Is there a way to get them? I saw that you have an endpoint in the backend-api.service, that returns the username and the profilePic (GetUsersStateless) - is there a way to consume this from our webapp?

Global Deso limit for NFT bid transactions seems to apply to gas, and not bid amount

When using Mint Machine by nathanwells, I noticed that I can authorize a derived key once with global deso limit set to 1 DeSo (or something like 1.0001 to be exact - probably to account for gas fees), but then I can get several 1 DeSo bids accepted (by cloutpunk in this case) on that derived key.

So it seems like global deso limit for nft bid transactions - applies to the "act" of placing the bid, so just the gas fees associated, and not to the amount of bids placed.

This does not seem to be the correct behaviour - I would expect that when authorizing a derived key to use NFT bid transactions, with a global deso limit of 1 DeSo, it's one of the 2 options:

  • I can place bids up to 1 DeSo, so if there is already a bid outstanding (not accepted) for 1 deso - I can't place a second one; if someone elses bid is accepted, and thus mine is deleted - then I can place another one up to 1 DeSo, or
  • regardeless of outstanding bids, the total amount of accepted bids on this derived key, cannot exceed 1 deso - so it's 1 cloutpunk @ 1 deso, or 100 other NFTs at 0.01 deso each

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.