apple / ccs-caldavtester Goto Github PK

View Code? Open in Web Editor NEW

55.0 55.0 36.0 3.68 MB

CalDAV/CardDAV Testing Framework used by CalendarServer

Home Page: https://www.calendarserver.org

License: Apache License 2.0

Shell 2.33% Python 97.67%

ccs-caldavtester's People

Contributors

Stargazers

Watchers

ccs-caldavtester's Issues

Allow 400 (Bad Request) for bad requests

douglm@… originally submitted this as ticket:389

Validator prepostcondition only allows 403, 409, 507 as a status even though 400 seems valid and sometimes more appropriate (e..g non-UTC datetime in time-range):

DAV says

Servers MAY reject questionable requests (even though
   they consist of well-formed XML), for instance, with a 400 (Bad
   Request) status code and an optional response body explaining the
   problem.

Build failure: NameError: name 'file' is not defined

While trying the "pip install" step in the install instructions, the build fails as below.

Little-Net:ccs-caldavtester minfrin$ virtualenv venv
created virtual environment CPython3.7.7.final.0-64 in 460ms
  creator CPython3Posix(dest=/Users/minfrin/src/apache/sandbox/calendar/ccs-caldavtester/venv, clear=False, global=False)
  seeder FromAppData(download=False, pip=latest, setuptools=latest, wheel=latest, via=copy, app_data_dir=/Users/minfrin/Library/Application Support/virtualenv/seed-app-data/v1.0.1)
  activators BashActivator,CShellActivator,FishActivator,PowerShellActivator,PythonActivator,XonshActivator
Little-Net:ccs-caldavtester minfrin$ source venv/bin/activate
(venv) Little-Net:ccs-caldavtester minfrin$ pip install -r requirements.txt
Obtaining file:///Users/minfrin/src/apache/sandbox/calendar/ccs-caldavtester (from -r requirements.txt (line 5))
    ERROR: Command errored out with exit status 1:
     command: /Users/minfrin/src/apache/sandbox/calendar/ccs-caldavtester/venv/bin/python -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/Users/minfrin/src/apache/sandbox/calendar/ccs-caldavtester/setup.py'"'"'; __file__='"'"'/Users/minfrin/src/apache/sandbox/calendar/ccs-caldavtester/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info
         cwd: /Users/minfrin/src/apache/sandbox/calendar/ccs-caldavtester/
    Complete output (5 lines):
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/Users/minfrin/src/apache/sandbox/calendar/ccs-caldavtester/setup.py", line 169, in <module>
        long_description = file(joinpath(dirname(__file__), "README.md")).read()
    NameError: name 'file' is not defined
    ----------------------------------------
ERROR: Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output.

"Test: 1" isn't very informative

@wsanchez originally submitted this as ticket:100

When CalDAVTester fails, the specific test that fails has a number. It would be nice if that were something more descriptive.

DTSTAMP should be (partially) filtered in calendarDataMatch

douglm@… originally submitted this as ticket:386

DTSTAMP is equivalent to LAST-MODIFIED for entities without a METHOD so should be filtered for those tests. For example, tests in put.xml fail because the DTSTAMP value changes,

DTSTAMP from rfc5545:

   Purpose:  In the case of an iCalendar object that specifies a
      "METHOD" property, this property specifies the date and time that
      the instance of the iCalendar object was created.  In the case of
      an iCalendar object that doesn't specify a "METHOD" property, this
      property specifies the date and time that the information
      associated with the calendar component was last revised in the
      calendar store.
...
      In the case of an iCalendar object that specifies a "METHOD"
      property, this property differs from the "CREATED" and "LAST-
      MODIFIED" properties.  These two properties are used to specify
      when the particular calendar data in the calendar store was
      created and last modified.  This is different than when the
      iCalendar object representation of the calendar service
      information was created or last modified.

      In the case of an iCalendar object that doesn't specify a "METHOD"
      property, this property is equivalent to the "LAST-MODIFIED"
      property.

