How to get sabredav working, and e.g. tested by litmus

[floogy]

Hi,
I followed http://code.google.com/p/sabredav/wiki/GettingStarted, but didn't get it working.

My structure is

/home/floogy/www/docs/www.davsrv.de/
data
public
 \_server.php
vendor
server.php

I don't know where server.php should reside etc. and what might be wrong with my setup.
/public/server.php is a copy of /server.php.

    # ls -l {data,server.php,public,vendor,composer*,sabre*}
    -rw-r--r-- 1 root root       58 20. Jan 13:41 composer.json
    -rw-r--r-- 1 root root     4205 20. Jan 13:44 composer.lock
    -rw-r--r-- 1 root root      107 20. Jan 14:01 sabredav_install.php
    -rw-r--r-- 1 root root     1192 20. Jan 14:22 server.php

    data:
    insgesamt 0

    public:
    insgesamt 4
    -rw-r--r-- 1 root root 1192 20. Jan 14:23 server.php

    vendor:
    insgesamt 16
    -rw-r--r-- 1 root root  182 20. Jan 13:56 autoload.php
    drwxr-xr-x 2 root root 4096 20. Jan 13:44 bin
    drwxr-xr-x 2 root root 4096 20. Jan 13:44 composer
    drwxr-xr-x 4 root root 4096 20. Jan 13:44 sabre

If I chown :www-data that didn't help. The bbehaviour is still the same:

    # chown -R :www-data {data,server.php,public,vendor,composer*,sabre*}
    # lynx --dump http://www.davsrv.de/public/server.php


    # lynx --dump http://www.davsrv.de/server.php
    <?php

    use
        Sabre\DAV;

    // Files we need

    require_once 'vendor/autoload.php';

    // Now we're creating a whole bunch of objects

    // Change public to something else, if you are using a different directory for your files
    $rootDirectory  = new DAV\FS\Directory('public');

    // The server object is responsible for making sense out of the WebDAV protocol
    $server = new DAV\Server($rootDirectory);

    // If your server is not on your webroot, make sure the following line has the correct information

    // ->setBaseUri('/~evert/mydavfolder'); // if its in some kind of home directory
    // ->setBaseUri('/dav/server.php/'); // if you can't use mod_rewrite, use server.php as a base uri
    // ->setBaseUri('/'); // ideally, SabreDAV lives on a root directory with mod_rewrite sending every request to server.php

    // The lock manager is reponsible for making sure users don't overwrite each others changes. Change 'data' to a different
    // directory, if you're storing your data somewhere else.
    $lockBackend = new DAV\Locks\Backend\File('data/locks');
    $lockPlugin = new DAV\Locks\Plugin($lockBackend);

    $server->addPlugin($lockPlugin);

    // All we need to do now, is to fire up the server
    $server->exec();

    ?>

How can I debug that and find the culprit?

EDIT: I changed line 21 of server.php to  $server ->setBaseUri('/webdav/server.php/'); // if you can't use mod_rewrite, use server.php as a base uri
that's a auth digest secured redirect to document root in lighttpd configuration.

Now I get for ~/Downloads/litmus-0.10.5$ lynx -auth=myuser:mypassword --dump http://www.davsrv.de:80/server.php
   Sabre\DAV\Exception\Forbidden Requested uri (/server.php) is out of
   base uri (/webdav/server.php/) 1.8.2

and for ~/Downloads/litmus-0.10.5$ lynx -auth=myuser:mypassword --dump http://www.davsrv.de:80/webdav/server.php
   Sabre\DAV\Exception\NotImplemented GET is only implemented on File
   objects 1.8.2

I think as as expected.

But the litmus test fails, I don't know how to use it right I think. mod_webdav is responding not sabredav I think.

litmus 0.10.5

litmus  http://www.davsrv.de/webdav user password

