ну если по-хорошему делать то симметричаня подпись запроса, например. например как тут 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
