<div dir="ltr"><div><div><div>Все зависит от степени желаемой безопасности.<br></div>Если апи общедоступное да еще с деньгами общается, то лучше подписывать все параметры в каждом запросе, как Виктор сказал.<br></div>Если внутреннее, то проще всего в реализации, добавление параметра-секрета к запросу. Для пущей безопасности секрет хешировать можно.<br><br></div><div>Всякие OAuth хороши, когда надо от юзера получить разрешение.<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">22 сентября 2016 г., 17:12 пользователь Aliaksandr Zahatski <span dir="ltr"><<a href="mailto:zahatski@gmail.com" target="_blank">zahatski@gmail.com</a>></span> написал:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Всем привет!<br>
<br>
Может подойти простой вариант c HTTP Basic Auth:<br>
<br>
curl -u "username:remotekey" -d "body=Hello+World" \<br>
     <a href="http://example.com/v1/entry" rel="noreferrer" target="_blank">http://example.com/v1/entry</a><br>
<br>
где remotekey - отдельная сущность в настройках пользователя или<br>
эквивалентно паролю<br>
<br>
С уважением,<br>
Александр<br>
<br>
<br>
22 сентября 2016 г., 14:35 пользователь Victor Efimov<br>
<<a href="mailto:victor@vsespb.ru">victor@vsespb.ru</a>> написал:<br>
<div class="HOEnZb"><div class="h5">> ну если по-хорошему делать то симметричаня подпись запроса, например.<br>
> например как тут<br>
> <a href="http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html#ConstructingTheAuthenticationHeader" rel="noreferrer" target="_blank">http://docs.aws.amazon.com/<wbr>AmazonS3/latest/dev/<wbr>RESTAuthentication.html#<wbr>ConstructingTheAuthenticationH<wbr>eader</a><br>
><br>
> 22 сентября 2016 г., 6:17 пользователь Anatoly Y <<a href="mailto:iskhartakh@gmail.com">iskhartakh@gmail.com</a>> написал:<br>
>> Привет.<br>
>> Если третьим лицам ничего делегировать не нужно. Используй подписанные куки,<br>
>> это надёжный, простой и удобный механизм.<br>
>><br>
>> 2016-09-21 21:53 GMT+07:00 Alexey Shrub <<a href="mailto:worldmind@mail.ru">worldmind@mail.ru</a>>:<br>
>>><br>
>>> Всем привет,<br>
>>><br>
>>> вопрос не столько про перл, но думаю допустимый, нужно мне сделать REST<br>
>>> сервис (кстати думаю попробовать<br>
>>> <a href="https://metacpan.org/pod/Mojolicious::Plugin::OpenAPI" rel="noreferrer" target="_blank">https://metacpan.org/pod/<wbr>Mojolicious::Plugin::OpenAPI</a>) и что-то у меня нет<br>
>>> ощущения уверенности в вопросе аутентификации.<br>
>>> API должно быть универсальным, а значит с ним должно быть удобно работать<br>
>>> и с мобильных устройств (из приложений), и из браузера (джаваскриптом) и с<br>
>>> серверов клиентов, тестирование curl'ом тоже должно быть удобным.<br>
>>> Прочитал несколько статей, но сильно яснее не стало, пока кажется что<br>
>>> обычные клиентские куки (подписанные или зашифрованные, полученные в обмен<br>
>>> на имя юзера и хешированный пароль) это оптимальный вариант.<br>
>>> Однако во всяких статьях часто упоминают про OAuth, пока не пойму будет ли<br>
>>> с него польза если нет необходимости показывать данные третьим лицам. Вроде<br>
>>> в OAuth 2 есть функционал аналогичный кукам, но имеет ли смысл непонятно, да<br>
>>> и неясно что в перле с поддержкой серверного OAuth 2, вроде есть<br>
>>> <a href="https://metacpan.org/pod/OAuth::Lite2" rel="noreferrer" target="_blank">https://metacpan.org/pod/<wbr>OAuth::Lite2</a> но какой в нём уровень поддержки не<br>
>>> написано, может кто юзал?<br>
>>><br>
>>> Другие варианты мне кажутся менее подходящими:<br>
>>> - Digest authentication - знаю что она более правильная чем Basic auth, но<br>
>>> не юзал, как понимаю она, как и basic auth, реализуется на уровне<br>
>>> веб-сервера, что делает менее удобным управление юзерами - надо из базы в<br>
>>> какой-то файлик переносить<br>
>>> - клиентские сертификаты это круто, но немного сложно для клиентов<br>
>>><br>
>>> Может у кого есть опыт в этом вопросе, основанные на этом опыте убеждения<br>
>>> и готовность ими поделится?<br>
>>><br>
>>><br>
>>> --<br>
>>> Moscow.pm mailing list<br>
>>> <a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" rel="noreferrer" target="_blank">http://moscow.pm.org</a><br>
>><br>
>><br>
>><br>
>> --<br>
>> Moscow.pm mailing list<br>
>> <a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" rel="noreferrer" target="_blank">http://moscow.pm.org</a><br>
>><br>
> --<br>
> Moscow.pm mailing list<br>
> <a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" rel="noreferrer" target="_blank">http://moscow.pm.org</a><br>
--<br>
Moscow.pm mailing list<br>
<a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" rel="noreferrer" target="_blank">http://moscow.pm.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">С уважением,<br>Иван</div>
</div>