Can't checkout caldavtester

jvb@… originally submitted this as ticket:515

Hi. I'd like to checkout caldavtester, but when I execute the svn command given in the instructions I get svn: access to 'http://svn.macosforge.org/repository/calendarserver/CalDAVTester/trunk' forbidden

How can I gain access to this project?

Thanks,

Jeff

Getting FATAL ERROR: No module named vobject.icalendar

douglm@… originally submitted this as ticket:369

When running the caldav tests on Ubuntu 9.10 if I run the individual test

./testcaldav.py CalDAV/reports.xml

it gets to

Test Suite: free-busy reports

test 1

then it terminates with

FATAL ERROR: No module named vobject.icalendar

Uninformative FATAL ERROR

douglm@… originally submitted this as ticket:450

Some server 'feature' kills the tester with

FATAL ERROR: string index out of range

Added a traceback print to caldavtest.py

except Exception, e:

print traceback.format_exc() self.manager.log(manager.LOG_ERROR, "FATAL ERROR: %s" % (e,), before=2) return 0, 1, 0

CalDAVTester-5.1 tag seems to be created incorrectly

@ryandesign originally submitted this as ticket:939

It looks like the CalDAVTester-5.1 tag is having a bit of an identity crisis.

The tag was originally created by copying trunk@11637 in r15455 but then trunk@11915 was copied into the tag in r15460 (leaving you with a trunk directory inside the tag).

To fix this, it would probably be cleanest to svn rm the tag, then recreate it by svn cping the correct revision of trunk.

Use substitution for timezone specs and ids

douglm@… originally submitted this as ticket:372

Allows us to keep them up to date or change them as desired. For example - added to serverinfo.xml

        <substitution>
            <key>$tzspecUSE:</key>
            <value>BEGIN:VTIMEZONE
TZID:US/Eastern
LAST-MODIFIED:20040110T032845Z
BEGIN:STANDARD
DTSTART:20001026T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20000404T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
END:VTIMEZONE
             </value>
        </substitution>

        <substitution>
            <key>$tzidUSE:</key>
            <value>US/Eastern</value>
        </substitution>

And changed CalDAVTester/Resource/CalDAV/implicit/deletecalendar/8.ics to be

BEGIN:VCALENDAR
VERSION:2.0
CALSCALE:GREGORIAN
PRODID:-//CALENDARSERVER.ORG//NONSGML Version 1//EN
$tzspecUSE:
BEGIN:VEVENT
UID:[email protected]
DTSTART;TZID=$tzidUSE::20060101T120000
...

Default params cause issues

douglm@… originally submitted this as ticket:563

Some tests fail because they expect default parameters to be present.

running CalDAV/sharing-peruser-data.xml,

    Test Suite: User02 changed event                          
Test 02 fails because it expects the default RELATED=START

Changed test file

Resource/CalDAV/sharing/peruser-data/simple-change02/2.ics

Not sure if there's any good way to handle these other than require all servers never to output defaults (or always)

"testcaldav.py" file lacks the execution bit

damiano.albani@… originally submitted this as ticket:130

The title says it all : "testcaldav.py" file lacks the execution bit.

Failed Verifier calendarDataMatch for ics with multiple vevents

Script implicitbadclients: All verifications with calendarDataMatch fail with the following error message:
Response data is not calendar data: 'NoneType' object has no attribute 'getText'

But it seems that this only occurs if the ics contains multiple vevents, e.g.:

BEGIN:VCALENDAR
PRODID:-//Example Corp.//CalDAV Client//EN
VERSION:2.0
BEGIN:VEVENT
UID:[email protected]
SUMMARY:Weekly Meeting
DTSTAMP:20041210T183838Z
DTSTART:20041206T120000Z
DTEND:20041206T130000Z
RRULE:FREQ=WEEKLY
END:VEVENT
BEGIN:VEVENT
UID:[email protected]
SUMMARY:Weekly Meeting
RECURRENCE-ID:20041213T120000Z
DTSTAMP:20041210T183838Z
DTSTART:20041213T130000Z
DTEND:20041213T140000Z
END:VEVENT
END:VCALENDAR

