Open bitkarrot opened 2 months ago
Found that it only does that if the first entry of the chat text is more then 25 characters. So 'npub12xwjlv7r2n6y7h2v0n0u2vnr8khs9x7v042tavxtpamsv3hcx58septfzz' doesnt work but 'npub 12xwjlv7r2n6y7h2v0n0u2vnr8khs9x7v042tavxtpamsv3hcx58septfzz' does.
@MORRA-RM good find. now the question is, how big of a security risk is it if its longer? the length is capped for good reason, or else it would not have a limit. Super long links can also an attack vector so we need to curb these.
or should we just selectively allow for only npubs and check the format to make sure its a legit npub, and let it through.
My ideal solution. The cap stays but doesnt even let a long string attempt to enter the text chat. The npub can be viewed by clicking on the user icon if they logged in with an extension only. if someone has the ability to add an npub after they can use any npub. i dont like that because it gets abused in the other chats.
what do you think about adding a condition if any bech32 starting with npub is entered it is converted into a link that directs to the users profile on a client like primal?
would that prevent any attempted malicious activity or does the same security risks remain?
I'm ok with allowing for any of these prefixes. obv we don't do nsec, but these are the common ones.
there are some current edge cases: a slightly shorter npub was ok, a longer one didn't work, and in one case a npub following an emoji came through.
what do you think about adding a condition if any bech32 starting with npub is entered it is converted into a link that directs to the users profile on a client like primal?
would that prevent any attempted malicious activity or does the same security risks remain?
in some cases users like to paste just note...... or nevent..... by itself. we should allow for both of these cases without url, provided its not insanely long. There is guidance in nips for length. https://github.com/nostr-protocol/nips
im still not sure exactly why its doing this. it only locks the chat if the first entry is to long. i entered a random string with 30 characters and it locks i entered the same string but put a space after the third character and it accepted it i entered section 1 of the mahabharata and it accepted the whole effin thing without issue plus it shrank the text field so it didnt take up the entire chat forcing users to scroll endlessly. cant figure out why the limit is only on the first entry of the text
@MORRA-RM this is good, keep posting your observations about what works and what doesn't. its very helpful. Also feel free to post exact strings and the results.
example:
sdlkfjslfksdfsd
is ok sdlkfjslfksdfsdsldkfjsdfjklsdfjlsjljslkjkfjlskfjslfjsdlfsjlfd
freezesHow about you append a "#" before every npub
example
pre_npub = '#' if npub_pasted = "npub1234....": pre_npub += npub_pasted
This should probably fix the crashing issue so npub appears in the backend as "#npub1234", but renders npub1234 by sicing the "#"
How about you append a "#" before every npub
example
pre_npub = '#' if npub_pasted = "npub1234....": pre_npub += npub_pasted
This should probably fix the crashing issue so npub appears in the backend as "#npub1234", but renders npub1234 by sicing the "#"
adding # prevents the chat from crashing, I just tried it.
to be fair, I also tried a " ' " and figured that any string would work, soi guess we can replace the # with just and empty quote( """ )
when pasting npub string in to the chat box, entire app freezes, requires exit and restart.
its probably due to the XSS filter but it should fail gracefully not freeze up