Skip to content
This repository has been archived by the owner on Feb 12, 2022. It is now read-only.

Unable to login to Baikal #22

Open
master-sonic opened this issue Jul 22, 2014 · 7 comments
Open

Unable to login to Baikal #22

master-sonic opened this issue Jul 22, 2014 · 7 comments
Labels
weird webdav wontfix

Comments

@master-sonic
Copy link

I ran into similar issues with Baikal as in issue #19.

Here's my logcat:

D/org.anhonesteffort.flock.ServerTestsFragment( 6919): handleStartTests()
D/org.anhonesteffort.flock.ServerTestsFragment( 6919): startTests()
D/org.anhonesteffort.flock.ServerTestsFragment( 6919): STATUS: 100

Apache's access log:

xxx.xxx.xxx.xxx:443 xxx.xxx.xxx.xxx - - [22/Jul/2014:23:37:34 +0200] "PROPFIND /baikal/.well-known/carddav HTTP/1.1" 302 2929 "-" "Jakarta Commons-HttpClient/3.1"
xxx.xxx.xxx.xxx:443 xxx.xxx.xxx.xxx - - [22/Jul/2014:23:38:11 +0200] "PROPFIND //.well-known/carddav HTTP/1.1" 302 2929 "-" "Jakarta Commons-HttpClient/3.1"

Output of curl test:

~ $ curl --request PROPFIND https://xxx.xxx.xxx.xxx/baikal/.well-known/carddav -k
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="https://xxx.xxx.xxx.xxx/baikal/card.php">here</a>.</p>
<hr>
<address>Apache/2.2.16 (Debian) Server at xxx.xxx.xxx.xxx Port 443</address>
</body></html>

And part of baikal's vhost:

        Alias /baikal   /var/www/Baikal/html
        RewriteEngine On
        RewriteRule /.well-known/carddav /baikal/card.php [R,L]
        RewriteRule /.well-known/caldav /baikal/cal.php [R,L]
        <Directory "/var/www/Baikal/html">
                Options None
                Options +FollowSymlinks
                AllowOverride All
        </Directory>

Finally a screenshot of the error message in flock:
screenshot_2014-07-23-00-01-46

Might there be some error in my setup?
@rhodey
Copy link
Contributor

rhodey commented Jul 22, 2014

Thanks for the detailed report :) seems related to #19, working on it.

@entonjackson
Copy link

I know this is a little off-topic, but I have a self signed SSL certificate which doesn't work with Flock as well. Will this also be fixed, or do I need another certificate?

@master-sonic
Copy link
Author

@entonjackson Use/Create your own CA to sign your certs. Then import the cert of your CA to your phone.
See for example issue #18 or here:
http://www.freebsdmadeeasy.com/tutorials/freebsd/create-a-ca-with-openssl.php
http://www.freebsdmadeeasy.com/tutorials/web-server/apache-ssl-certs.php
(don't forget to add SSLCertificateChainFile and SSLCACertificateFile to your apache vhost)
http://davdroid.bitfire.at/faq/entry/importing-a-certificate

@jmue
Copy link

jmue commented Jul 24, 2014

test on baikal/nginx:

one problem is in [CalDavStore|CardDavStore]::getCurrentUserPrincipal() - there is only checked for SC_MOVED_PERMANENTLY, not for SC_MOVED_TEMPORARILY

next error is like bug #23 - this can be fixed with qualified namespace "http://org.anhonesteffort.flock"" in OwsWebDav.NAMESPACE

remaining problem is that custom properties are not supported

@rhodey rhodey mentioned this issue Aug 1, 2014
Closed
@scento scento mentioned this issue Aug 2, 2014
Merged
@rhodey rhodey mentioned this issue Aug 3, 2014
Open
@scento
Copy link
Contributor

scento commented Aug 4, 2014

Some debugging information for baikal on nginx with the patch by @jmue:

Requests

  • PROPFIND /.well-known/carddav HTTP/1.1 - 302 (redirects to /card.php)
  • PROPFIND /card.php HTTP/1.1 - 401 (no digest authentication)
  • PROPFIND /card.php HTTP/1.1 - 207 (success [in theory])

Response /card.php

<?xml version="1.0" encoding="utf-8"?>
<d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:card="urn:ietf:params:xml:ns:carddav">
    <d:response>
        <d:href>/card.php/</d:href>
        <d:propstat>
            <d:prop>
                <d:getlastmodified>Mon, 04 Aug 2014 07:25:57 GMT</d:getlastmodified>
                <d:resourcetype>
                    <d:collection/>
                </d:resourcetype>
            </d:prop>
            <d:status>HTTP/1.1 200 OK</d:status>
        </d:propstat>
    </d:response>
    <d:response>
        <d:href>/card.php/principals/</d:href>
        <d:propstat>
            <d:prop>
                <d:getlastmodified>Mon, 04 Aug 2014 07:25:57 GMT</d:getlastmodified>
                <d:resourcetype>
                    <d:collection/>
                </d:resourcetype>
            </d:prop>
            <d:status>HTTP/1.1 200 OK</d:status>
        </d:propstat>
    </d:response>
    <d:response>
        <d:href>/card.php/addressbooks/</d:href>
        <d:propstat>
            <d:prop>
                <d:getlastmodified>Mon, 04 Aug 2014 07:25:57 GMT</d:getlastmodified>
                <d:resourcetype>
                    <d:collection/>
                </d:resourcetype>
            </d:prop>
            <d:status>HTTP/1.1 200 OK</d:status>
        </d:propstat>
    </d:response>
</d:multistatus>

@rhodey
Copy link
Contributor

rhodey commented Sep 18, 2014

Just finished installing Baikal, gotta say they got their act together :) really painless install.

I've made it to handleCardDavTestAddressbookHomeset() but fail here, the problem seems to be that Baikal is telling Flock to check out "/baikal/html/card.php/principals/usr00%40flock/" for the current user principal but instead Flock (in my case) makes a request to "/b//baikal/html/card.php/principals/usr00%40flock/". Note that I have a rewrite rule setup in lighttpd for "/b".

I think this is because Flock is treating the URL entered in the server tests fragment as a host name and not a URL, gonna try this out and see what comes up next...

@rhodey rhodey added the wontfix label Sep 18, 2014
@rhodey
Copy link
Contributor

rhodey commented Sep 18, 2014

Bleh.....

Turns out that Baikal does the same silly thing as OwnCloud and only persists a static list of WebDAV properties and thus breaks spec. The database structure Baikal uses for calendars makes it impossible for Baikal to fully support the requirements of WebDAV collection properties. For a more detailed explanation of what is wrong with the Baikal DB structure and how it can very trivially be resolved please see #19 (comment)

Going to keep this issue around for the purposes of documentation but labelling as won't fix because the core of this issue is within the Baikal server.

@perguth perguth mentioned this issue Sep 21, 2014
Closed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
weird webdav wontfix
Milestone
No milestone
Development

No branches or pull requests
5 participants
@entonjackson @jmue @master-sonic @scento @rhodey