Эта структура:
route {
before MyBasicAuth.new;
post -> LoggedInUser $user, 'api' {
...
}
}
Зависит от новой семантики before / after в следующей версии Cro 0.8.0. В текущем выпуске Cro на момент запроса / записи - и предшествующих ему - before в блоке route будет применяться только к маршрутам, которые уже были сопоставлены. Однако это было слишком поздно для промежуточного программного обеспечения, которое должно было повлиять на то, что будет соответствовать . Способ сделать это до Cro 0.8.0 - это либо смонтировать промежуточное ПО на уровне сервера, либо сделать что-то вроде этого:
route {
before MyBasicAuth.new;
delegate <*> => route {
post -> LoggedInUser $user, 'api' {
...
}
}
}
Что обеспечивает применение промежуточного программного обеспечения перед рассмотрением любого соответствия маршрута. Это не так красиво, поэтому изменения в предстоящем 0.8.0 (который также представит before-matched с оригинальной семантикой before).
Наконец, forbidden without $success; здесь не сработает. Подпрограмма forbidden является частью Cro::HTTP::Router и предназначена для использования в обработчиках маршрутизации, тогда как промежуточное ПО не привязано к маршрутизатору (так что вы можете решить направлять запросы другим способом, например, не теряя возможности использовать все промежуточное программное обеспечение). Контракт метода authenticate заключается в том, что он возвращает истинное значение, определяющее, что должно произойти; это не подходящее место, чтобы попытаться использовать другой код ответа.
Ошибка соответствия ограничения авторизации, например LoggedInUser, приведет к 401. Чтобы переписать это, добавьте after в самый внешний блок route, чтобы отобразить его:
route {
before MyBasicAuth.new;
after { forbidden if response.status == 401; }
delegate <*> => route {
post -> LoggedInUser $user, 'api' {
...
}
}
}