Hi!

Of course there is a password on the caldavzap URL. Otherwise anybody could access my calendar.

The browser requests the password and access is granted allright. This should not be the problem.

Or does caldavzap run into a problem even though the browser is authenticated?

bye, Klaus

Am 22.09.2015 17:23, schrieb Ján Máté:

Hi,

I don't think that it's CalDavZAP problem, it is 99% related to radicale & your (web server, ...) config.

E.g. if I try to open the: http://calendar.wanderreitkarte.de/cache.manifest I get a password prompt (why the hell you server asks for password to download the source code of cache.manifest?). It definitely not looks like normal installation.

JM

...

On 22 Sep 2015, at 16:41, Klaus Gaßner <kg@waldpfa.de mailto:kg@waldpfa.de> wrote:

Hello List!

I have been trying to use Caldavzap but so far without success.

I have a Radicale server which I want to access. Server is running fine, access with Clients like Mozilla Lightning, Outlook or CalDavSync works fine. Server access is with a ProxyPass in Apache config.

I decided to use globalAccountSettings. Originally, the server's adress was http://calendar.wanderreitkarte.de/beide/calendar.ics, so I set config.js to

var globalAccountSettings=[ { href: 'http://calendar.wanderreitkarte.de/beide/', userAuth: { userName: 'beide', userPassword: 'myPassword' } } ];

Caldav I put onto a different subdomain. This produced cross-domain problems. As I did not find a way to make Radicale allow the cross-domain access, I moved the caldav server one folder down to http://calendar.wanderreitkarte.de/radicale/beide/calendar.ics/ and put CaldavZap on top level of the same subdomain.

Now my settings read var globalAccountSettings=[ { href: 'http://calendar.wanderreitkarte.de/radicale/beide/', userAuth: { userName: 'beide', userPassword: 'myPassword' } } ];

I have changed cache.manifest multiple times and I did get the message that a newer version was available and reloaded the page.

However, when I try to run Caldavzap, I get the following error messages (in Chrome):

Document was loaded from Application Cache with manifest http://calendar.wanderreitkarte.de/cache.manifest calendar.wanderreitkarte.de/:1 http://calendar.wanderreitkarte.de/ Application Cache Checking event calendar.wanderreitkarte.de/:1 http://calendar.wanderreitkarte.de/ Application Cache NoUpdate event calendar.wanderreitkarte.de/:1 http://calendar.wanderreitkarte.de/ Info: [userAccount: 'http://beide@calendar.wanderreitkarte.de/radicale/beide/']: crossDomain set to: 'false' main.js:823

1. PROPFIND http://beide:myPassword@calendar.wanderreitkarte.de/beide/ http://beide:Quaflinger@calendar.wanderreitkarte.de/beide/ 405 (Method Not Allowed) jquery-2.1.4.min.js:4

Error: [netLoadResource: 'PROPFIND http://beide@calendar.wanderreitkarte.de/beide/']: code: '405' status: 'error' webdav_protocol.js:1866 Error: [netFindResource]: 'Unable to load resources'

Questions:

• do you have any idea what the reason for that 405 might be?
• why does it still try to access the old URL

http://beide@calendar.wanderreitkarte.de/beide/? http://beide@calendar.wanderreitkarte.de/beide/ That string is nowhere in the config.js. Or is it wrongly reconstructed from the base URL and login name for some reason?

In Firefox I get a different error message: GET http://calendar.wanderreitkarte.de/cache_handler.js [HTTP/1.1 200 OK 108ms] OPTIONS http://www.inf-it.com/versioncheck/CalDavZAP/ [HTTP/1.1 200 OK 120ms] not well-formed <unknown>:1:110 syntax error

Which does not look similar at all. Any ideas what causes this completely different fail?

Thanks for any advice

                        Klaus

---

https://www.avast.com/antivirus

Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. www.avast.com https://www.avast.com/antivirus

--- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus

Hi!

Am 22.09.2015 18:44, schrieb Ján Máté:

Even if I don't think that this is your problem, It is not recommended to use CalDavZAP with additional authentication (e.g. custom .htaccess). If you want to use authentication use the login screen (and password manager which can pre-fill your password).

Using globalAccountSettings, this would give anyone free access to my config.js which holds my password in clear text. Not a good idea.

Ask Radicale developer for CORS support and all your problems will be solved without ProxyPass and/or similar hacks ...

So are you saying that while Lightning, Outlook and CalDavSync work fine with this setup, CalDavZAP cannot handle it and would need a different server setup?

So it makes no sense to try and find out why CalDavZAP tries to access an URL which is nowhere in the configuration?

bye Nop

--- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus

Radicale can run on its own (default install) or behind an http server (using mod_wsgi).

Letting radicale run behind apache using mod_proxy is not a usual supported configuration. See the documentation : http://radicale.org/user_documentation/#idwsgi-cgi-and-fastcgi

If radicale runs behing apache, CORS headers have to bet set on apache side. See apache documentation (mod_headers).

If radicale runs on its own, CORS headers can be set in radicale config file. See the documentation : http://radicale.org/user_documentation/#idinfcloud-caldavzap-carddavmate

Le 2015-09-22 18:44, Ján Máté a écrit :

Even if I don't think that this is your problem, It is not recommended to use CalDavZAP with additional authentication (e.g. custom .htaccess). If you want to use authentication use the login screen (and password manager which can pre-fill your password).

Ask Radicale developer for CORS support and all your problems will be solved without ProxyPass and/or similar hacks ...

JM

...

On 22 Sep 2015, at 18:28, Klaus Gaßner kg@waldpfa.de wrote:

Hi!

Of course there is a password on the caldavzap URL. Otherwise anybody could access my calendar.

The browser requests the password and access is granted allright. This should not be the problem.

Or does caldavzap run into a problem even though the browser is authenticated?

bye, Klaus