I'm trying to streamline login handling, so I'm trying to get caldavzap/auth/index.php working. I had a bear of a time figuring out that my server was not trusting itself. I have a private CA, and the new php 5.6 refused talking to my server over ssl until I added that CA to the list of trusted CAs on the server (see update-ca-certificates(8) on debian jessie)
A tip to do that would fit right in under section "5.) problems with SSL ", something like:
If php 5.6 or higher on the server is not aware of the CA used to create the ssl certificate used by davical, fsockopen() will return 0. Add your CA to the system-wide list of trusted certificate authorities.
Now, talking to oneself over SSL might be redundant, but I would like to get a single config working, and that config should be SSL-only, not accepting plaintext from clients.
As an aside I got the auth/index.php working, returning the correct credentials in the xml after a single successful login on the chromebook. The chromebook client still insists upon demanding a password on every refresh of the calendar even though the password and username are correct in auth/index.php :/ .
Beats me.
Hi Håkon,
sorry for the late answer (I forgot to reply) ...
On 29 Oct 2014, at 00:10, Håkon Alstadheim hakon@alstadheim.priv.no wrote:
I'm trying to streamline login handling, so I'm trying to get caldavzap/auth/index.php working. I had a bear of a time figuring out that my server was not trusting itself. I have a private CA, and the new php 5.6 refused talking to my server over ssl until I added that CA to the list of trusted CAs on the server (see update-ca-certificates(8) on debian jessie)
A tip to do that would fit right in under section "5.) problems with SSL ", something like:
If php 5.6 or higher on the server is not aware of the CA used to create the ssl certificate used by davical, fsockopen() will return 0. Add your CA to the system-wide list of trusted certificate authorities.
Now, talking to oneself over SSL might be redundant, but I would like to get a single config working, and that config should be SSL-only, not accepting plaintext from clients.
the problem is that I don't want to confuse users about SSL settings related to PHP and untrusted Root CAs, because the "auth module setup" itself is only for "advanced admins". I understand that a such sentence can help somebody, but it will confuse much more people who don't understand the whole PKI (so instead of getting less support request we will get more, because users will not understand what is CA, what is fsockopen(), ...)
As an aside I got the auth/index.php working, returning the correct credentials in the xml after a single successful login on the chromebook. The chromebook client still insists upon demanding a password on every refresh of the calendar even though the password and username are correct in auth/index.php :/ .
This cannot be caused by the auth module itself. If your setup works without the auth module and you set exactly the same values in the auth module config (as you used in config.js) it MUST work. The XML from the auth module is appended to the globalAccountSettings only once after the login - then the client use the globalAccountSettings (the auth module is never requested again during the "session").
JM
Beats me.
I wrote:
As an aside I got the auth/index.php working, returning the correct credentials in the xml after a single successful login on the chromebook. The chromebook client still insists upon demanding a password on every refresh of the calendar even though the password and username are correct in auth/index.php :/ .
On 10. nov. 2014 18:09, Ján Máté replied: This cannot be caused by the auth module itself. If your setup works without the auth module and you set exactly the same values in the auth module config (as you used in config.js) it MUST work. The XML from the auth module is appended to the globalAccountSettings only once after the login - then the client use the globalAccountSettings (the auth module is never requested again during the "session").
Bug in Chrome OS browser I suspect. Google Chrome Beta on linux is less fussy, so we'll just have to wait for an update to Chrome OS I believe (or switch the chromebook to linux, taking on a whole new support responsibility on that thing ... )
-
Håkon Alstadheim -
Ján Máté