Files
jcoffey-dev 6efa90cfc1 Calendar: answer iTIP REFRESH and REPLY only from the event's attendees
An organizer's server sent the whole event, with every attendee, the
description and the location, to anyone who sent a REFRESH with the
event's UID, including attendees who had been removed and people who
were never invited. A REPLY for an instance the organizer hadn't
changed was stored as a new instance as long as the sender listed
itself as an attendee of the reply, so a removed attendee or a
stranger could add instances on any date, with any ORGANIZER parameters
and any other ATTENDEE lines; those attendees would then get the
organizer's next update.

A REFRESH is now answered only when the sender is an attendee of the
stored event. A REPLY for an unchanged instance needs the sender to be
an attendee of the series and the date to be one of the series' own
dates. The new instance takes its ORGANIZER, UID and SEQUENCE from the
organizer's copy and the sender's own ATTENDEE line with the answer
applied; only the people the sender delegated to are added from the
reply.

The recurring to-do test used a RECURRENCE-ID that is not a date of
its series; it now uses the series' second date.

Test: a REFRESH from someone never invited returned the full event on
main, and a removed attendee's REPLY created an instance; a REPLY that
added another attendee stored that attendee, and one for a date outside
the series stored it. Now each is refused or ignored and the
organizer's copy holds only the attendee's own answer.
2026-10-28 21:54:34 -07:00
..
2026-09-18 10:21:56 -07:00
2026-09-18 10:21:56 -07:00
2026-09-28 06:29:38 -07:00
2026-09-18 10:21:56 -07:00
2026-09-18 10:21:56 -07:00
2026-09-18 10:21:56 -07:00