Нужно опубликовать для совместной работы календарь. Попробовал использовать связку acWeb+WebDav+SunBird.
В принципе для чтения работает. Но внести изменения не могу. Требует авторизации. Учетные записи из UserList не срабатывают.
Вообще как разделить доступ к календарю: одним только для чтения, другим для изменения?
Как это реализовать в acWeb?
Спасибо.
В логе acWEB.log должны появиться записи "UPLOADING..." и т.д. — реакция по умолчанию, заданная в acWEB\conf\http\PrePUT.rules.txt и acWEB\conf\http\PostPUT.rules.txt. Предполагается, что в PostPUT файл будет перемещаться туда, куда задумано админом — в публичный каталог, например (где на календарь могут подписаться другие).
Вот кусок из acWeb.log:
UPLOADING:..\script\control\wwwroot\my\
<?xml version="1.0"?>
<D:Propfind xmlns
..\script\control\wwwroot\my\test2.ics
/my/test2.ics
..\script\control\wwwroot\my\test2.ics*
<?xml version='1.0' encoding='utf-8'?>
<D:multistatus xmlns
<D:response xmlns:lp1='DAV:' xmlns:lp3='
<D:href>/my/test2.ics</D:href>
<D:Propstat>
<D:Prop>
<lp1:getcontentlength>118</lp1:getcontentlength>
<lp1:getcontenttype>text/xml</lp1:getcontenttype>
<lp1:creationdate>Tue, 06 May 2008 05:07:41 GMT</lp1:creationdate>
<lp1:getlastmodified>Tue, 06 May 2008 05:07:41 GMT</lp1:getlastmodified>
<lp1:resourcetype/>
<lp1:checked-in><D:href>/my/test2.ics</D:href></lp1:checked-in>
</D:Prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:Propstat>
<D:Propstat>
<D:Prop>
<g1:executable/>
<g0:checked-out/>
</D:Prop>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:Propstat>
</D:response>
</D:multistatus>
AcceptDirectory: .
AcceptDirectory: ..\CONF\pub\wwwroot
AcceptDirectory: ..\script\control\wwwroot
AcceptDirectory: ..\script\control\wwwroot\my
AcceptDirectory: ..\script\control\wwwroot
AcceptDirectory: ..\script\control\wwwroot\my
..\script\control\wwwroot\my\
UPLOADING:..\script\control\wwwroot\my\
<?xml version="1.0"?>
<D:Propfind xmlns
..\script\control\wwwroot\my\test2.ics
/my/test2.ics
..\script\control\wwwroot\my\test2.ics*
<?xml version='1.0' encoding='utf-8'?>
<D:multistatus xmlns
<D:response xmlns:lp1='DAV:' xmlns:lp3='
<D:href>/my/test2.ics</D:href>
<D:Propstat>
<D:Prop>
<lp1:getcontentlength>118</lp1:getcontentlength>
<lp1:getcontenttype>text/xml</lp1:getcontenttype>
<lp1:creationdate>Tue, 06 May 2008 05:07:41 GMT</lp1:creationdate>
<lp1:getlastmodified>Tue, 06 May 2008 05:07:41 GMT</lp1:getlastmodified>
<lp1:resourcetype/>
<lp1:checked-in><D:href>/my/test2.ics</D:href></lp1:checked-in>
</D:Prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:Propstat>
<D:Propstat>
<D:Prop>
<g1:executable/>
<g0:checked-out/>
</D:Prop>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:Propstat>
</D:response>
</D:multistatus>
AcceptDirectory: .
AcceptDirectory: ..\CONF\pub\wwwroot
AcceptDirectory: ..\script\control\wwwroot
AcceptDirectory: ..\script\control\wwwroot\my
AcceptDirectory: ..\script\control\wwwroot
AcceptDirectory: ..\script\control\wwwroot\my
.( UPLOADING
Тогда закачиваемый пользователем календарь будет попадать в общедоступную папку
- ошибки Sunbird больше не выдает, но и реального сохранения не происходит. К примеру, я хочу сохранит новое событие в календарь test2, расположенный в папке my. На эране в нужном месте календаря это событие появляется, в папке ics появляется календарь {User}.ics и все. После прохождения команды обновления удаленного календаря это событие с экрана пропадает.
Если подключить календарь {User}.ics то этого события нет и там.Вот кусок лога:
UPLOADING:..\script\control\wwwroot\my\
Upload result ior:0
AcceptDirectory: .
AcceptDirectory: ..\CONF\pub\wwwroot
AcceptDirectory: ..\script\control\wwwroot
AcceptDirectory: ..\script\control\wwwroot\my
AcceptDirectory: ..\script\control\wwwroot
AcceptDirectory: ..\script\control\wwwroot\my
<?xml version="1.0"?>
<D:Propfind xmlns
..\script\control\wwwroot\my\test2.ics
/my/test2.ics
..\script\control\wwwroot\my\test2.ics*
<?xml version='1.0' encoding='utf-8'?>
<D:multistatus xmlns
<D:response xmlns:lp1='DAV:' xmlns:lp3='
<D:href>/my/test2.ics</D:href>
<D:Propstat>
<D:Prop>
<lp1:getcontentlength>118</lp1:getcontentlength>
<lp1:getcontenttype>text/xml</lp1:getcontenttype>
<lp1:creationdate>Tue, 06 May 2008 05:07:41 GMT</lp1:creationdate>
<lp1:getlastmodified>Tue, 06 May 2008 05:07:41 GMT</lp1:getlastmodified>
<lp1:resourcetype/>
<lp1:checked-in><D:href>/my/test2.ics</D:href></lp1:checked-in>
</D:Prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:Propstat>
<D:Propstat>
<D:Prop>
<g1:executable/>
<g0:checked-out/>
</D:Prop>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:Propstat>
</D:response>
</D:multistatus>
Исправление обновления существующего календаря:
Еще нужен как минимум простейший контроль типа (расширения) записываемого файла, чтоб скрипты не закачали. Например, такой — полный PrePUT:
Т.е. если закачивается не *.ics, то принудительно уводим его из /my/. Или так:
Остался еще вопрос. Есть ли возможность разграничить права доступа к календарю: только для чтения и чтения-записи на уровне acWeb?
mixsv спасибо за тему
ac нужна небольшая статья по работе с SB
Статья о чем? Если просто о работе с SB, то тут все просто, а если про связку SB + acWEB + WebDav то можно конечно, только чуть позже, я сейчас в отпуске и за компьютер сажусь вечером раз в два дня.
Через недельку постараюсь в кратце описать как я это делал, если еще будет интересно.
Статья о связке "SB + acWEB + WebDav"
Ждем, интересно, спасибо.
Да. Чтобы запретить запись конкретного URL'а через WebDav в каталог /my/, можно добавлять правила в acWEB\conf\http\MyOnRequest2.rules.txt
Например запрет записи admin.ics не-админу:
Uri /my/admin.ics | LoggedAs: admin 0= | Forbidden \EOF или запрет записи someuser.ics, если авторизован не как someuser:
URI " /my/{User}.ics" STR@ ~= 0= | Unauthorized "{User} calendars" \EOF
ACTION =~ DavPutFile | URI " /my/{User}.ics" STR@ ~= 0= | Unauthorized "{User} calendars" \EOF
А
может уже готова?
А Eserv (любой версии, включая 2.x и даже 1.x) поддерживает публикацию iCal-календарей. WebDav для этого не нужен, т.к. команда PUT (используемая для публикации всеми календарными приложениями) появилась в HTTP еще до разработки DAV-расширений. Но все последние версии календарей для выяснения "а могу ли я публиковать в этот каталог" используют OPTIONS/PROPFIND, которые уже "dav'овые", поэтому в своё время потребовали доработки Eserv. В Eserv/2 реализован OPTIONS, но PROPFIND отсутствует. Т.е. SunBird'ом публиковать календари на Eserv/2 уже не получится. А на Eserv/3 и Eserv/4 получится.
Подписка на календари в случае iCal производится обычными GET-запросами, поэтому возможна во всех версиях Eserv. В CalDav календари хранятся в тех же iCal-форматах, но CalDav (в лице SunBird и Apple'овского календарей) предусматривает другой порядок подписки — указанием не конкретного календаря, а папки с календарями — список календарей в папке извлекается PROPFIND'ом, соответственно и поддержку версиями Eserv'а см. выше. Функционально с точки здения каледарного клиента между способом PUT/GET и PUT/PROPFIND разницы никакой (внутри один и тот же iCal). Технически второй способ слегка экономнее для клиента, но затратнее для серверных ресурсов (перебор содержимого каталога, каждое событие/задача попадает на сервере в отдельный ics-файл). В SunBird/Lightning при создании календарей лучше использовать iCal-метод, т.к. только в этом случае вы точно знаете, какой URL указать для подписки на тот же календарь в Windows Calendar или Outlook.
- Я знаю, в чем дело. Текущие версии стали использовать команду REPORT (вместо GET) для выборки конкретных элементов CalDAV-каталога. acWEB для совместимости уже подкручен, но в 3.35 этого патча еще нет, я с ним компилировал только acWEB из беты Eserv/4. Когда доберусь до основной рабочей машины (в понедельник ближе к вечеру) постараюсь собрать и выдать обновление acWEB.exe и для тройки.
Там в sunbird'овской реализации CalDAV недавно открылась еще одна проблема, которая врядли решаемая, т.к. скорее всего считается нормой (а жаль): если в одном каталоге перемешаны ics-файлы, опубликованные как в iCal-режиме, так и в CalDAV-режиме (на самом деле одной и той же командой PUT, т.e. для сервера-то "режим" без разницы и даже неизвестен), то при подписке на папку в CalDav-режиме — из iCal-календарей SunBird и Lightning показывает только первое событие, а остальные игнорирует. Потому что при добавлении событий в CalDav-режиме он каждое событие отправляет на сервер в виде отдельного файла — и в таком же виде ожидает обратно, не предполагая, что другие календарные клиенты (или тот же Sunbird в iCal-режиме) будут помещать туда файлы с несколькими событиями. Поэтому лучше не перемешивать, iCal и CalDAV, а выделять им отдельные каталоги: для общих календарей или списков задач, где всё в одной куче — использовать CalDAV, а для собственных todo и календарей, и для календарных клиентов, не понимающих CalDAV (т.e. MS*) — использовать iCal-файлы в собственных папках, и не пускать туда CalDAV.Но опять же имеется проблема. Apache, например, не дает перезаписать файл, пока не скачаешь последнюю версию этого файла. Т.е. если кто-то что-то записал в задание, другой не может добавить что-то свое пока не нажмет кнопочку Обновить. Насколько я понимаю, за подобное поведение отвечает модуль dav_lock acWeb, по крайней мере пока, таким функционалом не располагает. Есть ли такое в планах?
И, опять же, в CalDAV проблемы блокировок нет. И при описанном мною выше способе работы с iCal (у каждого _свой_ календарь, и каждый подписывается на календари интересующих его людей) тоже.