New auth code is generated each time securejoin link is created
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 25/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- rust
- Domain
- authentication
Research direction
Start from the securejoin code that generates the invite link's s= auth token and compare it with the lookup of an existing invite token. Read the referenced commits d8912a98 and 307a2eb6, which explain why tokens are withdrawn per grpid. The maintainers have not chosen between always regenerating and reusing tokens, so agree on the approach first. Done means repeated link creation keeps s= stable or regenerates it deliberately, and the offline second-device scenario in the issue is tested.
Written by the indexing model from the issue text.
Description
I have created a new profile in Delta Chat Desktop with core 2.62.0 and created two "setup contact" (not group) invite links for the profile.
First link created immediately after setup:
https://i.delta.chat/#A958F64D5A4D60EC7DC5402ECD950C67FD3CA0C9&v=3&i=GZeN100sdXQEkrzp1JAlAnPj&s=YyzTpgrEPbid46yUs6yYn2OV&[email protected]&n=Me
Second link created a bit later:
https://i.delta.chat/#A958F64D5A4D60EC7DC5402ECD950C67FD3CA0C9&v=3&i=GZeN100sdXQEkrzp1JAlAnPj&s=SgEDzS-ZSZH2F6VuYuuoIxRW&[email protected]&[email protected],[email protected]&n=Me
You can see that i= parameter is the same, but s= is different.
The reason to create a new auth token each time was to make it possible for the token to expire. Comment explaining this ("We always generate a new auth token because auth tokens "expire" and can only be used to join groups without verification afterwards.") was removed in d8912a98ac17176e0c277d53d9968c477b5f8200 (PR https://github.com/chatmail/core/pull/8691), but now we create a new auth token each time for no reason, while still looking up invite token if it exists. I think there was no other purpose of generating a new auth token each time.
We anyway withdraw all tokens for the same grpid (including empty grpid meaning "setup contact")
since 307a2eb6ecdc81473b2b707d1d12a9f156db1fab (PR https://github.com/chatmail/core/pull/7176) when any invite link is withdrawn.
First option is to create a new invite token each time, so we always create a new invite and auth tokens when QR code is generated. Second option is to always try to reuse the tokens.
One advantage of the second option is that a QR code created on a second device while offline can be answered by existing device that is online. There was also a topic where user asked why we always regenerate an invite link: https://support.delta.chat/t/invite-link-reset-different-one-produced-on-each-click/4786
If we implement it, the following scenario should work and can be tested:
- Alice sets up two devices
- Alice creates an invite link on the first device
- Wait until Alice's second device receives a sync message
- Bring Alice's second device offline.
- Show a QR code from the second device to Bob.
- Bob should be able to setup contact or join a group via Alice's first device with a QR code shown from the second offline device.
There is also a remotely related issue https://github.com/chatmail/core/issues/7555 about making it visible when auth token is used.
- Dominant language
- Rust
- Stars
- 937
- Forks
- 150
- Avg merge
- 1d 12h
- Merged PRs (30d)
- 90
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from chatmail/core
-
Difficulty 1/5 Under an hour Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 50/100
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 45/100
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 54/100
chatmail/core#8814 · 3 comments · 1 reaction ·
Maintainers usually reply within 1 day
-
bug
Difficulty 3/5 1-2 days Newbie friendliness 56/100
chatmail/core#8802 · 2 comments · 1 reaction ·
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
EmbarkStudios/cargo-deny#910 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
tursodatabase/turso#10054 ·
Maintainers usually reply within 1 day
-
build: Update rust versionPossibly taken A pull request linked to this issue is open or already merged. Opendependencies
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
ibm-granite-community/granite-cli#229 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
orottier/web-audio-api-rs#658 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
aosama/astronomical#1318 ·
Maintainers usually reply within 1 day