О, вы тоже переходите на RAML? А OpenAPI смотрели? Честно говоря RAML мне нравится значительно больше, в частности введением типов, но все-таки хочется больше мнений)
Немного беспокоит сосредоточение сильных мира сего вокруг OpenAPI - не хочется чтобы RAML загнулся...
Самый нормальный ответ. А то тут пошли то примеры с кодом на Go, то какие-то вопросы о стабильности (видимо только у меня Винда не бсодит каждые полчаса).
Денис Гончаренко
> А в диспетчере задач за это время память приложения увеличивается.
Это еще интереснее. Вы какую колонку-то смотрите? Там много разных, и показывают они разные вещи.
> Цель не единый вход, а единый аккаунт.
Давайте попробуем подробнее разобрать это утверждение, т.к. дело в терминах. Что для вас значит "единый аккаунт"? SSO обеспечивает перенос ответственности за аутентификацию на отдельный сервис. Если "аккаунт" для вас - это аутентификация, то SSO это таки единый аккаунт.
Возможно, для вас единый аккаунт - это единый центр информации о пользователе (фамилия, имя, почта, и т.д.). Некоторые реализации SSO также обеспечивают вас этой информацией (см. OpenID Connect, о котором мы с вами уже говорили).
Если же и это не ваше понятие "единого аккаунта", то тогда поясните).
Если вопрос не в безопасности, то этот хедер прекрасно вам подойдет. Когда еще в вебе с вопросами совместимости было совсем плохо, многие веб-сайты по юзер-агенту определяли, какой HTML лучше отдать клиенту, или не отдавать вообще, и сказать, что браузер устарел/не поддерживается сайтом. При этом браузеры, в свою очередь, начали косить друг по друга.. Так что это все как раз про вас, только у вас в роли клиента не браузер, а более узкоспециализированное приложение.
Иван Воробей
> К примеру есть клиенты на android и ios, появилась необходимость отключить приложение на ios.
Надежно - никак, по тем же причинам, что мы уже обсудили - все может будет подделать. Чел может сесть, собрать траффик, и отправить запросы вообще с ПК, и выдать себя за кого угодно.
Ненадежно - посылайте сами нужные заголовки из обоих приложений, User-Agent как раз для этого. Тогда вы сможете смотреть этот хедер и не обслуживать того, кого не хотите (т.е. сделать whitelist, а всех, кто не попадает в него - посылать), это будет работать для тех юзеров, кто не готов заморачиваться и что-то перехватывать.
И все-таки, хороший REST-сервис - тот, для которого клиент - ведь абстрактная. По сути, клиентское приложение - лишь инструмент упрощения жизни юзеру. С помощью клиентского приложения вы как бы избавляете человека от необходимости генерить HTTP-запросы вручную, не более того. Если нужно как-то ограничивать доступные ресурсы на сервисе - авторизуйте конкретного пользователя, плюс используйте rate limits, если нужно.
Иван Воробей Потому что надежное ограничение круга используемых клиентов задача довольно непростая, и редко оправдывается с точки зрения затрат. Возможно, у вас в клиенте реклама, и вы хотите чтобы её смотрели, тогда конечно в этом есть некоторый смысл. Если же вы это делаете ради безопасности, то это плохой путь к ней.
Попробуйте поработать с клиентскими сертификатами. Посмотрите, поддерживает ли http-клиент в вашем стеке технологий использование клиентского сертификата в TLS соединении. И вшейте потом приватный ключ в приложение, чтобы его сложнее было найти. Имхо, это единственный более-менее надежный вариант, т.к. все остальные велосипеды будут подвержены сниффингу и риплей атакам.
> Т.е. чтобы знать что запрос пришел именно от "своего" клиента (под клиентом я подразумеваю мобильное приложение).
Это не очень хорошая идея в принципе. Почему такая потребность возникла? Какова изначальная задача?
Я думаю человек интересуется тем, какую сортировку указать при построении индекса, чтобы СУБД использовала его при выполнении приведенного запроса. Зачем человеку такой запрос - другое дело. Обычно такие выборки по дате делаются...
Немного беспокоит сосредоточение сильных мира сего вокруг OpenAPI - не хочется чтобы RAML загнулся...