As soon as I remove the second vevent, the verifier matches correctly.

I don't know it it is an issue of CalDavTester or from the python class pycalendar.

Content-type matching for CalDAV/put.xml test is not entirely correct

me@… originally submitted this as ticket:882

Suite: PUT with Content-Type parameters

Test: 3

Failed Verifier: propfindItems
        Items not returned in report (OK) for /~evert/sabre/caldavtester/groupwareserver.php/calendars/user01/calendar/1.ics: ('{DAV:}getcontenttype', 'text/calendar;charset=utf-8')
        Unexpected items returned in report (OK) for /~evert/sabre/caldavtester/groupwareserver.php/calendars/user01/calendar/1.ics: ('{DAV:}getcontenttype', 'text/calendar; charset=utf-8; component=vevent')

The test is expecting:

text/calendar;charset=utf-8

I am supplying:

text/calendar; charset=utf-8; component=vevent

The component= parameter is optional.

Changes to test suite

douglm@… originally submitted this as ticket:517

These are notes I took while getting the current version of the test suite to work with bedework.

I've zipped up a copy of most of the affected files.

Added this after line 54 in propfindItems.py - I think it dealt with errors that caused exceptions - produced more useful messages

            if value is None:
                    return False, "           Could not parse XML value: None"

            if value == "":
                    return False, "           Could not parse XML value: zero len"

Where there were delays in the tests they were sometimes not long enough. I added a variable to the server config and used that. It's probably over-long

       <!-- delay inserted (usually after PUT) to allow background scheduling
             processes to run -->
        <substitution>
            <key>$schedDelay:</key>
            <value>14</value>
        </substitution>

Added/changed some delays (used token to set delay length) to

implicitscenario1.xml
implicitallday.xml
implicitauto1.xml
implicitauto3.xml
implicitauto6.xml
implicitcancels.xml
implicitcompatibility.xml
implicitdeletecalendar.xml
implicitrecur1.xml
implicitscenario2.xml
implicitscheduleagent.xml
implicitscheduletag.xml
implicitsecurity.xml
implicittimezones.xml
implicittodo.xml

In reports.xml I'd previously added a load of DEPTH: 1 headers - they may be needed again. Note done yet.

Running all the tests leads to a lot of failures. Turns out user02 is left with a read only privilege on the home which affects everything below it. acl.xml doesn't clean up user2 home afterwards.

Added

    <request user="$userid2:" pswd="$pswd2:">
        <method>ACL</method>
        <ruri>$calendarhome2:/</ruri>
        <data>
            <content-type>text/xml; charset=utf-8</content-type>
            <filepath>Resource/CalDAV/acls/99.xml</filepath>
        </data>
    </request>

to the end stuff with 99.xml being

<?xml version="1.0" encoding="utf-8" ?>
<D:acl xmlns:D="DAV:" >
    <D:ace>
        <D:principal>
            <D:property><D:owner/></D:property>
        </D:principal>
        <D:grant>
            <D:privilege><D:all/></D:privilege>
        </D:grant>
    </D:ace>
    <D:ace>
        <D:principal>
            <D:href>$principaluri2:</D:href>
        </D:principal>
        <D:grant>
            <D:privilege><D:all/></D:privilege>
        </D:grant>
    </D:ace>
</D:acl>

Not altogether what I want but deals with the issue.

Acl test reversed?

douglm@… originally submitted this as ticket:373

test 6 of CalDAV/acl.xml appears to be testing deny before grant restrictions by sending an acl with a deny before a grant.

RFC3744 says

5.6.3. DAV:deny-before-grant
This element indicates that all deny ACEs must precede all grant ACEs.
<!ELEMENT deny-before-grant EMPTY>

