Всем привет! Может подойти простой вариант c HTTP Basic Auth:
curl -u "username:remotekey" -d "body=Hello+World" \ http://example.com/v1/entry где remotekey - отдельная сущность в настройках пользователя или эквивалентно паролю С уважением, Александр 22 сентября 2016 г., 14:35 пользователь Victor Efimov <vic...@vsespb.ru> написал: > ну если по-хорошему делать то симметричаня подпись запроса, например. > например как тут > http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html#ConstructingTheAuthenticationHeader > > 22 сентября 2016 г., 6:17 пользователь Anatoly Y <iskhart...@gmail.com> > написал: >> Привет. >> Если третьим лицам ничего делегировать не нужно. Используй подписанные куки, >> это надёжный, простой и удобный механизм. >> >> 2016-09-21 21:53 GMT+07:00 Alexey Shrub <worldm...@mail.ru>: >>> >>> Всем привет, >>> >>> вопрос не столько про перл, но думаю допустимый, нужно мне сделать 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 >>> moscow-pm@pm.org | http://moscow.pm.org >> >> >> >> -- >> Moscow.pm mailing list >> moscow-pm@pm.org | http://moscow.pm.org >> > -- > Moscow.pm mailing list > moscow-pm@pm.org | http://moscow.pm.org -- Moscow.pm mailing list moscow-pm@pm.org | http://moscow.pm.org