Короче блиать! я нашел способ доставать улицы любого горда на любом языке)

Сорь за маты - переволновался... 2 дня ибался.

Так что если кому надо

пишите)

вот мы сейчас с вами общаемся, это спам или флуд? или для вас это одно и то же?

Да обычная беседа

Короче блиать! я нашел способ доставать улицы любого горда на любом языке)

Выложите на гитхаб и киньте ссылочку :)

Со всем уважением) но времени сейчас на это нету)

Дедлайн позапрошлогодним воскресеньем января.

Вопрос такой возник: есть админ. система (Admin), ее API не является публичным, только для внутреннего использования в данный момент. Есть сервис аутентификации\авторизации (Auth). При определенных условиях, мне необходимо отправлять запрос из Auth в Admin для создания аккаунта пользователя. Auth сервис будет находится на своем сервере со своим IP-адрессом без прокси. Является ли нормальным решением на первое время проверять на стороне Admin-части с какого IP-адреса и домена пришел запрос, который я делаю из Auth-сервиса? Если, например, с айпи 999.99.999.999 и домена secure.domain.com, то разрешить дальнейшие действия.

@fes0r Если будет у Вас возможность, хотелось бы и ваше мнение узнать)

Запрос получается "внутренним", если можно так сказать, без редиректа.

Вопрос такой возник: есть админ. система (Admin), ее API не является публичным, только для внутреннего использования в данный момент. Есть сервис аутентификации\авторизации (Auth). При определенных условиях, мне необходимо отправлять запрос из Auth в Admin для создания аккаунта пользователя. Auth сервис будет находится на своем сервере со своим IP-адрессом без прокси. Является ли нормальным решением на первое время проверять на стороне Admin-части с какого IP-адреса и домена пришел запрос, который я делаю из Auth-сервиса? Если, например, с айпи 999.99.999.999 и домена secure.domain.com, то разрешить дальнейшие действия.

нет)

делай какую-нибудь сессию тогда

для "внутренних" запросов

пишите)

С какой базой работает?

отдает в CSV

а дальше сами

Откуда гребет-то?)

OSM

Спасибо. Возможно пригодится в ближайшее время.

делай какую-нибудь сессию тогда

Ну перед тем, как создать сессию для ресурса, мне надо его все равно идентифицировать получается. Или я не так вас понял)

Ну перед тем, как создать сессию для ресурса, мне надо его все равно идентифицировать получается. Или я не так вас понял)

т.е. ты хочешь вынести аутентефикацию совсем отдельно? SOA?

т.е. ты хочешь вынести аутентефикацию совсем отдельно? SOA?

Наверно не совсем SOA, сервис аутентфикации будет на отдельном домене, но пока что на одном сервере, и будет использовать одну базу данных.

т.е. ты хочешь вынести аутентефикацию совсем отдельно? SOA?

Я так понимаю, вы клоните к тому, чтобы создать сессию на стороне сервиса аутентификации, и потом просто посылать запрос на админ. сервис и уже там проверять, существует ли сессия?

Вопрос такой возник: есть админ. система (Admin), ее API не является публичным, только для внутреннего использования в данный момент. Есть сервис аутентификации\авторизации (Auth). При определенных условиях, мне необходимо отправлять запрос из Auth в Admin для создания аккаунта пользователя. Auth сервис будет находится на своем сервере со своим IP-адрессом без прокси. Является ли нормальным решением на первое время проверять на стороне Admin-части с какого IP-адреса и домена пришел запрос, который я делаю из Auth-сервиса? Если, например, с айпи 999.99.999.999 и домена secure.domain.com, то разрешить дальнейшие действия.

Если у тебя есть два доверяющих друг другу сервиса, и ты хочешь с одного послать запрос на другой, то есть такая клевая вещь как крипто подписи. Фишка в чем: ты раздаешь крипто ключи обоим сервисам, потом на клиенте ( в твоем случае Auth) подписываешь свое сообщение этим ключем, и добавляешь подпись к запросу. Сервер (Admin) смотрит запрос, и сравнивает подпись - если подпись настоящая, то доверяет запросу. Уже есть куча готовых либ (например тот же JWT токен), но можешь и сам велик наваять. Крипто можешь настраивать как хочешь - асинхронные ключи, синхронные и тд. Плюсы - будет работать надежно с любой топологией сети. Минусы - чуть сложнее чем просто проверка IP.

