-
Notifications
You must be signed in to change notification settings - Fork 125
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
carddav: not found #170
Comments
Maybe hydroxide doesn't cope well with these transformations:
Can you give an example of a mismatch? Additionally, hydroxide should send individual per-vCard errors instead of a global error, this is somewhat tracked in emersion/go-webdav#25. |
Thanks for the quick response. That's a good idea! Here is an example of what changes during vdirsyncer's URL "normalization":
In order to try and eliminate the carddav client variable, I just tried to see if the encoding makes any difference in the following way:
But then, I guess all that means is curl is handling the encoding ok. Could the issue then reside in the fact that vdirsyncer is trying to get a bunch of vCards at once (all 700+ maybe)? |
Hm, so URL encoding wouldn't make a difference. Not sure what's going on then. Maybe try to add some |
Ok, so I did a bit more digging. diff --git a/carddav/carddav.go b/carddav/carddav.go
index 76c9b8d..8e680ba 100644
--- a/carddav/carddav.go
+++ b/carddav/carddav.go
@@ -18,9 +18,6 @@ import (
"github.com/emersion/hydroxide/protonmail"
)
-// TODO: use a HTTP error
-var errNotFound = errors.New("carddav: not found")
-
var (
cleartextCardProps = []string{vcard.FieldVersion, vcard.FieldProductID, "X-PM-LABEL", "X-PM-GROUP"}
signedCardProps = []string{vcard.FieldVersion, vcard.FieldProductID, vcard.FieldFormattedName, vcard.FieldUID, vcard.FieldEmail}
@@ -83,8 +80,15 @@ func formatCard(card vcard.Card, privateKey *openpgp.Entity) (*protonmail.Contac
func parseAddressObjectPath(p string) (string, error) {
dirname, filename := path.Split(p)
ext := path.Ext(filename)
- if dirname != "/" || ext != ".vcf" {
- return "", errNotFound
+ if dirname != "/" {
+ // TODO: use a HTTP error
+ errMsg := fmt.Sprintf("hydroxide/carddav: malformed address, dirname != /: %s", dirname)
+ return "", errors.New(errMsg)
+ }
+ if ext != ".vcf" {
+ // TODO: use a HTTP error
+ errMsg := fmt.Sprintf("hydroxide/carddav: malformed address, extension is not .vcf but: %s", ext)
+ return "", errors.New(errMsg)
}
return strings.TrimSuffix(filename, ext), nil
}
@@ -182,12 +186,13 @@ func (b *backend) GetAddressObject(path string, req *carddav.AddressDataRequest)
contact, ok := b.getCache(id)
if !ok {
if b.cacheComplete() {
- return nil, errNotFound
+ errMsg := fmt.Sprintf("hydroxide/carddav: could not find contact id %s in cache, despite cacheComplete", id)
+ return nil, errors.New(errMsg)
}
contact, err = b.c.GetContact(id)
if apiErr, ok := err.(*protonmail.APIError); ok && apiErr.Code == 13051 {
- return nil, errNotFound
+ return nil, errors.New("hydroxide/carddav: got API error code 13051 (whatever that means…)")
} else if err != nil {
return nil, err
}
@@ -291,7 +296,8 @@ func (b *backend) PutAddressObject(path string, card vcard.Card) (loc string, er
return "", err
}
if len(resps) != 1 {
- return "", errors.New("hydroxide/carddav: expected exactly one response when creating contact")
+ errMsg := fmt.Sprintf("hydroxide/carddav: expected exactly one response when creating contact, got %x", len(resps))
+ return "", errors.New(errMsg)
}
resp := resps[0]
if err := resp.Err(); err != nil {
@@ -316,7 +322,8 @@ func (b *backend) DeleteAddressObject(path string) error {
return err
}
if len(resps) != 1 {
- return errors.New("hydroxide/carddav: expected exactly one response when deleting contact")
+ errMsg := fmt.Sprintf("hydroxide/carddav: expected exactly one response when deleting contact, got %x", len(resps))
+ return errors.New(errMsg)
}
resp := resps[0]
// TODO: decrement b.total if necessary Which allowed me to see that quite a few clients (in particular Thundirbird with CardBook extension), perform a:
initially to set up the connection and therefore fail, since – as per discussion in #44 and emersion/go-webdav#30 – hydroxide doesn't implement the .well-known paths yet. This in fact can be easily worked around with a redirect at the webserver level (which might be work mentioning in the installation instructions), something like this for nginx: server {
…
rewrite ^/.well-known/carddav$ https://[servername]/ permanent;
…
} Other issue I discovered with macOS contacts handling of CardDAV: there is a checkbox that can be ticked to "use SSL", buuuut unticking this makes the traffic into garbage. I watched in Wireshark as macOS attempted to contact the server, and no http traffic was generated at all, just giberich that made the reverse proxy answer with "Invalid request". That's about all from me. Closing as technically it's possible to get everything working with hydroxide just the way it is now. Maybe the improvements to the error messages I made could be used? (although I'm not exactly golang fluent – the code above compiled and worked as expected, but it may well contain errors). In any case, I think it would serve others if both the redirect for .well-known and the possible importance of SSL for a number of common clients were documented directly in the installation instructions in README.md? |
Pro tip: you can use
Yup -- PRs welcome.
I'd rather get well-known implemented, than documenting a workaround in the README. I'd rather not add client-specific instructions to the README, either. |
Oh thanks
I understand that. But wouldn't a warning about the occasional need for SSL be helpful? Since it's not really something that can be debugged from the messages that hydroxide will produce and people will be thinking (I would imagine) that it is hydroxide's fault, when it has to do with the client requiring SSL? I realize that is certainly a bug on the part of the client but hey 🤷♂️ I gave up reporting stuff to Apple a looong time ago! |
Hi @emersion and all,
First of all, thanks for your great work on this very helpful floss alternative to the Protonmail bridge!
I've been using it for a while now with IMAP/SMTP with no problem, and I have just recently been trying to set up carddav with no such luck :/
I have set up Apache as a reverse proxy to forward incoming connections to the hydroxide carddav port. Upon setting up a client to access this server, I am simply getting the—rather terse—
carddav: not found
error mentioned in the title.As far as I can tell from the source, this is problematic as the same error is thrown in three different places :
hydroxide/carddav/carddav.go
Line 87 in 6243593
hydroxide/carddav/carddav.go
Line 185 in 6243593
hydroxide/carddav/carddav.go
Line 190 in 6243593
The behavior I am seeing is very similar to #157
although there is no mention of openpgp in my case. By the way, I checked in the web interface to Protonmail, and my emails and contacts are encrypted with the same RSA key (the main one), which hydroxide obviously is handling fine since the emails are functioning ok on the SMTP/IMAP end.
On the server side I am seeing this:
and to give you an idea of the interactions the client is seeing, here is an example using the cli utility
vdirsync
(I have indented the xml for legibility, it is on a single line with literal\n
's everywhere in the original):Similar behavior is also happening with Thunderbird add-on Cardbook, and with the macOS Contacts app: they discover the service ok, create an account but then show nothing in the list of contacts when trying to sync (mind you neither one throws an error though…)
Let me know if there is anything else I can do to help debug.
Best regards,
Mark.
The text was updated successfully, but these errors were encountered: