поддержка формата ошибок - PullRequest
0 голосов
/ 14 марта 2011

Я разрабатываю приложение, которое создает календарь компании с данными, полученными из других систем (это часть более крупного приложения J2EE, для экспорта календаря я использую ical4j).Одним из требований клиента было поместить «секретный токен» в ссылку синхронизации календаря, чтобы иметь возможность сбросить его, чтобы сделать ранее созданные ссылки для синхронизации календаря неиспользуемыми.Другими словами, это работает следующим образом:

  • пользователь нажимает кнопку «экспортировать ссылку» и видит ссылку для синхронизации календаря (которую можно вставить в iCal, календарь Google и т. Д.).Ссылка выглядит следующим образом:

(сервер / постоянная часть) + userName + секретный код (случайный, уникальный для каждого пользователя токен)

  • копия пользователяон и выполняет синхронизацию календаря со своим телефоном / другим устройством чтения календаря

  • после каждого запроса синхронизации (каждый раз, когда телефон запрашивает синхронизацию календаря) приложение проверяет, совпадает ли токен запроса с одним сохраненнымв базе данных (если токен действителен), и если да - календарь (* .ics файл) возвращается.

  • если, например, телефон украден, пользователь может сбросить этосекретный токен, и если телефон запрашивает у сервера синхронизацию календаря и токен из запроса и из базы данных будет другим, и календарь не будет возвращен.

У меня вопрос, есть ли возможность (iCalendarподдержка формата или любой другой способ отображения ошибок для пользователя (или чтобы они знали, что что-то пошло не так).Я имею в виду, что когда пользователь пытается синхронизировать календарь с неверным / просроченным токеном, все, что он / она увидит (проверено в thinderbird + lightning), это тот же старый календарь - без ошибок, без информации, что ничего не было обновлено и т. Д. (Единственное, что я могуget это запись в журнале на сервере).Некоторым полурешением было бы отправить пустой календарь, но это больше похоже на «взлом», чем реальное решение.

Спасибо за любую помощь.

1 Ответ

0 голосов
/ 14 марта 2011

Что ж, вы могли бы отправить 401 Несанкционированный HTTP-ответ (с новой строкой области), что может привести к тому, что клиент покажет диалоговое окно с паролем (снова).

(я не уверен, если не попробую, если 403 Forbidden сделает что-нибудь полезное в Lightning.)

...