Денис Гончаренко
> А в диспетчере задач за это время память приложения увеличивается.
Это еще интереснее. Вы какую колонку-то смотрите? Там много разных, и показывают они разные вещи.
> Цель не единый вход, а единый аккаунт.
Давайте попробуем подробнее разобрать это утверждение, т.к. дело в терминах. Что для вас значит "единый аккаунт"? SSO обеспечивает перенос ответственности за аутентификацию на отдельный сервис. Если "аккаунт" для вас - это аутентификация, то SSO это таки единый аккаунт.
Возможно, для вас единый аккаунт - это единый центр информации о пользователе (фамилия, имя, почта, и т.д.). Некоторые реализации SSO также обеспечивают вас этой информацией (см. OpenID Connect, о котором мы с вами уже говорили).
Если же и это не ваше понятие "единого аккаунта", то тогда поясните).
Если вопрос не в безопасности, то этот хедер прекрасно вам подойдет. Когда еще в вебе с вопросами совместимости было совсем плохо, многие веб-сайты по юзер-агенту определяли, какой HTML лучше отдать клиенту, или не отдавать вообще, и сказать, что браузер устарел/не поддерживается сайтом. При этом браузеры, в свою очередь, начали косить друг по друга.. Так что это все как раз про вас, только у вас в роли клиента не браузер, а более узкоспециализированное приложение.
Иван Воробей
> К примеру есть клиенты на android и ios, появилась необходимость отключить приложение на ios.
Надежно - никак, по тем же причинам, что мы уже обсудили - все может будет подделать. Чел может сесть, собрать траффик, и отправить запросы вообще с ПК, и выдать себя за кого угодно.
Ненадежно - посылайте сами нужные заголовки из обоих приложений, User-Agent как раз для этого. Тогда вы сможете смотреть этот хедер и не обслуживать того, кого не хотите (т.е. сделать whitelist, а всех, кто не попадает в него - посылать), это будет работать для тех юзеров, кто не готов заморачиваться и что-то перехватывать.
И все-таки, хороший REST-сервис - тот, для которого клиент - ведь абстрактная. По сути, клиентское приложение - лишь инструмент упрощения жизни юзеру. С помощью клиентского приложения вы как бы избавляете человека от необходимости генерить HTTP-запросы вручную, не более того. Если нужно как-то ограничивать доступные ресурсы на сервисе - авторизуйте конкретного пользователя, плюс используйте rate limits, если нужно.
Иван Воробей Потому что надежное ограничение круга используемых клиентов задача довольно непростая, и редко оправдывается с точки зрения затрат. Возможно, у вас в клиенте реклама, и вы хотите чтобы её смотрели, тогда конечно в этом есть некоторый смысл. Если же вы это делаете ради безопасности, то это плохой путь к ней.
Попробуйте поработать с клиентскими сертификатами. Посмотрите, поддерживает ли http-клиент в вашем стеке технологий использование клиентского сертификата в TLS соединении. И вшейте потом приватный ключ в приложение, чтобы его сложнее было найти. Имхо, это единственный более-менее надежный вариант, т.к. все остальные велосипеды будут подвержены сниффингу и риплей атакам.
> Т.е. чтобы знать что запрос пришел именно от "своего" клиента (под клиентом я подразумеваю мобильное приложение).
Это не очень хорошая идея в принципе. Почему такая потребность возникла? Какова изначальная задача?
Я думаю человек интересуется тем, какую сортировку указать при построении индекса, чтобы СУБД использовала его при выполнении приведенного запроса. Зачем человеку такой запрос - другое дело. Обычно такие выборки по дате делаются...
Иван Воробей ну в OIDC подписанный веб-токен и передаётся) Так что вполне можно и самому попробовать это реализовать. Стандарт можно использовать как ориентир, и выкинуть лишнее.
Иван Воробей
OpenID Connect ( openid.net/connect ) - стандарт аутентификации поверх протокола OAuth . Если говорить грубо, то создавался с целью заменить кнопочки Login by Google, Login by Facebook и прочие самописные протоколы аутентификации на базе OAuth на единое соглашение. Не путать с классическим OpenID, это совершенно разные вещи.
DancingOnWater я скорее про лямбду в целом, а не про аргументы. Один аргумент действительно не берут в скобки, а вот лямбду целиком можно бы. И не объявляйте лишний раз несколько переменных на одной строке, если названия не короткие вроде i, j. Тем более, если одна из переменных инициализируется - тогда вообще не сразу понимаешь, что рядом делает вторая переменная.
Павел Никитин все-таки я предлагаю сначала конфигурацию игрового сервера глянуть. Если там ip-шник прописан, в этом и может заключаться проблема, его нужно сменить. Все-таки дело в виндовой машине, раз порты не открываются на прослушку. А, еще проверьте, не занят ли нужный порт кем-то еще. Это маловероятно, но чем черт не шутит.
Также, ВОЗМОЖНО, дедик пытается слушать на IPv6-интерфейсе, который почему-то выбирает по-умолчанию, такое тоже бывает. И поэтому вы не видите прослушиваемых TCP-портов. Возможно стоит прописать конкретный IP, если это еще не было сделано.