and

8.1.1. ACL Preconditions
...
(DAV:deny-before-grant): All non-inherited deny ACEs MUST precede all non-inherited grant ACEs.

while the test appears to be checking for the reverse, i.e. grant must precede deny

sharing-notification-sync.xml - incorrect resources

douglm@… originally submitted this as ticket:540

Resource/CalDAV/sharing/notification-sync/2.xml has the content

<?xml version="1.0" encoding="utf-8" ?>
<D:sync-collection xmlns:D="DAV:">
<D:sync-token/>
</D:sync-collection>

which is invalid according to the spec

   <!ELEMENT sync-collection (sync-token, sync-level, limit?, prop)>

Should be more like

   <?xml version="1.0" encoding="utf-8" ?>
   <D:sync-collection xmlns:D="DAV:">
     <D:sync-token/>
     <D:sync-level>1</D:sync-level>
     <D:prop>
       <D:getetag/>
     </D:prop>
   </D:sync-collection>

Similarly 4.xml, 9.xml

Incorrect treatment of Depth on REPORTs

navara@… originally submitted this as ticket:297

CalDAVTester incorrectly sends calendar-query REPORTs with no Depth header and expect it to match on the contents of the collection. No Depth header is equivalent to Depth: 0 as per RFC 4791 and RFC 3253 (section 3.6), so no matching on child resources should be performed by the server. This results in the failure of reports.xml tests and possibly others.

Remove dependency on Pyflakes

riggle@… originally submitted this as ticket:408

DCS is unbuildable because of Pyflakes. Can you guys remove the dependency on Pyflakes? Here's what ./run prints out:

Updating CalDAVTester... At revision 6892.

Removing build directory /Users/dave/DarwinCalendarServer/CalDAVTester/build... Removing pyc files from /Users/dave/DarwinCalendarServer/CalDAVTester... Updating Pyflakes... svn: 'http://divmod.org/svn/Divmod/trunk/Pyflakes' path not found

propfindItems should allow asserting the existence of specific children

@dreid originally submitted this as ticket:49

Currently you have to match the entire string of the property's children. In particular this would allow some tests to pass when backed by an OD server with group and resource principal collections instead of just the user principal collection found in the static configuration.

sharing-invites: Extra cleanup and incorrect test for bad users

douglm@… originally submitted this as ticket:539

In sharing-invites.xml we have

   <test-suite name='Attempt broken invite'>
        <test name='1' ignore='no'>
            <description>POST invitation</description>
...
                <verify>
                    <callback>multistatusItems</callback>
                    <arg>
                        <name>424</name>
                        <value>$cuaddr2:</value>
                    </arg>
                    <arg>
                        <name>403</name>
                        <value>mailto:[email protected]</value>
                    </arg>
...

The first test should be for 200 as the server should accept all the good ones.

The next test also needs changing to check for a single notification rather than no notification

Also - same file it would be useful to add some extra cleanup to help after errors:

Added

    <request>
      <method>DELETE</method>
      <ruri>$calendarhome1:/shared2/</ruri>
    </request>

better parsing of returned properties would help

douglm@… originally submitted this as ticket:371

Tests fail with messages like:

Failed Verifier: propfindItems
        Items not returned in report (OK) for /ucaldav/user/user01/Inbox/: ('urn:ietf:params:xml:ns:caldavschedule-default-calendar-URL', '<href xmlns="DAV:">/ucaldav/user/user01/calendar</href>')
        Unexpected items returned in report (OK) for /ucaldav/user/user01/Inbox/: (u'urn:ietf:params:xml:ns:caldavschedule-default-calendar-URL', u'<href>/ucaldav/user/user01/calendar/</href>')

because of unexpected formats to the response, e.g.

<?xml version="1.0" encoding="UTF-8" ?>

