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

Add redirect to support RFC 6764 (".well-known" addresses) #126

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
5 participants
@brianpcurran

brianpcurran commented Mar 10, 2014

I added a bit of code to support an HTTP 303 redirect to base_prefix when a client requests /.well-known/carddav or /.well-known/caldav. It's been a while since I've touched Python so feedback would be appreciated. I tested on iOS 7 and it worked great as long as you pre-create an address book and corresponding props file with {"tag": "VADDRESSBOOK"}. iOS then seems to pick up the availability of the address book automatically. I tested with multiple vcf files too and they were both selectable under "Groups" in the Contacts app. I also tested on an Android (4.3.1) device with Card/CalDAV-sync (0.4.5 and 0.4.1, respectively) to make sure I didn't inadvertently break anything and all seemed to be work fine, both when specifying the full path to the address book and when using only the domain name ("https://example.com:5232").
#32

Oh and if someone could test this with the Contacts application on OS X that would be super. Hopefully it will make the ridiculous steps in #81 unnecessary.

@liZe

This comment has been minimized.

Member

liZe commented Mar 10, 2014

Looks good! One little question before merging: what happens when no collection is created before?

@brianpcurran

This comment has been minimized.

brianpcurran commented Mar 10, 2014

If nothing is tagged with VADDRESSBOOK the account successfully verifies (on iOS 7, not sure about Android but can test later today) but there is no option to select it under "Groups" in the Contacts app. I'm not sure what the RFCs say should happen on the client in this case, but I can look into that further as well.

@liZe

This comment has been minimized.

Member

liZe commented Mar 10, 2014

Is there a way to manually create an addressbook by setting a manual full URL? By the way, even if this works, we should try to return something like /user/addressbook.vcs/ and see if it's created by Radicale. Of course, this path should be configurable, and we must find a solution for anonymous users (as said in #111 (comment) that may be solved by this solution).

@brianpcurran

This comment has been minimized.

brianpcurran commented Mar 11, 2014

Not on iOS. If you specify the full URL it still tries for /.well-known/carddav and gets redirected to base_prefix. In the case of CalDAV, you're able to specify a full URL to the calendar. If you look in Advanced Settings for the CardDAV account after creating it (no matter what you specify as the URL when you set it up) the URL is always https://example.com:5232/user/.

By returning a collection path to see if it's created by Radicale, do you mean essentially "faking" that an address book collection exists, and then hoping that the client's subsequent requests for it cause Radicale to create it? I'd worry that this might cause other clients (if configured with https://example.com:5232/, not a full path to a file) to create an extraneous collection, unless Radicale decides to fake the existence of the collection after determining that there are no other existing ones.

Perhaps two additional configuration items would make sense: default_addressbook_filename, and anonymous_addressbook_filename (these could be shortened...). The first to specify the path to the collection that Radicale "fakes" in the case of no address books for an authenticated user, and the second to point to an address book collection that anonymous users of iOS (and other clients that will only request .well-known paths) will be redirected to. Thoughts?

@kyokenn

This comment has been minimized.

kyokenn commented Jul 1, 2014

Perhaps two additional configuration items would make sense: default_addressbook_filename, and anonymous_addressbook_filename

May be add a config option like redirect_urls, for example:

"redirect_urls": {
    "/.well-known/caldav": "/%(login)s/caldav/",
    "/.well-known/carddav": "/%(login)s/carddav/",
}

So every user will be redirected to own address book/calendar.
For the anonymous user redirecting to base_prefix will be enough. Also anonymous urls can be specified in a separate section same as "redirect_urls".

@liZe

This comment has been minimized.

Member

liZe commented Jul 2, 2014

@okami-1: that's exactly what I dream of (in a configparser format). Anyone interested in including this change in the pull request? Hope that it will help to fix #110 and #111 too.

@deronnax

This comment has been minimized.

Contributor

deronnax commented Sep 22, 2014

Me, in something like 2 weeks

@dmfs

This comment has been minimized.

Contributor

dmfs commented Oct 3, 2014

You could redirect the user directly to the principal path (see #198). The .well-know mechanism is meant to provide an entry point into calendar/addressbook discovery. It doesn't need to point directly to the calendars or calendar-home.

@kyokenn

This comment has been minimized.

kyokenn commented Oct 3, 2014

Can you store both addressbook and calendar records at the principal path?

@dmfs

This comment has been minimized.

Contributor

dmfs commented Oct 3, 2014

You can, if the principal path is also a collection, but that's not necessarily the case. With many servers the principal path is kind of a virtual address.
The calendar-home and the addressbook-home are a bit closer to the concept of a folder, although the server doesn't have to support uploads to these neither.
Having principal and a calendar or address book at the same path is definitely not a good idea.

@kyokenn

This comment has been minimized.

kyokenn commented Oct 9, 2014

Redirecting user directly to the principal path is actually a bad idea. #198 should be merged. I already made a workaround for the .well-known path inside my django app: https://github.com/okami-1/djradicale/blob/master/djradicale/views.py

@dmfs

This comment has been minimized.

Contributor

dmfs commented Oct 10, 2014

@okami-1 No, it's actually a very good idea, it's good practice and it's common procedure. The only thing that's different among popular servers is the definition of the principal path. Some servers provide it under a separate path (like /principals/users/{user}), others provide it as a parent directory of the calendars and address books (like /{user} with all calendars and address book located in sub-directories under this path). Both ways are ok and perfectly valid. #198 implements the second way.

deronnax added a commit to deronnax/Radicale that referenced this pull request Oct 20, 2014

@liZe liZe closed this in b863e83 Oct 21, 2014

@liZe liZe modified the milestones: 1.0, 0.10 Oct 22, 2014

@liZe liZe referenced this pull request Aug 1, 2016

Merged

Remove /.well-known #451

@mxdvl mxdvl referenced this pull request Jun 4, 2018

Open

Apple's Contacts Support #740

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment