Re-associating account?

[darkpixel]

A few days ago I accidentally ran out of disk space and Chrome lost its mind.
It sorta looks like the cookies database was corrupted/deleted on my machine.

My padloc site didn't remember me....so I entered my email address and it emailed me a code. I entered the code...and it asked me to create a master password. Padloc is trying to create a new account for me.

I guessed (incorrectly) that creating an identical master password would associate with my old account.

It did not.

Since I am the only administrator in the vault, how do I send an "invite" to associate myself with it?

[MaKleSoft]

Sounds like you used a different email address the second time, maybe? Are you using the official app or a self-hosted instance?

[darkpixel]

Self-hosted. I'm using the same email address I used previously (I can see the 4 account records in the database corresponding with the 4 users that use the service).

When I finish the process it does create a new, identical email address in the database.

[MaKleSoft]

There must be some difference in the two email addresses, otherwise they wouldn't result in a different id, which is basically a hash of the email address.

[darkpixel]

Postgres disagrees with you. :)

[MaKleSoft]

Hm, really not sure how that would happen. Here are the relevant parts of the code:

https://github.com/padloc/padloc/blob/main/packages/core/src/server.ts#L2031
https://github.com/padloc/padloc/blob/main/packages/core/src/util.ts#L195

Maybe you managed to enter some weird zero-width characters that got stripped out when saving them to postgres but made it into the hash? Are there any non-ascii characters in the domain part of the email?

[darkpixel]

No weird characters. Just a-z and dashes. All lower case.

I see that getIdFromEmail does a trim and convert to locale lower case, which shouldn't be outputting anything different because I'm entering my email using all lower-case characters and no spaces.

I tested in node:

> my_email = '[email protected]'
'[email protected]'
> testing = my_email.trim().toLocaleLowerCase()
'[email protected]'
> my_email == testing
true
> 

There doesn't appear to be anything in the way of debug output in that server.ts, so I'm not entirely sure where it might be failing. Maybe it's having trouble looking up the 'old' format in the block at 2038?

[darkpixel]

Should I re-open the bug report?

[darkpixel]

Can't re-open the ticket, so I just created a new one: #720

[MaKleSoft]

Can you reproduce this with a different email address? Or is it simply this one account that seems to be inaccessible because the id is wrong somehow?

Have you tried simply copying over the data from the old auth row to the new one? You should be able to distinguish the two by their data->>'created' value. Obviously make a backup of the database first.

[darkpixel]

Well...without knowing much about the internal architecture and dealing with the god-awful mess of JSON inside a SQL field, I managed to create a new account copy the 'org' array over to the new account.

I can see the new orgs, but they show up with a triangle next to them in the web interface and they are empty.

I dumped all the JSON, cleaned it up with jq and did a diff on the files.

Between my original account and the 'new' account with the same email address, I see the following fields with differences:

• id
• name
• created/updated
• revision
• salt
• iterations
• mainVault->id
• publicKey
• iv
• additionalData

I'm guessing I probably need to copy the iterations, salt, publickey, iv, and additionalData keys over?

[MaKleSoft]

Well...without knowing much about the internal architecture and dealing with the god-awful mess of JSON inside a SQL field, I managed to create a new account copy the 'org' array over to the new account.
I'm guessing I probably need to copy the iterations, salt, publickey, iv, and additionalData keys over?

Yeah, that probably won't work. If your trying to manipulate individual properties you're likely to cause some internal consistency and mess up the data. When I said "copy over the data" I meant the data column in it's entirety. Or you can switch out the ids which has the same effect. Basically you just want to make sure that when you authenticate with your email, the original account is chosen instead of the new one. Don't touch any other tables, just the auth one.

[darkpixel]

Hmm....after testing a few days ago, I deleted the new record from the account table.

Now when I go into padloc, it asks for my email, sends a confirmation code, and then asks for my master password. After I enter that and hit "Login" it pops up and says "An account with this email address does not exist!" with the options of "Sign up" and "Cancel". When I hit "Sign up" it takes me back to the main screen and asks for my email address again, send a code, and keeps looping through this process...

[darkpixel]

Ok--rolled back my database to before I started testing and now it's back to thinking I'm a new user....so I created a new account.

So which ID number am changing? The auth table ID, or the auth table data column id field?

[darkpixel]

Well....after copying that data over, it said my master password was wrong. I tried a few times and it locked me out.

I just get a greyed out screen with no text and an "OK" button.

[darkpixel]

Finally got it.
I created a "new" account and grabbed the id column from the account table.
Then I looked up the id of the new record in the auth table and ran:

update auth set data['account'] = '"old-account-id"' where id = 'new-auth-record-id';

update auth set data['sessions'][0]['account'] = '"old-account-id"' where id = 'new-auth-record-id';

I signed out of the interface and signed back in. It synced my data and I was able to export it.

I'm concerned this could potentially happen to someone else as the root-cause hasn't been found.

Like I mentioned before, the computer ran out of disk space and a bunch of Chrome extensions crashed. I fixed the space issue (killed a runaway process that ate up a ton of disk space) and then restarted Chrome. After that the app thought I was a new account no matter what I did.

I'm not sure if it matters or not, but before I started this process, there was no record for my email address in the auth table, just the accounts table. I'm assuming the auth table is just a temporary store of recently authenticated users, so that probably doesn't matter.

select data->>'email', count(data->>'email') from account group by data->>'email'; still shows 2 next to my email address...so this isn't a mismatch or weird unicode character getting entered or anything.

I can help debug this for another few days if you're interested, but we're going to blow away the database in a few days.
We're moving to https://github.com/gopasspw/gopass/ for a few reasons if the community is interested:

• The response times on this issue is pretty slow which gives the appearance of a lack of interest in troubleshooting the open source side of things.
• Bug [Android] Unable to specify self-hosted server on initial launch #573 seems to make it clear that while padloc is open source, it's going to make it difficult to run stuff on your own to try and drive you towards a paid service. Not to mention, the extension still hasn't been updated to the latest manifest format--so once again, open source users are screwed.
• The structure of the database (using huge JSON blobs) instead of "proper tables" in my personal opinion makes it more difficult for me to troubleshoot on my own if there are problems. I hate having to perform raw SQL queries as it is, but having to deal with Postgres jsonb_pretty(data) and matching up indents or selecting from data->>['somearray'][0]['somefield'] is pretty horrible.