search

deltachat / interface

General and shared components and discussions relating to deltachat user interface
8 stars 3 forks source link

add `DCLOGIN` uri scheme #48

Closed Simon-Laux closed 1 year ago

Simon-Laux commented 2 years ago

What do you think about this specification? If there are no issues I'll implement it in the next days.

Implementation state

Related Forum topics:

https://support.delta.chat/t/configure-email-account-via-qr-code/1805 https://support.delta.chat/t/configure-dc-account-through-qr-code/1164 https://support.delta.chat/t/allow-users-to-generate-qr-codes-to-simplify-the-login-process/1406

r10s commented 2 years ago

for cbor: one should also take into account, that the code needs to be generated somehow, by ppl not that deep into development maybe, cbor is not the best choice in that regard. it is not that know and has less support than url-parameter or base64 or json.

in general, i am wondering if json is a good format for this purpose.

using the url-parameter-format as for the other schemes has some advantages:

of course, there are also drawbacks :) at least i want to bring up this point more clearly, i've seen it is already partly discussed above :)

interesting, while not totally matching: https://datatracker.ietf.org/doc/html/rfc5092

flub commented 2 years ago

given the available size and the scanning by other apps i guess i feel more for using a plain URI format that's well known. Could flatten everything to query parameters etc, which is all well supported in many languages also for generation like r10s suggests.

Simon-Laux commented 2 years ago

So you are all more in favour of implementing the uri encoding/decoding?

for cbor: one should also take into account, that the code needs to be generated somehow, by ppl not that deep into development maybe, cbor is not the best choice in that regard. it is not that know and has less support than url-parameter or base64 or json.

uri encoding/decoding is easily forgotten and then people wonder why it does not work. (like it worked with this simple password, but does not work with my super secure passwords that contain special characters (which I don't know that they need special encoding so I blame it on DC))

So going for a binary format forces people to think about the documentation. Also I would create a web tool to generate it.

it is not that know and has less support than url-parameter or base64 or json.

msgpack(https://msgpack.org) and cbor(https://cbor.io/impls.html) have implementations for most popular programming languages.

The thing about json (or binary json) is that it is easier for us to work with, than uri encoding which can have a someencoding edge cases like macOS encoding the #. (see https://github.com/deltachat/deltachat-core-rust/issues/1969) or the difference between encodeURIComponent and encodeURI (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent#description) which can be quite confusing when implementing it.

The idea of the version part is that we can change the format, if we decide on the uri-scheme format from the start we could also put the version into a query parameter, I believe we should still have a version, especially if we later might want to allow stuff like oauth authentication in those links/qr-codes, and then we need a way for the old versions of deltachat to tell to the user "this requires a newer version of DC, please update".

an uri based version was already proposed in the forum:

dclogin://password:name@example.com?smtpserver=loginname:password@smtp.example.com:1234&imapserver=loginname:password@imap.example.com:5678&smtpsecurity=ssltls&imapsecurity=ssltls&authmethod=auto&certchecks=auto

which follows the url conventions a bit, kinda like (https://datatracker.ietf.org/doc/html/rfc5092)

There is still the question of how to shorten the parameters, but I don't think it is even needed (we have ~1000 chars, with all parameters set we might get 400-500), also shortening them to single letters makes the format more complicated again.

I'd be in favour of the url based variant though I'm worried the escaping stuff will get too complicated.

r10s commented 2 years ago

thanks for all the considerations!

maybe, the need of a webtool seems to underline that things are designed too complex :)

also, having a webtool does not really help if you want to generate the code automatically somehow. also, this is questionable security wise as one has to enter the password on some platform (even if that is not uploaded somewhere, one has to explain that etc.) (or install the tool locally, which is also some effort) i also do not think that urlencode is often forgotten or a real issue to most devs - and even if, the dev has to learn that then, i mean this is a cornerstone of the whole web, it is needed everywhere and also very visible. you need to learn that anyway soon as a web developer. in contrast to that, cbor. msgpack or whatever is a much bigger hurdle for much fewer impact when new to web development.

i would not die on that hill, tbh, i am also quite a bit unsure about the whole scope of DCLOGIN and why it is needed now, however, i would go the easy path.

another thing: consider also to adapt the existing DCACCOUNT scheme as that is handled more and more by the different UIs. from the view of the UI, both things work the same i think?

EDIT: ahh: and there is currently also a BACKUP-TRANSFER QR-code evolving: https://github.com/deltachat/deltachat-core-rust/pull/3489 - at least that targets a similar field.

Simon-Laux commented 2 years ago

, i am also quite a bit unsure about the whole scope of DCLOGIN and why it is needed now,

It's needed for a project.

another thing: consider also to adapt the existing DCACCOUNT scheme as that is handled more and more by the different UIs. from the view of the UI, both things work the same i think?

data at some web endpoint (DCACCOUNT) vs data inside in the qrcode (DCLOGIN). Yes UI is similar, maybe different wording but apart from that it can share the same code base.

EDIT: ahh: and there is currently also a BACKUP-TRANSFER QR-code evolving: https://github.com/deltachat/deltachat-core-rust/pull/3489 - at least that targets a similar field.

yeah similar field, but also very different

So I will update this pr to propose a uri based approach soon, binary brings it's own complexities so we can try the uri encoding stuff.

Simon-Laux commented 2 years ago

Changed it to a fully URI based approach, what do you think now?