Все зависит от степени желаемой безопасности. Если апи общедоступное да еще с деньгами общается, то лучше подписывать все параметры в каждом запросе, как Виктор сказал. Если внутреннее, то проще всего в реализации, добавление параметра-секрета к запросу. Для пущей безопасности секрет хешировать можно.
Всякие OAuth хороши, когда надо от юзера получить разрешение. 22 сентября 2016 г., 17:12 пользователь Aliaksandr Zahatski < [email protected]> написал: > Всем привет! > > Может подойти простой вариант c HTTP Basic Auth: > > curl -u "username:remotekey" -d "body=Hello+World" \ > http://example.com/v1/entry > > где remotekey - отдельная сущность в настройках пользователя или > эквивалентно паролю > > С уважением, > Александр > > > 22 сентября 2016 г., 14:35 пользователь Victor Efimov > <[email protected]> написал: > > ну если по-хорошему делать то симметричаня подпись запроса, например. > > например как тут > > http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html# > ConstructingTheAuthenticationHeader > > > > 22 сентября 2016 г., 6:17 пользователь Anatoly Y <[email protected]> > написал: > >> Привет. > >> Если третьим лицам ничего делегировать не нужно. Используй подписанные > куки, > >> это надёжный, простой и удобный механизм. > >> > >> 2016-09-21 21:53 GMT+07:00 Alexey Shrub <[email protected]>: > >>> > >>> Всем привет, > >>> > >>> вопрос не столько про перл, но думаю допустимый, нужно мне сделать REST > >>> сервис (кстати думаю попробовать > >>> https://metacpan.org/pod/Mojolicious::Plugin::OpenAPI) и что-то у > меня нет > >>> ощущения уверенности в вопросе аутентификации. > >>> API должно быть универсальным, а значит с ним должно быть удобно > работать > >>> и с мобильных устройств (из приложений), и из браузера (джаваскриптом) > и с > >>> серверов клиентов, тестирование curl'ом тоже должно быть удобным. > >>> Прочитал несколько статей, но сильно яснее не стало, пока кажется что > >>> обычные клиентские куки (подписанные или зашифрованные, полученные в > обмен > >>> на имя юзера и хешированный пароль) это оптимальный вариант. > >>> Однако во всяких статьях часто упоминают про OAuth, пока не пойму > будет ли > >>> с него польза если нет необходимости показывать данные третьим лицам. > Вроде > >>> в OAuth 2 есть функционал аналогичный кукам, но имеет ли смысл > непонятно, да > >>> и неясно что в перле с поддержкой серверного OAuth 2, вроде есть > >>> https://metacpan.org/pod/OAuth::Lite2 но какой в нём уровень > поддержки не > >>> написано, может кто юзал? > >>> > >>> Другие варианты мне кажутся менее подходящими: > >>> - Digest authentication - знаю что она более правильная чем Basic > auth, но > >>> не юзал, как понимаю она, как и basic auth, реализуется на уровне > >>> веб-сервера, что делает менее удобным управление юзерами - надо из > базы в > >>> какой-то файлик переносить > >>> - клиентские сертификаты это круто, но немного сложно для клиентов > >>> > >>> Может у кого есть опыт в этом вопросе, основанные на этом опыте > убеждения > >>> и готовность ими поделится? > >>> > >>> > >>> -- > >>> Moscow.pm mailing list > >>> [email protected] | http://moscow.pm.org > >> > >> > >> > >> -- > >> Moscow.pm mailing list > >> [email protected] | http://moscow.pm.org > >> > > -- > > Moscow.pm mailing list > > [email protected] | http://moscow.pm.org > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org > -- С уважением, Иван
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