-> running `basic':
 0. init.................. pass
 1. begin................. pass
 2. options............... pass
 3. put_get............... pass
 4. put_get_utf8_segment.. pass
 5. mkcol_over_plain...... pass
 6. delete................ pass
 7. delete_null........... pass
 8. delete_fragment....... WARNING: DELETE removed collection resource with Request-URI including fragment; unsafe
    ...................... pass (with 1 warning)
 9. mkcol................. pass
10. mkcol_again........... pass
11. delete_coll........... pass
12. mkcol_no_parent....... pass
13. mkcol_with_body....... pass
14. finish................ pass
<- summary for `basic': of 15 tests run: 15 passed, 0 failed. 100.0%
-> 1 warning was issued.
-> running `copymove':
 0. init.................. pass
 1. begin................. pass
 2. copy_init............. pass
 3. copy_simple........... FAIL (simple resource COPY:
409 Conflict)
 4. copy_overwrite........ WARNING: COPY-on-existing fails with 412
    ...................... FAIL (COPY-on-existing with 'Overwrite: T': 409 Conflict)
 5. copy_nodestcoll....... pass
 6. copy_cleanup.......... pass
 7. copy_coll............. FAIL (collection COPY `/webdav/litmus/ccsrc/' to `/webdav/litmus/ccdest/': 403 Forbidden)
 8. move.................. FAIL (MOVE `/webdav/litmus/move' to `/webdav/litmus/movedest': 409 Conflict)
 9. move_coll............. FAIL (collection COPY `/webdav/litmus/mvsrc/' to `/webdav/litmus/mvdest2/', depth infinity: 403 Forbidden)
10. move_cleanup.......... pass
11. finish................ pass
<- summary for `copymove': of 12 tests run: 7 passed, 5 failed. 58.3%
-> 1 warning was issued.
See debug.log for network/debug traces.
make: *** [check] Fehler 1

litmus  http://www.davsrv.de/webdav/server.php user password

-> running `basic':
 0. init.................. pass
 1. begin................. FAIL (Could not create new collection `/webdav/server.php/litmus/' for tests: 409 Conflict
Server must allow `MKCOL /webdav/server.php/litmus/' for tests to proceed)
<- summary for `basic': of 2 tests run: 1 passed, 1 failed. 50.0%
See debug.log for network/debug traces.
make: *** [check] Fehler 1

$ grep server debug.log
Header Name: [server], Value: [lighttpd/1.4.28]

litmus 0.13 gives similar results. Those results are exactly the results of lighttpd mod_webdav. Therefor I think I'm blind in my understanding how to test sabredav.


Also I have noticed, that 'upgrade' may is the wrong keyword for composer updates(?). You may want to fix that in wiki/GettingStarted.
 

# composer upgrade


                                    
  [InvalidArgumentException]        
  Command "upgrade" is not defined. 
                                    


# composer update
Loading composer repositories with package information
Updating dependencies
Nothing to install or update
Generating autoload files

TIA

floogy

[Evert Pot]

litmus  http://www.davsrv.de/webdav user password

If /webdav/server.php/ is your base url, you should also call litmus on that url.

So:

litmus http://www.davsrv.de/webdav/server.php/ user pwd

litmus  http://www.davsrv.de/webdav/server.php user password

-> running `basic':
 0. init.................. pass
 1. begin................. FAIL (Could not create new collection `/webdav/server.php/litmus/' for tests: 409 Conflict
Server must allow `MKCOL /webdav/server.php/litmus/' for tests to proceed)
<- summary for `basic': of 2 tests run: 1 passed, 1 failed. 50.0%
See debug.log for network/debug traces.
make: *** [check] Fehler 1

A conflict could mean that the collection there already exists. So simply remove the litmus directory and all it's contents, and should be good.

> Also I have noticed, that 'upgrade' may is the wrong keyword for composer updates(?). You may want to fix that in wiki/GettingStarted.

Fixing this, thanks :)

Evert

[floogy]

Hi, I want to get sabredav working for the document root to edit the website by authorized users.

Therefor I changed the pathes in server.php

http://www.bpaste.net/show/BFD6ouKNn4jUHR7ybZ3i/

I also pasted the lighttpd error.log.
Here is my  dav block of lighttpd.conf

http://www.bpaste.net/show/gSZ6sfAAm21xWLuGjtdm/

I get that way on http://www.davsrv.de/dav/server.php this error:

<d:error>
<s:exception>Sabre\DAV\Exception\NotFound</s:exception>
<s:message>File with name /dav could not be located</s:message>
<s:sabredav-version>1.8.2</s:sabredav-version>
</d:error>

and on http://www.davsrv.de/server.php

<d:error>
<s:exception>Sabre\DAV\Exception\NotFound</s:exception>
<s:message>File with name /server.php could not be located</s:message>
<s:sabredav-version>1.8.2</s:sabredav-version>
</d:error>

on http://www.davsrv.de/dav I get the webpage.

I would expect to get on the last one the webdav interface from this code http://code.google.com/p/sabredav/wiki/CreateHTMLDirectories

Thank you in advance

floogy

[Evert Pot]

You cannot really have a real website on your root _and_ sabredav. If you want to run sabredav on a root domain, you must create a new subdomain dedicated to this.

If you do have it on the root, you must set the base url to / and use lighttpd's rewrite system to rewrite every single url to the server.php script..

Evert

> --
> You received this message because you are subscribed to the Google Groups "SabreDAV Discussion" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/sabredav-discuss/-/hnxqMw0-F10J.
> To post to this group, send email to sabredav...@googlegroups.com.
> To unsubscribe from this group, send email to sabredav-discu...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sabredav-discuss?hl=en.

[floogy]

Hi Evert,

can you please point me to an example of such a rewrite on lighttpd, and how the server.php should look in that case?

BTW, I already got it working for /public, but I wasn't able to test that config by litmus. Maybe due to the lacking trailing / in the URL.

kind regards

floogy

[Evert Pot]

On Jan 20, 2013, at 6:25 PM, floogy <ggru...@web.de> wrote:

> Hi Evert,
>
> can you please point me to an example of such a rewrite on lighttpd, and how the server.php should look in that case?

I guess something like this?

url.rewrite-once = ( "[.*]" => "/server.php" )

The server.php is just the default, with the baseUrl set to '/'.

Evert

[floogy]

Hi Evert,

thank you for your answer,

I used this rewrite
        url.rewrite = (
            "^/(.*)$" => "/server.php",
        )

and created a symbolic link to public, because I didn't know how to get that otherwise listing the doc root:
ln -s  /home/gerhard/www/docs/www.davsrv.de public
public -> /home/gerhard/www/docs/www.davsrv.de

     $HTTP["host"] =~ "davsrv" {
        # block 9
        server.document-root = "/home/floogy/www/docs/www.davsrv.de"
        accesslog.filename   = "|/usr/sbin/cronolog /home/floogy/www/logs/%Y/%m/www.davsrv.access.log"
        url.rewrite          = (
            "^/(.*)\.(.+)$" => "$0",
            "^/(.+)/?$"     => "/index.php/$1",
            # 2
        )

    } # end of $HTTP["host"] =~ "davsrv"

    $HTTP["host"] == "webdav.davsrv.de" {
        # block 10
        server.document-root           = "/home/floogy/www/docs/www.davsrv.de"
        accesslog.filename             = "|/usr/sbin/cronolog /home/floogy/www/logs/%Y/%m/www.davsrv.access.log"
        url.rewrite                    = (
            "^/(.*)$" => "/server.php",
        )
        auth.backend                   = "htpasswd"
        auth.backend.htpasswd.userfile = "/home/floogy/www/docs/www.davsrv.de/passwd.dav"
        auth.require                   = (
            "" => (
                "method"  => "basic",
                "realm"   => "dav",
                "require" => "valid-user",
                # 3
            ),
        )

    } # end of $HTTP["host"] == "webdav.davsrv.de"

Now the litmustest looks like this. Are the errors and skips due to the use of lighttpd and as expected?

-> running `basic':
 0. init.................. pass

 1. begin................. pass
 2. options............... pass
 3. put_get............... pass
 4. put_get_utf8_segment.. pass

 5. put_no_parent......... pass
 6. mkcol_over_plain...... pass
 7. delete................ pass
 8. delete_null........... pass
 9. delete_fragment....... pass
10. mkcol................. pass
11. mkcol_again........... pass
12. delete_coll........... pass
13. mkcol_no_parent....... pass
14. mkcol_with_body....... pass
15. finish................ pass
<- summary for `basic': of 16 tests run: 16 passed, 0 failed. 100.0%
-> running `copymove':
 0. init.................. pass

 1. begin................. pass
 2. copy_init............. pass

 3. copy_simple........... pass
 4. copy_overwrite........ pass

 5. copy_nodestcoll....... pass
 6. copy_cleanup.......... pass

 7. copy_coll............. pass
 8. copy_shallow.......... pass
 9. move.................. pass
10. move_coll............. pass
11. move_cleanup.......... pass
12. finish................ pass
<- summary for `copymove': of 13 tests run: 13 passed, 0 failed. 100.0%
-> running `props':
 0. init.................. pass
 1. begin................. pass
 2. propfind_invalid...... pass
 3. propfind_invalid2..... pass
 4. propfind_d0........... pass
 5. propinit.............. pass
 6. propset............... FAIL (PROPPATCH on `/litmus/prop': http://webdav.davsrv.de/litmus/prop: 403 Forbidden
)
 7. propget............... SKIPPED
 8. propextended.......... pass
 9. propmove.............. SKIPPED
10. propget............... SKIPPED
11. propdeletes........... SKIPPED
12. propget............... SKIPPED
13. propreplace........... SKIPPED
14. propget............... SKIPPED
15. propnullns............ SKIPPED
16. propget............... SKIPPED
17. prophighunicode....... SKIPPED
18. propget............... SKIPPED
19. propremoveset......... SKIPPED
20. propget............... SKIPPED
21. propsetremove......... SKIPPED
22. propget............... SKIPPED
23. propvalnspace......... SKIPPED
24. propwformed........... pass
25. propinit.............. pass
26. propmanyns............ FAIL (PROPPATCH on `/litmus/prop': http://webdav.davsrv.de/litmus/prop: 403 Forbidden
)
27. propget............... FAIL (No value given for property {http://example.com/kappa}somename)
28. propcleanup........... pass
29. finish................ pass
-> 16 tests were skipped.
<- summary for `props': of 14 tests run: 11 passed, 3 failed. 78.6%

See debug.log for network/debug traces.

Thank you very much. I hope I didn't introduced to much security flaws....

The litmus test returns 

 1. begin................. FAIL (Could not create new collection `/litmus/' for tests: 401 Unauthorized
Server must allow `MKCOL /litmus/' for tests to proceed)

<- summary for `basic': of 2 tests run: 1 passed, 1 failed. 50.0%

without the correct user and pass.

Have a nice day!

floogy

[Evert Pot]

> Now the litmustest looks like this. Are the errors and skips due to the use of lighttpd and as expected?
>

Yes, this is expected. The defaults don't allow for storage of arbitrary properties. If you want to see a succesful litmus test, you should not use Sabre\DAV\FS\Directory, but Sabre\DAV\FSExt\Directory.

But there's no real point in using that in practice.

Evert

[floogy]

Hi Evert,

thank you very much.  was now able to connect witth nautilus and everything seems to be fine. Much much better then mod_webdav in lighty or the native and extended module in nginx. I hope that will behave with Dreamweaver, Quanta++, Explorer, BitKinect, Cyberduck and Finder a bit similar.

Strange is, that all php files are interpreted but the server.php will be downloaded by wget, lynx or firefox while accessing through other subdomains then webdav.davsrv.de, e.g. like www.davsrv.de/setup.php .

Is this an security issue?

kind regards

floogy

Am Sonntag, 20. Januar 2013 20:58:20 UTC+1 schrieb Evert Pot:

> Now the litmustest looks like this. Are the errors and skips due to the use of lighttpd and as expected?
>

[Evert Pot]

On Jan 20, 2013, at 8:23 PM, floogy <ggru...@web.de> wrote:

> Hi Evert,
>
> thank you very much. was now able to connect witth nautilus and everything seems to be fine. Much much better then mod_webdav in lighty or the native and extended module in nginx. I hope that will behave with Dreamweaver, Quanta++, Explorer, BitKinect, Cyberduck and Finder a bit similar.
>

> Strange is, that all php files are interpreted but the server.php will be downloaded by wget, lynx or firefox while accessing through other subdomains then webdav.davsrv.de, e.g. likewww.davsrv.de/setup.php .

>
> Is this an security issue?

Files that go trough sabredav (including .php files) always get returned as their source. This is the expected behaviour. If you consider that a security problem, you shouldn't expose those php files through sabredav.

Evert

[floogy]

Am Sonntag, 20. Januar 2013 23:51:58 UTC+1 schrieb Evert Pot:

On Jan 20, 2013, at 8:23 PM, floogy <ggru...@web.de> wrote:

> Hi Evert,

>[...]

> Strange is, that all php files are interpreted but the server.php will be downloaded by wget, lynx or firefox while accessing through other subdomains then webdav.davsrv.de, e.g. likewww.davsrv.de/setup.php .
>
> Is this an security issue?

Files that go trough sabredav (including .php files) always get returned as their source. This is the expected behaviour. If you consider that a security problem, you shouldn't expose those php files through sabredav.

Evert

No, for sure I expect the files from https://webdav.davsrv.de to be vieable and downloadable as source, but that happen to server.php also from http:/www.davsrv.de which is the normal webpage. I expoect there the error message mentioned in the docs, that that file isn't meant to be loaded. as

 ~/Downloads/litmus-0.10.5$ lynx -auth=myuser:mypassword --dump http://www.davsrv.de:80/server.php

   Sabre\DAV\Exception\NotImplemented GET is only implemented on File
   objects 1.8.2

But instead it will print the source code to stdin.

The webdav.davsrv.de instead is secured and gives webdav access. www.davsrv.de is the website and php files get processed by php-fcgi, but not server.php. That's a bit strange, at least I don't understand that behaviour.
 
kind regards

floogy

 

[Evert Pot]

> No, for sure I expect the files from https://webdav.davsrv.de to be vieable and downloadable as source, but that happen to server.php also from http:/www.davsrv.de which is the normal webpage. I expoect there the error message mentioned in the docs, that that file isn't meant to be loaded. as
>
> ~/Downloads/litmus-0.10.5$ lynx -auth=myuser:mypassword --dump http://www.davsrv.de:80/server.php
> Sabre\DAV\Exception\NotImplemented GET is only implemented on File
> objects 1.8.2
> But instead it will print the source code to stdin.
>
> The webdav.davsrv.de instead is secured and gives webdav access. www.davsrv.de is the website and php files get processed by php-fcgi, but not server.php. That's a bit strange, at least I don't understand that behaviour.

I'm not sure either to be honest!

I can tell you that the error : "GET is only implemented on File objects" only happens because the Browser plugin is not loaded..

Do so by:

$server->addPlugin(\Sabre\DAV\Browser\Plugin());

before:

$server->exec();

Evert