search

subdavis / Tusk

🐘 🔒 KeePass-compatible browser extension for filling passwords.
https://subdavis.com/Tusk
Other
476 stars 73 forks source link

UUID references are not resolved #213

Closed iw0nderhow closed 6 years ago

iw0nderhow commented 6 years ago

This issue is a

Please describe the current behavior, and explain why it's bad.

Tusk does not resolve UUID field references (like {REF:U@I:49e530bd456571c6f6250c0010c22416}). This is not good because UUID references are the only way to uniquely identify a stored account, as titles can appear multiple times.

Please describe how you think it should change.

Please make Tusk resolve UUID references so that multiple domains can point to an exactly identifiable password record.

subdavis commented 6 years ago

Hmm, I agree that should work already. Let me double check and get back to you. Thanks!

nkarasic commented 6 years ago

Would this be the reason that the same title & username appear multiple times as entry-list-items, even though they only have one entry in the database?

jeffbowman commented 6 years ago

In my database, I have one entry for my SSO credentials and then many entries to specific locations with references to the user and password in the SSO entry. So, for example, if I have an entry for Jenkins at my company and I want to use my SSO credentials, then I use the reference to the SSO entry in my Jenkins entry. However, when I actually go to the Jenkins page to login, Tusk will not follow the references to the SSO entry and instead will paste the references themselves (ie: {REF:U@I:....} for the user and {REF:P@I:...} for the password).

This is marked as needing more details, I'm happy to try to provide more details from my perspective if the above does not provide enough additional information.

Thanks! Jeff

subdavis commented 6 years ago

It was a pretty worthless bug - simple case mismatch (upper/lower). It allowed me to fix some other issues though. TY.

jeffbowman commented 6 years ago

Great news!! I look forward to the update! Thanks for the plugin.

kopach commented 5 years ago

@subdavis, is solution for this defect was deployed to play store? I do still have this defect reproducible in v2018.9.27

cdesserich commented 5 years ago

@kopach, @subdavis I think I found the issue. MacPass (I'm assuming you're using MacPass, as I am) creates cloned entries that have dashes in the UUIDs, and the ones created in normal KeePass clients do not (i.e. KeePassXC). Tusk seems to handle the non-dashed UUIDs fine, but not the dashed ones. The next version of MacPass will address this. https://github.com/MacPass/MacPass/issues/825

subdavis commented 5 years ago

It's been fixed and needs to deploy to Chrome Webstore. Sorry for the delay

cdesserich commented 5 years ago

It's been fixed and needs to deploy to Chrome Webstore. Sorry for the delay

No apologies. I was trying to point out that the bug really lies in MacPass, not in Tusk. If Tusk handles it both ways, all the better, but it seems like no delimiters in the UUID seems to be the standard everywhere else besides MacPass. That's all I was saying.

kopach commented 5 years ago

Thanks @cdesserich for a clarification and your help. I've just removed delimiters manually from UUID and everything works fine for me now.