<multistatus xmlns="DAV:" xmlns:ns1="urn:ietf:params:xml:ns:caldav" xmlns:ns2="http://www.w3.org/2002/12/cal/ical#">
  <response>
    <href>/ucaldav/user/user01/Inbox/</href>
    <propstat>
      <prop>
        <ns1:schedule-default-calendar-URL>
          <href>/ucaldav/user/user01/calendar/</href>
        </ns1:schedule-default-calendar-URL>
      </prop>
      <status>HTTP/1.1 200 ok</status>
    </propstat>
  </response>
</multistatus>

Exclusion/inclusion of test values

douglm@… originally submitted this as ticket:562

In sharing-notification-sync.xml for example we have

   <test-suite name='initial tokens - depth infinity' ignore='no'>
        <test name='1' ignore='no'>
...
                <verify>
                    <exclude-feature>
                        <feature>split-calendars</feature>
                    </exclude-feature>
                    <callback>multistatusItems</callback>
                    <arg>
                        <name>okhrefs</name>
                        <value>$calendar:/</value>
                        <value>$inbox:/</value>
                        <value>$outbox:/</value>
                        <value>$freebusy:</value>
                        <value>$notification:/</value>
                        <value>shared/</value>
                    </arg>
                    <arg>
                        <name>badhrefs</name>
                        <value>$dropbox:/</value>
                    </arg>
                </verify>
                <verify>
                    <require-feature>
                        <feature>split-calendars</feature>
                    </require-feature>
                    <callback>multistatusItems</callback>
                    <arg>
                        <name>okhrefs</name>
                        <value>$calendar:/</value>
                        <value>$tasks:/</value>
                        <value>$inbox:/</value>
                        <value>$outbox:/</value>
                        <value>$freebusy:</value>
                        <value>$notification:/</value>
                        <value>shared/</value>
                    </arg>
                    <arg>
                        <name>badhrefs</name>
                        <value>$dropbox:/</value>
                    </arg>
                </verify>

Currently I don't have split calendars, not dropbox nor a freebusy calendar so I get 2 failures for freebusy and dropbox.

I don't think I could reasonably express all that with the exclude-feature and require-feature sub-elements

It might simplify things if we could apply an exclude-feature and require-feature attribute to the value and arg elements

JSON observer does NOT contain request&response in details

jsondump observer ignores command line switches: --print-details-onfail, --allways-print-request and --allways-print-response.

The first switch is used by https://github.com/calconnect/caldavtester-tools to store the data of run tests.

Ralf

Do GET to allow auto-provision?

douglm@… originally submitted this as ticket:374

CalDAV/implicitauto1.xml failed during startup until the following get was added after request #⁠4

       <request user="$resourceid1:" pswd="$pswd1:">
            <method>GET</method>
            <ruri>$rcalendarpath1:/</ruri>
        </request>

This allowed the system to auto-provision the resource account

Content-type could use its own verifier

douglm@… originally submitted this as ticket:387

Tests fail because the content-type header value doesn't match but is actually valid, e.g. g test for

text/calendar;charset=utf-8

and receive

text/calendar; charset=UTF-8

The space(s) after the semi-colon are valid as is the UC "UTF-8"

This might be complicated enough to justify its own verifier

Extra cleanup in sharing-calendars.xml

douglm@… originally submitted this as ticket:518

Added something to delete the shared calendar...

    <request user="$userid1:" pswd="$pswd1:">
      <method>DELETE</method>
      <ruri>$calendarhome1:/shared/</ruri>
    </request>

ddf

arda@… originally submitted this as ticket:437

Keywords: ddf
radar: ddf

sharing remove is wrong

douglm@… originally submitted this as ticket:538

The remove elements in a number of files are incorrect. We have

    <CS:remove>
        <D:href>$cuaddr2:</D:href>
        <CS:summary>My Shared Calendar</CS:summary>
        <CS:read-write/>
    </CS:remove>

