I neither change the authentication method of the groupware server nor the certificate requirement of the proxy server before the groupware server. For me it would be good enough if I could specify user/password in the base url. But davdroid seems to remove this part of the url.

I neither change the authentication method of the groupware server nor the certificate requirement of the proxy server before the groupware server. For me it would be good enough if I could specify user/password in the base url. But davdroid seems to remove this part of the url.

It doesn’t remove anything, but it doesn’t use username/password from the URL. At the moment, DAVdroid unfortunately only supports username/password or client certificates as authentication, but not both because client certificates are implemented as an authentification method.

BTW, I cannot reply using firefox 59.0.2. In the webconsole I get:

I’m typing this reply with Firefox 59.0.2 (MozillaFirefox-59.0.2-lp150.1.6.x86_64 from OpenSUSE Leap 15 Beta). If you can find out what the problem is, it would be kind if you could report it to NodeBB directly. We’re currently using NodeBB 1.8.2 (latest release) without modifications.

@rfc2822 Any update on using client certificates with username and password authentication? I’m in the same situation as above, where the reverse proxy requires the client certificate and the DAV server requires username and password authentication. There doesn’t seem to be a way to disable the username and password authentication for any of the implementations I’ve tried (NextCloud, Radicale, Baikal).

@rfc2822 Hmm, from what @dg10a wrote (“There doesn’t seem to be a way to disable the username and password authentication…”) I guess this was about 1)?

As far as 2) goes that would only work if the backend CalDAV server supported some mode where you could just tell it “trust me, I’m user XXX, go”. In that case you would use the reverse proxy as a trusted source and just send the required data somehow using HTTP as you have shown. Albeit, not all CalDAV backends support such a thing.

@rfc2822 Thank you, I will look into writing a plugin. However, I think #1 is my preferred solution as it is server agnostic (as @marki mentioned) and does not require the reverse proxy to treat particular applications differently.

@dg10a #1 is also more secure. First, it authenticates the device (certificate), then it authenticates the user (password). It would be so elegant. ^^
Now I’m not sure what you’re planning to do. I hope you’re still using an encrypted private key and you’re not just asking for no credentials anymore. If you’re doing that, you might as well just save the password.

@marki I was asking about disabling user/pass authentication to be able to test client certificate authentication in the current DAVdroid build. My ideal setup would be as you described, with the device authenticated via certificate and the user via password.

Technically, username/password together with client certificates are not that hard. As always, the UI part is more difficult.

All these possiblities:

Service discovery (email) + password

URL (+ service discovery) + password

Service discovery (email) + client certificate

URL (+ service discovery) + client certificate

Service discovery (email) + password + client certificate

URL (+ service discovery) + password + client certificate

In the future: OAuth

Maybe: no authentication at all (yes, this was also requested)

should be grouped in a way that makes sense (and is “material”), and for the most common methods (printed bold above), there should be as little distraction as possible (no talking about strange “certificates” etc. when you choose one of these two methods). Maybe hide everything then 1+2 behind some “expert” button?

It should be possible to change the credentials in the account settings, like now. Maybe it would make sense to change the authentication method, too? For instance, could you change from username/password to client certificates without password at all? In this case, the username/password field would have to disappear.

I guess the whole login activity should be re-worked and probably “materialized” (colors, images, whatever). Would be nice if someone could provide a good draft for the login fragments

By default, only “password” is checked. Like that you can choose to either have no authentication at all (“password” is unselected), one of the two, or both (“password” as well as “client certificate” are selected).

Depending on what is selected, you either show both password and certificate selection at the top (below whatever connection method is chosen), one of the two, or nothing at all (email or username/URL only).

Maybe you could hide the entire lower part “Authenticate using” behind some “Advanced mode” button.

Remains OAuth. I’m not sure about that, would have to read up on how it works first (what data is needed to connect).