> activitypub и задумывался для межсерверного взаимодействия, а не для клиент-серверного
Есть пруфы? Сам стандарт вот описывает и сервер-сервер, и клиент-сервер. Причем клиент-сервер даже упомянут первым.
Top-level
> activitypub и задумывался для межсерверного взаимодействия, а не для клиент-серверного Есть пруфы? Сам стандарт вот описывает и сервер-сервер, и клиент-сервер. Причем клиент-сервер даже упомянут первым. 2 comments
В явном виде в спеках этого не попадалось, но по-моему, это вытекает из того что по дефолту браузеры не могут получать джейсоны со сторонних доменов и по дефолту на AP инстансах этот хедер не включён. Почему большинство AP движков по дефолту не включают хз, возможно, как я уже предположил выше, чтобы минимизироать трафик: запрашивая инфу через свой инстанс, инфа сперва ищется в кеше твоего инстанса, а уже потом запрашивается со стороннего. |
@top
> А ставить ли хедер access-control-origin зависит от того, хочет ли админ сервера чтобы запросы могли слать посторонние.
Запросы _уже шлют_ посторонние, просто это не браузеры, а другие серверы. К примеру, перкзапросить activity по ее id по HTTPS - один из стандартных способов подтвердить ее достоверность, если она не была подписана. А если была - то запросить профиль ее автора, чтобы получить его публичный ключ и валидировать эту подпись.
А говорить "это API публично, но только если ты шлёшь запросы не из браузера" очень нелогично и непоследовательно, как по мне.
@top
> А ставить ли хедер access-control-origin зависит от того, хочет ли админ сервера чтобы запросы могли слать посторонние.
Запросы _уже шлют_ посторонние, просто это не браузеры, а другие серверы. К примеру, перкзапросить activity по ее id по HTTPS - один из стандартных способов подтвердить ее достоверность, если она не была подписана. А если была - то запросить профиль ее автора, чтобы получить его публичный ключ и валидировать эту подпись.