instead of

    <CS:remove>
        <D:href>$cuaddr2:</D:href>
    </CS:remove>

The incorrect files are

Resource/CalDAV/sharing/notification-sync/11.xml
Resource/CalDAV/sharing/invites/double/7.xml
Resource/CalDAV/sharing/invites/double/8.xml
Resource/CalDAV/sharing/invites/uninvitebad/3.xml
Resource/CalDAV/sharing/invites/uninvitebad/2.xml
Resource/CalDAV/sharing/invites/uninvitenew/1.xml
Resource/CalDAV/sharing/cache/3.xml
Resource/CalDAV/sharing/multiple/4.xml

PARTSTAT=NEEDS-ACTION not handled consistently

douglm@… originally submitted this as ticket:516

Got a failure on that value as:

+ATTENDEE;CN=User 02;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;SCHEDULE-STATUS=1.2:ma
+ ilto:[email protected]
 ATTENDEE;CN=User 01;PARTSTAT=ACCEPTED:mailto:[email protected]
-ATTENDEE;CN=User 02;RSVP=TRUE;SCHEDULE-STATUS=1.2:mailto:[email protected]
 ATTENDEE;CN=Resource 01;PARTSTAT=ACCEPTED;SCHEDULE-STATUS=2.0:mailto:resou


So I switched my system to not output the default partstat value - now it fails in other tests with 

+ATTENDEE;CN=User 03;RSVP=TRUE;SCHEDULE-STATUS=1.2:mailto:[email protected]
+ATTENDEE;CN=User 02;RSVP=TRUE;SCHEDULE-STATUS=1.2:mailto:[email protected]
 ATTENDEE;CN=User 01;PARTSTAT=ACCEPTED:mailto:[email protected]
-ATTENDEE;CN=User 02;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;SCHEDULE-STATUS=1.2:ma
- ilto:[email protected]
-ATTENDEE;CN=User 03;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;SCHEDULE-STATUS=1.2:ma
- ilto:[email protected]

Python warnings

douglm@… originally submitted this as ticket:564

Seeing messages like this:

----- Running Tests from "scripts/tests/CalDAV/sharing-peruser-data.xml"... ----- 
...
    Test Suite: Different freebusy                            

/home/douglm/drop2/calendar/apple/CalDAVTester-dist/verifiers/propfindItems.py:152: FutureWarning: The behavior of this method will change in future versions.  Use specific 'len(elem)' or 'elem is not None' test instead.
  if not prop:
        Test: 1                                              [OK] 

/home/douglm/drop2/calendar/apple/CalDAVTester-dist/verifiers/postFreeBusy.py:47: FutureWarning: This search is broken in 1.3 and earlier, and will be fixed in a future version.  If you rely on the current behaviour, change it to './{urn:ietf:params:xml:ns:caldav}response/{urn:ietf:params:xml:ns:caldav}calendar-data'
  for calendar in tree.findall("/{urn:ietf:params:xml:ns:caldav}response/{urn:ietf:params:xml:ns:caldav}calendar-data"):
        Test: 2                                              [FAILED]

Weak Cryptographic Hash

I found a reflective Weak Cryptographic Hash issue in the request.py
Details are as follows:

Weak cryptographic hashes cannot guarantee data integrity and should not be used in security-critical contexts.It is recommended to use SHA-224, SHA-256，SHA-384

More setup needed for CalDAV/implicitauto6.xml

douglm@… originally submitted this as ticket:396

This

       <request user="$useradmin:" pswd="$pswdadmin:">
            <method>DELETEALL</method>
            <ruri>$calendarpath1:/</ruri>
        </request>

needs adding to the startup for CalDAV/implicitauto6.xml

Previous tests can leave stuff lying around in the calendar

apple / ccs-caldavtester Goto Github PK

ccs-caldavtester's People

Contributors

Stargazers

Watchers

Forkers

ccs-caldavtester's Issues

Recommend Projects

Recommend Topics

Recommend Org