Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update imap & smtp URI for ease of maintenance #5111

Closed
wants to merge 4 commits into from

Conversation

toppk
Copy link
Contributor

@toppk toppk commented Jan 30, 2021

This change cleans up the imapURI a bit. If we call the current state "legacy", then legacy looks a bit like this:

legacy: imap[+(ssl|tls)+]://auth:user:(password|certAlias)@host[:port]/[(0|1)|][prefix]

If we were to imagine a cleaned up version that didn't totally break the
current scheme, we'd move most options to query parameters, which are
named (hence ordering doesn't matter) and it is easier to mantain
forwards and backwards compatability.

This also "split" tls-cert from auth external, so they can be set
independenty in the future. It also merged "autoPrefix" with "prefix"
so they cannot be set independently.

cleanish: imap[+(ssl|tls)+]://user[:password]@host[:port]/?prefix=(auto|/INBOX)&auth-type=(external|plain|oauth2|)&tls-cert=certAlias

What we can do, and be 100% backwards compatable today, is encode the
values both as query parameters and in the "legacy" form. This is
called hybrid, and it doesn't break old decoders since they ignore
query, and all the information in query is redundant. It looks like
this:

hybrid: imap[+(ssl|tls)+]://[auth:]user[:(password|certAlias)]@host[:port]/[(0|1)|][prefix]?prefix=(auto|/prefix)&auth-type=(external|plain|xoauth2|)&tls-cert=certAlias

What I have implemented in this patch is encoding the hybrid uri format.
The uri decoder has been updated to read in legacy, hybrid, and cleanish formats.

If you like this approach, I will update smtp (and pop3, if that's still sticking around) along the same lines, as well as adding a few more test cases. Then I will address any other feedback about the code quality. java is not my native tongue.

This change cleans up the imapURI a bit.  If we call the current state
"legacy", then legacy looks a bit like this:

legacy:     imap[+(ssl|tls)+]://auth:user:(password|certAlias)@host[:port]/[(0|1)\|][prefix]

If we were to imagine a cleaned up version that didn't totally break the
current scheme, we'd move most options to query parameters, which are
named (hence ordering doesn't matter) and it is easier to mantain
forwards and backwards compatability.

This also "split" tls-cert from auth external, so they can be set
independenty in the future.  It also merged "autoPrefix" with "prefix"
so they cannot be set independently.

cleanish:   imap[+(ssl|tls)+]://user[:password]@host[:port]/?prefix=(auto|\/INBOX)&auth-type=(external|plain|oauth2|)&tls-cert=certAlias

What we can do, and be 100% backwards compatable today, is encode the
values both as query parameters and in the "legacy" form.  This is
called hybrid, and it doesn't break old decoders since they ignore
query, and all the information in query is redundant.  It looks like
this:

hybrid:     imap[+(ssl|tls)+]://[auth:]user[:(password|certAlias)]@host[:port]/[(0|1)\|][prefix]?prefix=(auto|\/prefix)&auth-type=(external|plain|xoauth2|)&tls-cert=certAlias

What I have implemented in this patch is encoding the hybrid uri format.
The uri decoder has been updated to read in legacy, hybrid, and cleanish formats.
@toppk
Copy link
Contributor Author

toppk commented Jan 30, 2021

I created this pull request based off of the comment in this old pull request.

#780 (comment)

…as to query params

this cleanup allows for more flexible and less brittle configuration of
settings.  This supports a clean(-ish) uri syntax, the current syntax,
and a hybrid combination.

Here is a summation of those syntax.

legacy:     smtp[+(tls|ssl)+]://user:(password|certAlias):auth@server[:port]

hybrid:     smtp[+(tls|ssl)+]://user:(password|certAlias):auth@server[:port]?auth-type=(plain|external)&tls-cert=certAlias

cleanish:   smtp[+(tls|ssl)+]://user[:password]@server[:port]?auth-type=(plain|external|cram_md5)&tls-cert=certAlias
@toppk toppk changed the title update imap URI for ease of maintenance update imap & smtp URI for ease of maintenance Jan 30, 2021
@toppk
Copy link
Contributor Author

toppk commented Jan 30, 2021

second commit does the same for smtp transport uri.

This is only needed when query contain user input and may contain
reserved chars.
 - smtp may not have auth
 - smtp may not have auth or tls (no query params)
 - tidy up no username/password/auth encoding

test cases added for these issues
@cketti
Copy link
Member

cketti commented Jan 31, 2021

Thanks for taking a stab at this.

Judging by the number of updates to this pull request, you have now experienced first-hand that URIs are not a great serialization format for K-9 Mail's server settings 😄

If we wanted to keep URIs as the serialization format for server settings your new format would be an improvement 👍
However, supporting both the old format and the new one at the same time needlessly increases the complexity of the parsing code. K-9 Mail supports migrations for (account) settings, see StorageMigrations. It could be used to rewrite URIs from the old format to the new format.

However, I want to get rid of the URIs altogether. Many parts of the app already use ServerSettings. There's only a few places left where store/transport URIs are used. I started work on finishing the transition yesterday. Once I'm done it should be fairly easy for you to add support for client certificates and password authentication.

Closing this issue because we're going with a different approach.

@cketti cketti closed this Jan 31, 2021
@toppk
Copy link
Contributor Author

toppk commented Jan 31, 2021

Are you also planning on writing the new encoder/decoder and migration code? If not I'd be happy to help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants