2014-05-26 2 views
0

У меня есть многопользовательский веб-сайт и вы хотите опубликовать индивидуальный файл подписки icalendar (.ics) для каждого пользователя.Как я могу защитить подписку icalendar (.ics)?

Наш сервер Apache настроен только для обеспечения доступа по https.

Один из методов, который я рассмотрел, когда пользователь сначала запрашивает URL своей подписки, генерирует длинный случайный секретный ключ и включает его в URL-адрес. Затем хэш этого ключа будет сохранен в базе данных. Пример: https://site.com/calendar/user_id/dQXeCgtiOmZ5lAXoedmujiuA47VmCgA5OIfE6vZ8BhJT3Rxh20b9Ci.ics

Все страницы в нашем приложении cakephp требуют, чтобы пользователь вошел в систему (обязательно проверьте страницу входа в систему). Я бы сконфигурировал файл ics, чтобы также не требовать, чтобы пользователь вошел в систему, но отображался только тогда, когда был поставлен правильный секретный ключ (проверенный против хэша).

Есть ли недостатки в этом методе?

Есть ли другой способ, которым я должен пользоваться?

Я видел примеры людей, включая базовую аутентификацию в URL подписки, но похоже, что было бы хуже. Пример: https://user:[email protected]/calendar/user_id

Это развертывается в школьной среде, поэтому подписки iCalendar содержат довольно мирские вещи, такие как расписания занятий и даты назначений, но я все же хочу сохранить их в безопасности.

ответ

0

Недостаток добавления недействующих секретов к URL-адресам заключается в том, что они могут «течь» в другие системы. Все, что читает фид iCalendar, на самом деле не считает сам URL-адрес фида очень чувствительным, и эти URL-адреса могут храниться в тех частях системы, которые могут читать другие приложения.

Каналы iCalendar могут быть кэшированы, поэтому кэшированные копии этого канала + их секреты могут жить в локальных кешах браузера, корпоративных сетевых кэшах и других посредниках.

Когда пользователь впервые нажимает на URL-адрес, панели инструментов браузера могут регистрировать запрос и отправлять его также внешним сервисам.

Это всего лишь несколько векторов. Использование базового auth не хуже, просто не вставляйте его в URL-адрес и не требуйте от пользователя повторного ввода пароля.

Я не могу решить для вас, хотя это приемлемый риск. Мы используем секретные URL-адреса для некоторых вещей.