Если у тебя есть два доверяющих друг другу сервиса, и ты хочешь с одного послать запрос на другой, то есть такая клевая вещь как крипто подписи. Фишка в чем: ты раздаешь крипто ключи обоим сервисам, потом на клиенте ( в твоем случае Auth) подписываешь свое сообщение этим ключем, и добавляешь подпись к запросу. Сервер (Admin) смотрит запрос, и сравнивает подпись - если подпись настоящая, то доверяет запросу. Уже есть куча готовых либ (например тот же JWT токен), но можешь и сам велик наваять. Крипто можешь настраивать как хочешь - асинхронные ключи, синхронные и тд. Плюсы - будет работать надежно с любой топологией сети. Минусы - чуть сложнее чем просто проверка IP.

Рассматривал JWT токены. Синхронного ключа с последующим HMAC шифрованием для данного случая должно быть достаточно, как я понимаю?

Если у тебя есть два доверяющих друг другу сервиса, и ты хочешь с одного послать запрос на другой, то есть такая клевая вещь как крипто подписи. Фишка в чем: ты раздаешь крипто ключи обоим сервисам, потом на клиенте ( в твоем случае Auth) подписываешь свое сообщение этим ключем, и добавляешь подпись к запросу. Сервер (Admin) смотрит запрос, и сравнивает подпись - если подпись настоящая, то доверяет запросу. Уже есть куча готовых либ (например тот же JWT токен), но можешь и сам велик наваять. Крипто можешь настраивать как хочешь - асинхронные ключи, синхронные и тд. Плюсы - будет работать надежно с любой топологией сети. Минусы - чуть сложнее чем просто проверка IP.

Благодарю за ответ :) Ваш подход надежный и не очень трудный в реализации

combot.org/chat/-1001042383571

Рассматривал JWT токены. Синхронного ключа с последующим HMAC шифрованием для данного случая должно быть достаточно, как я понимаю?

я бы так сам брал.

я бы так сам брал.

Спасибо)

разбаньте @RmFloodUser и будет всегда активность, но какая!

я же не в бане. просто на js пока пишу и доковыриваю задачи. там я уже сам справляюсь и в логику и в код. возможно сюда напишу сегодня

значит read only был на некоторое время

Короче блиать! я нашел способ доставать улицы любого горда на любом языке)

тоже интересует. вообще щас задача связанная с адресами. я ее уже месяц пилю

тоже интересует. вообще щас задача связанная с адресами. я ее уже месяц пилю

что же за задача с адресами что вы ее месяц пилите. озвучьте, если не секрет

что же за задача с адресами что вы ее месяц пилите. озвучьте, если не секрет

ну там подписки, услуги , личный кабинет, определение адрреса в любом формате ввоода. > секрет

Спасибо. Возможно пригодится в ближайшее время.

меня тоже держите в курсе, мне это интересно

посмотрите в сторону кладр атм и регионы и города и адреса с домами и корпусами и координаты вроде даже есть

посмотрите в сторону кладр атм и регионы и города и адреса с домами и корпусами и координаты вроде даже есть

В кладр только Россия. Чем меня и заинтересовало то решение, что оно по миру. И было интересно, какую базу парсит.

посмотрите в сторону кладр атм и регионы и города и адреса с домами и корпусами и координаты вроде даже есть

а мне интересен ввод города на различныч языкач

мы юзали geonames когда-то

там за немного денег можно было скачать всю базу

а в максминде нет такой базы?

мы юзали geonames когда-то

OSM их и юзает

Geonames туфта полная.

нифига не структурированная фигня - про бесплатно.

про платно не знаю.

нифига не структурированная фигня - про бесплатно.

в смысле?

Ну всмысле ты их дампы качал?

бесплатные

мы работали с их апишкой

до покупки базы дело не дошло, нам апишки хватало

а есть бд где по индексу достать населенный пункт?

ну я дампы качал - апи как то не особо.

ну я дампы качал - апи как то не особо.

что не особо?

http://www.geonames.org/export/ws-overview.html

покажи где тут улицы получить

Это точечное апи - а мне общее надо.

вопрос был про улицы или города?

мне города нужны были)

а для улиц и геокодинга я гугловую апиху юзаю

я помню мы юзали АПИ гугла для определения валидности адресов в екоммерсе. вполне вменяемо работало даже по всему миру плюс-минус

но щас я не вспомню где у них дока по этому апи лежит и даже как оно зовется

у них же для апи есть песочница и норм доки

ку

$posts = Post::query() ->where('option', 1) ->where('message_validate', $message_validate)->get(); как обновить в колекции все записи кроме первой

$posts = Post::query() ->where('option', 1) ->where('message_validate', $message_validate)->get(); как обновить в колекции все записи кроме первой

Юзай not

:)

(:

Ребят, вопрос: стоит ли для основных сущностей в системе создавать интерфейсы? Например, сущности Company и User, и интерфейсы для них CompanyInterface и UserInterface. И везде тайпхинтить сами интерфейсы, а не классы сущностей. Или это лишний оверхед? з.ы. работаю с Doctrine, если это имеет какое-то значение.

Интерфейсы это поведение. То есть отвечают на вопрос "Какой"

Угу, а частный их случай - DI

Если вы не понимаете, зачем оно вам - значит пока не нужно

Ребят, вопрос: стоит ли для основных сущностей в системе создавать интерфейсы? Например, сущности Company и User, и интерфейсы для них CompanyInterface и UserInterface. И везде тайпхинтить сами интерфейсы, а не классы сущностей. Или это лишний оверхед? з.ы. работаю с Doctrine, если это имеет какое-то значение.

создавай интерфейсы только тогда когда ты понимаешь что у тебя больше одной реализации

или же для Dependency Inversion

и "понимаешь что болше одной реализации" это не "ну наверное" а вот понадобилось уже

банально делаем extract interface и вуаля

и заодно сможем конкретные классы уже лучше назвать с учетом их различий

Интерфейсы это поведение. То есть отвечают на вопрос "Какой"

не "Какой" а "Кто".

или что

существительные короч

а делать просто так интерфейсы не круто

так же не круто как добавлять суффикс Interface

traversable - действительно кто

Serializable да да существительное

так же не круто как добавлять суффикс Interface

Серега, чет тебя занесло. http://www.php-fig.org/bylaws/psr-naming-conventions/

так же не круто как добавлять суффикс Interface

Т.е., если его употребляешь, значит уже по сути интерфейс не надо)) Я кстати читал, что если название интерфейса и реализации одно и тоже, то интерфейс тоже не имеет смысла делать. Ну, в общем, если на данный и в ближайший момент не предполагается разные реализации, то интерфейс нету смысла добавлять. Ну разве что кроме интерфейся для репозиториев, по стандарту)

Серега, чет тебя занесло. http://www.php-fig.org/bylaws/psr-naming-conventions/

как же я так посмел нарушить святое писание

я беру PSR-1/PSR-2 и меняю пункты которые мне не нравятся. Это нормальная практика

получается стайлгайд в 3 предложения

Нет, это практика велосипедостроителя. И не стайлгайд, а stylefree

Т.е., если его употребляешь, значит уже по сути интерфейс не надо)) Я кстати читал, что если название интерфейса и реализации одно и тоже, то интерфейс тоже не имеет смысла делать. Ну, в общем, если на данный и в ближайший момент не предполагается разные реализации, то интерфейс нету смысла добавлять. Ну разве что кроме интерфейся для репозиториев, по стандарту)

интерфейс для репозиториев создается для того что бы инвертировать направление зависимостей. то есть DIP

Нет, это практика велосипедостроителя. И не стайлгайд, а stylefree

может это тебя занесло?)

ты слишком категоричен

"если не стандарт значит велосипед"

я это называю "надстройкой над стандартом"

Как у вас поведение отвечает на вопрос кто? То есть, интерфейс определяет что делать. И у вас это существительное?

от него то я не отказываюсь полностью, соблюдаю где-то на 95%