Писать в техподдержку Яндекс карт — по опыту за 10 лет — не эффективно, ощущение что там только один разработчик который тянул весь проект. На самом деле, вместо Сбербанка — золотую акцию надо было дать этому разработчику и ещё пару процентов обычных.
«Как оно работает» с JS API карт
Компания или разработчик регистрируется в личном кабинете разработчиков Яндекса. И создаёт ключ (похож на UUID). Ключ не имеет никаких настроек (Домен, лимиты и т.д.) и служит только для разделения тарификации.
На странице где требуются функции карт — вставляется JS скрипт и API ключ: (URL для «платной» версии может отличаться).
<head>
<script src="https://api-maps.yandex.ru/2.1/?apikey=ваш API-ключ&lang=ru_RU" type="text/javascript">
</script>
</head>
Заметили? Нет? Следите за пальцами:
- Ключ является публичным. (АЛЛО! какой нафиг биллинг по публичному API ключу?).
- На ключе отсутствуют настройки (Привязки к домену, сервису, лимиты).
- Любой может взять ваш ключ и использовать в любых целях (это не запрещено законом, вы сами его публикуете на своей странице и рандомный хеш не является объектом авторского права).
Далее статью можно было бы не писать. Но мы ведь за добро и за своё бабло, учитывая что размещая этот ключ — оно тратится третьими лицами.
Давайте подумаем, что нужно сделать папе(не биологическому, но всё же) рунета (и тому герою-разработчику), чтобы дети не страдали:
- Одна карта — один ключ (https://www.mapbox.com/).
Ключ относится к конкретной карте. В настройках ключа прописываются разрешённые домены (не забудьте про wildcard). По ключу запрещается геокодирование через HTTP API. - Лимиты запросов.
Я не хочу попасть на деньги из-за злоумышленников. - Авторизация к ключу / Приватный ключ.
Я хочу ключ для своих сервисов которые используют геокодинг и отдельный биллинг по ним.Я не хочу чтобы джун залез в ЛК и взял мой ключ для публичной карты.
Пока это всё отсутствует — любой может взять ваш ключ и геокодить в удовольствие.
Всем добра и берегите свои ключи =)
Комментарии (70)
freeExec
20.11.2019 20:55+2В настройках ключа прописываются разрешённые домены
В подавляющем большинстве ключи заимствуют не для своего сайта, чтобы по-быстрому выкачать тайлы или геокодировать сотню тысяч адресов. А добавить в скрипт нужный referer не составляет труда.
ReDev1L Автор
20.11.2019 21:25В этом и проблема что на одном ключе и геокодинг и фичи карты.
Настройки доменов (CORS) — для запрета встраивания карты на другой сайт, а геокодирование — по другому ключу.
С тайлами проблемы нет — открыть их в паблик доступ без ключа =)freeExec
21.11.2019 09:01Так геокодировать то же ведь на сайте надо и ключ будет доступен пользователю. Нет никакого смысла разделять ключи, ну только лишь для статистики.
ReDev1L Автор
21.11.2019 10:43Проксировать геокодирование через бекенд?)
freeExec
21.11.2019 10:48Ну я тогда у себя в скрипте адрес яндекса на ваш поменяют. А вам кроме того, что яндексу платить, ещё и за собственный сервак придётся раскашелится.
ReDev1L Автор
21.11.2019 11:03Не поменяют, потому что сессии и csrf =)
Upd:
Геокодировать через бекенд дешевле, т.к. можно держать кеш до 30 дней по условиям использования. (зависит от вашей нагрузки)freeExec
21.11.2019 11:14Защитит разве что от wget, но ни как не от скрипта.
ReDev1L Автор
21.11.2019 11:51Быстрее будет сделать несколько ключей, чем проходить csrf. Я понимаю что это щит и меч и борьба до бесконечности. Но на своём бекенде можно делать рейт лимиты и блэк листы. В общем это лучше чем просто ключ наружу и геокод с фронта, лучше в плане защиты от добрых соседей.
Можно геокодить только после рекапчи, относительно новая — без ввода символов и чекбоксов.
Конечно если хочешь это все обходится, но это вопрос ресурсов, я бы просто взял другой или создал несколько аккаунтов. Меньше кода — лучше.
starkeen
21.11.2019 09:06К сожалению, не спасает даже если разнести ключи — биллинг прибит не к ключу, а к аккаунту.
YetAnotherSlava
20.11.2019 23:40+2Зато в Яндексе гномики на собеседованиях, сортировка чего-то на куче разных узлов и тому подобное. Я бы с удовольствием задал собеседующим встречные вопросы, например про права доступа на NTFS и о системах разделения доступа вообще. Но к сожалению, давить на собеседующих возможно только при личной встрече, а не по скайпу.
justboris
20.11.2019 23:42Задачки про гномиков спрашивают у программистов, а авторизацию к API придумывают менеджеры. Вот как-то так и выходит.
denisromanenko
21.11.2019 08:10Ваши менеджеры случайно собачью чумку не разносят?
А молоко от их присутствия не киснет?
А то бедные менеджеры прямо во всём виноваты, прямо выгребная яма ответственности, всё туда можно спихнуть.starkeen
21.11.2019 09:04Вы, наверное, менеджер? С вашей точки зрения аргументация в таком случае понятна. Но, увы, согласиться с ней трудно.
denisromanenko
21.11.2019 10:35+1Нет, я слава богу вообще далёк от всей «офисной разработки». Просто меня всегда поражало детское нежелание многих встречающихся (в жизни, в интернете) программистов отвечать за свои косяки и солидарная уверенность что все беды не из-за них.
1. Много костылей — это менеджеры торопили.
2. Идиотская дыра в безопасности — да это менеджеры приказали забить на безопасность, надо новую версию выпускать.
3. 5 лет не фиксится баг в 1С — да там менеджеры вообще за работой твоей не следят, зачем стараться, взял фичу-однодневку из таск-трекера и пилишь её месяц.
4. Да наш PM следит постоянно за нами, проводит проверки, постоянно пальцами тыкает в косяки, так ни в какой «поток» не войдёшь.
Много следят за тобой менеджеры — плохо, мало следят — плохо, торопят — плохо, не торопят — плохо. Ну чёт везде прям плохие они, менеджеры эти.
Вот и в случае API карт — вот прямо менеджер сказал — «в скрипте оставьте свободно, чтобы кто угодно мог использовать». Вот прям словами, приказом? А что, даже в таком случае умного техлида не хватило подойти и сказать «ребят, чушь творим, Гугл по другому делает».
В этом смысле некоторые программисты мало чем отличаются от, допустим, отделочников-забулдыг, у которых виноват бригадир, заказчик, предыдущий отделочник, «кисть не дают, туды её в качель».
При этом каждый второй в комментариях и статьях наделяет своё ремесло просто невероятной важностью, мнит себя строителем цифровых вселенных и вдохновенно надувает щёки как лягушка-бык.
freeExec
21.11.2019 10:45-1Расскажите нам про гугл
UserAd
21.11.2019 14:06Тут скорее проблема в том, что многие программисты не будут никогда использовать то, что они делают. Поэтому автоматически на многие кейсы выключают мозг. Я сам видел (и продолжаю довольно часто видеть) JOIN 4х таблиц по 1-5M записей так как на их стендах все было почищено и в табличках по 100 записей максимум. А на вопрос «почему такое решение было выбрано» я получаю ответ «ну так же быстрее и красивее».
Superl3n1n
21.11.2019 14:48+1Тут дело в том, что есть дилемма, сделать быстро или сделать качественно. И выбор как делать лежит именно на заказчике (менеджер, управленец). И из этого и получается:
— Нужно по быстрому слепить систему на коленке, разве это сложно?
— Совсем не сложно. Какие требования к ней?
— Никаких, лишь бы работало. Это все равно будет общедоступная система для всех.
Через время:
— Нужно добавить следующие функции (перечень функций для внедрения которых необходимо значительно переделывать всю структуру проекта)
— Тут два варианта, первый быстрые костыли за N времени (но возможно в ущерб отказоустойчивости), или второй основательное переделывание проекта за N*M времени. Какой выбираем?
— Нам нужно это срочно, по этому первый вариант.
Еще через время все возмущаются, почему система иногда не работает или работает так криво! А потому, что изначально система создавалась совсем для другого. Как программисты могут наперед увидеть хотелки менеджеров?lorc
21.11.2019 15:08+1Как программисты могут наперед увидеть хотелки менеджеров?
Отвечу как программист программисту. Нужно спросить у них об этом наперед. Словами через рот. «Что может понадобиться в будущем? Как вы видите законченную систему? Если я сделаю вот так, то потом мы не сможем поддерживать больше чем 100 клиентов. Вас такое устроит? А вы случайно не захотите потом добавить Х? А как насчет Y?».
Neikist
21.11.2019 15:36После таких вопросов обычно идет ответ: конечно нас все устраивает в быстром и дешевом варианте. А через пол года/год приходят и требуют «немного» доработать и оптимизировать. «Всех все устраивает, но почему-то под нагрузкой висит, надо бы чтобы на выросшем количестве пользователей так же работало. Ты там день другой посиди, оптимизируй чтобы все ок было».
lorc
21.11.2019 15:49«Но я же вам сразу говорил что мы не сможем поддерживать больше чем 100 пользователей. Мне нужно несколько недель на то чтобы переделать архитектуру и протестировать новые изменения. Вот более детальный work breakdown с эстимейтами.»
Magikan
23.11.2019 13:04так ответ же очевиден: нет! это надо вот только сейчас, ровно на 1 раз и ни кто этим пользоваться не будет. Проблема не в том, что программисты не умеют говорить ртом с манагерами (хоть эта проблема тоже имеет место быть), проблема в том, что сами манагеры зачастую не знают ответов тк хотелки прилетают откуда-то сверху.
foxez
21.11.2019 18:31Тут слегка размытая область ответственности, но если придерживаться проактивной позиции, то заказчик не должен быть компетентен во всем. Это задача специалиста — сигнализировать и доводить до осознания риски того или иного решения.
Superl3n1n
22.11.2019 04:08Рассказав заказчику о гипотетических рисках, заказчик оптимист и рассчитывает, что такая ситуация никогда не настанет, потому что при расчете бюджета при выборе экономить или нет, задача экономить ставится в приоритет.
А когда подобный форс-мажор наступает, то исполнитель и как программист плохой, потому что система не работает, и как специалист — не смог донести риски.
ne_kotin
21.11.2019 12:26А то бедные менеджеры прямо во всём виноваты
Дык, постановкой задач кто занимается? Менеджерье. Значит оно и виновато.denisromanenko
21.11.2019 12:38+1Ну если задачи нужно действительно ставить так, чтобы до человека дошло и он нигде не прошляпился, то это такие программисты действительно не лучше и не ценнее неопытного разнорабочего-подёнщика.
Потому что профессионалу можно сказать.
1. «Вон там на объекте №3 квартира 25, заштукатурь её по-красоте».
А он ещё позвонит и скажет, что сейчас окон и дверей нет и штукарить нельзя, а то высохнет плохо из-за сквозняка. Ты себя по голове ударишь — точно, совсем из головы вылетело.
А если нужно говорить вот так, чтобы потом не натыкаться на проблемы, то дело наверное ещё и в исполнителе?
2. «Вон там объект № 3, ну всмысле не помнишь, видишь, где синий кран стоит, там на четвёртом этаже хата, в которой вы в прошлый раз дверь ставили, помнишь? Ну вы ещё ломом полотно пробили и обналичку замарали, вспомнил? Ну вот, там надо стены заштукатурить, мешки на складе, мешать то хоть помнишь как? 3 к 1, и воду тепловатую, а не горячую как тогда! Только розетки не замажь, и тазик потом не забудь отмыть, а то всё колом встанет.»ne_kotin
21.11.2019 12:53-3Ну если задачи нужно действительно ставить так, чтобы до человека дошло и он нигде не прошляпился, то это такие программисты действительно не лучше и не ценнее неопытного разнорабочего-подёнщика.
Сорян, телепаты в отпуске.
Приходит такой менеджер и говорит — «Надо сделать авторизацию в API». При этом бизнесовый смысл не озвучивает. Или может вообще не знает сам. Ок, вот тебе механизм API-ключей, которые эмитируются через ЛК.
А потом уже выясняется что по ключам хотели биллить клиентов. А для этого нужен еще SWOT анализ, выработка решений, ограничивающих злонамеренное использование.
Так что, дорогие менеджеры, приносите свои хотелочки вместе с бизнесовым контекстом — получите желаемое, а не минимально удовлетворительный функционал.balexa
21.11.2019 14:58«Надо сделать авторизацию в API». При этом бизнесовый смысл не озвучивает. Или может вообще не знает сам. Ок, вот тебе механизм API-ключей, которые эмитируются через ЛК.
А потом уже выясняется что по ключам хотели биллить клиентов.
Ну ок, менеджер ничего не знает. Это тоже не в пользу компании говорит, ну да ладно. Ну вот один такой плохой менеджер, не успели уволить.
Но дальше то что? Т.е. вначале разработчик решает авторизовать по публичным ключам, а потом уже по тем же самым ключам делает биллинг клиентов? И этот разработчик был один? Или все же там была команда? И никто из этой команды не сказал «ребят, а не херню ли мы делаем?»ne_kotin
21.11.2019 15:54-1Что заказали — то и получили, какие проблемы то?
denisromanenko
21.11.2019 16:21+1Ну вот таких программистов скоро и заменит искусственный интеллект. С простыми вещами он справится. Менеджер ему так по-простому скажет — «ИИ, а сделай мне к работающему движку API для клиентов, чтобы он им ключики выдавал» — тот ему и выдаст результат за две секунды. Да, простой, с уязвимостью, ну такой же как ему бы дал программист «что заказал — то и получил».
А сложные вещи с ним доработает настоящий программист, который может продумать сценарии использования наперёд и обсудить с менеджером, чтобы добиться наилучшего результата.
Тысячи высокообразованных луддитов, которые не хотят думать на пользу дела и просчитывать последствия, а хотят только переводить тупой запрос в тупой код пойдут на митинги и будут громить датацентры.
А раньше над теми таксистами смеялись, которые думать не хотят, а хотят только баранку крутить задорого. Времена «баранок задорого» в IT закончатся быстрее, чем в других сферах.
Здесь не все такие умные, как им хочется казаться, едва какой-нибудь электронный мозг научится вставлять в кодовую базу копипасты со StackOverflow — половину «миддлов» сразу можно выносить из офиса.ne_kotin
21.11.2019 16:39А сложные вещи с ним доработает настоящий программист, который может продумать сценарии использования наперёд
Для этого у программиста должна быть перед глазами джира с юзерстори, где зафиксировано — в чем бенефит задачи, какие критерии приемки, и так далее.
И вообще говоря, продумывать сценарии — это задача бизнес-аналитика, а программиста — реализовывать в терминах используемого языка программирования и фреймворка.
Ну вот таких программистов скоро и заменит искусственный интеллект. С простыми вещами он справится.
Была такая баечка. По факту «искусственный интеллект» оказался толпой то ли индусов, то ли китайцев.
Еще раз: что менеджер принес в клювике — то он и получит. Угадывать что он хотел, бегать за ним — никто не обязан, своей работы хватает.
Если из менеджера надо клещами вытягивать суть задачи, ценность для заказчика, место фичи в роадмапе продукта — пусть менеджер страдает и получает ровно то, что просил. Особенно, если в цепочке отсутствуют бизнес-аналитик и архитект.denisromanenko
21.11.2019 16:50Ну значит в будущем не будет человека по профессии «кодер» в конце цепочки разработки, для которого самое главное это в VS code писать строчки с нужным отступом и не забывать про ";".
На бизнес-аналитике закончится, который будет формулировать задачи для ИИ развёрнуто. Вообще это будет наверное как code-as-service — бот-разработчик подключается к вашей базе на гихабе, а ты ему просто формулируешь развернутые задачи. Не смейтесь, машины водить мы ИИ научим, а писать код без обязательств? Ещё проще.
Представляете, как здорово станет, если в компании не останется посторонних людей, не заинтересованных в качестве конечного продукта? :)ne_kotin
21.11.2019 16:59-1Представляете, как здорово станет, если в компании не останется посторонних людей, не заинтересованных в качестве конечного продукта?
Особенно мутного менеджерья, который носит задачи по каплям и из которого надо вытягивать подробности клещами.
Вообще это будет наверное как code-as-service — бот-разработчик подключается к вашей базе на гихабе, а ты ему просто формулируешь развернутые задачи.
А вы смешной. Самое трудоемкое в машинном обучении — это разметка датасетов и тренировка.
Типовые CRUD-ы сейчас например по схеме базы уже можно генерить, но как только вам надо шаг вправо-влево — извольте платить кожаному мешку.
Ну, и развивать и поддерживать реализации таких ботов тоже кто-то будет ручками.
Так что без работы не останемся.
Но если у постановщика каша в голове и во рту — не надо обижаться, что обратно постановщик получает вторую производную этой каши.denisromanenko
21.11.2019 17:05Нет-нет, что вы — программисты конечно будут, и много! Хорошие, ответственные! В настоящем значении слова «программист»
А вот «кожаных мешков», которые не думают, пока им не принесут мысль в клювике и не пережуют за них, взявшись рукой за челюсть — вот их надеюсь не уже не будет.
balexa
21.11.2019 16:50Да нет никаких проблем, это вопрос исключительно квалификации людей, которых вы нанимаете.
Условно говоря, есть шкала «сеньор-джун», и при найме нужно понимать, что за человек у вас в команде. Понятно, что у всех эти критерии разные, но собственно, в моем понимании, к сеньорному разработчику можно прийти и сказать «нужна авторизация API по ключам». Даже нет, не так. «Мы хотим сделать невозможным анонимное использование нашего API». Вот так. И человек это сделает. Он в целом в курсе, откуда компания берет деньги, он знаком с best practices, он способен заложить запас расширяемости, и способен сделать это все чистым кодом. Професионал одним словом.
А если к разработчику надо приходить и говорить «нужно апи по ключам, и они должны быть разные для разных целей, нельзя делать билинг по публичным ключам, нельзя делать ключи чтобы шли по порядку (чтобы нельзя было добавить единичку и получить следующий), надо писать тесты, надо разбивать код на модули» и еще явно «заказывать» кучу вещей — то ничего плохого в этом нет, но это уровень начинающего разработчика. Неопытного. Вот и все. Опять же, ничего плохого в начинающих разработчиках нет, все мы такими были.
Проблемы возникают тогда, когда реальное положение разработчика на этой шкале не совпадает с его самомнением. Крайняя степерь — это когда разработчик доказывает, что он гений, а из этих тупых менеджеров никто в джире не написал, что код должен компилиться и работать" (с) — это практически дословная цитата сотрудника аутсорсера на прошлой работе, который объяснял, почему он считает задачу закрытой и почему он не будет ничего исправлять.
А вина менеджера ЯндексКарт состоит в том, что он дал сеньорскую зарплату и ответсвенность некомпетентному человеку. Что, само собой, тоже крупный косяк.ne_kotin
21.11.2019 17:05А если к разработчику надо приходить и говорить ...
Видите ли. Я тут давеча писал один сервис, и там тоже необходима была авторизация по ключам. Она была нужна исключительно для разделения контекста, и самый край — экстренного отключения потребителя API в случае компрометаций.
Никакого биллинга там не было, сервис использовался бэкендом другого сервиса, поэтому — вот вам пожалуйста ключи, вот вам админка к API, чтобы эти ключи раздавать потребителям. Никуда на фронт они не утекали.
Что-то мне подсказывает, что в данном кейсе программистам забыли сказать, что ключ поедет аж до фронта. Кто виноват?balexa
21.11.2019 17:39забыли сказать, что ключ поедет аж до фронта. Кто виноват?
Наверное тот, кто забыл сказать. Кстати, кто это должен был сказать?
Явно же не программисты, которые не знают как у них устроена система, и ничего не знают за пределами своего сервиса и знать не хотят.
Явно за то, какие ключи куда где генерируются, и кем используются, как они отзываются, где хранятся и т.д. отвечает лично менеджер. И только он это знает. Такое знание программистам явно недоступно и никто им этого не говорит.
Ну, я так понимаю вашу позицию.Neikist
21.11.2019 18:18Не сильно стремлюсь оправдывать программистов яндекса, но зная насколько большими бывают системы, в каком бардаке происходит разработка часто во многих компаниях, и как могут дробить и доносить задачи через 20 человек — программист вообще мог делать таску в полной уверенности что это для внутренних сервисов, для учета статистики. Точнее более того, уверен что эту таску делала туева хуча программистов по частям, не зная друг о друге, и цельная картина не факт что вообще у кого то была. Один главный менеджер поставил задачу, через несколько менеджеров подчиненных друг другу ее поразбивали и поиграли в испорченный телефон, а до кучки конечных исполнителей могло дойти что угодно, разбитое как угодно.
balexa
21.11.2019 18:42+1Безусловно. Я прекрасно понимаю, я тоже работал в таком бардаке, как и большинство думаю.
и цельная картина не факт что вообще у кого то была.
Именно так. Очевидно, что ее просто не было
через несколько менеджеров подчиненных друг другу ее поразбивали и поиграли в испорченный телефон,
А вот менеджеры тут не при чем. Даже в таких корпорациях дробят задачу и разбивают те же программисты. Да, они возможно, выполняют в т.ч. и менеджерские обязанности, но все же это делают техлиды. А они в первую очередь программисты.
А цельной картиной должен владеть solution (e2e/system) architect, ну или как он там называется. Но это техническая должность. Не менеджерская. Причем техническая должность, предполагающая очень большую техническую компетенцию в первую очередь. Не управленческую.
Делаем вывод — в яндексе нет системных архитекторов, каждый кодер пилит свой кусок, и ему плевать что там у соседей. Менеджер не сказал явно — вот пусть получает. Хорошая позиция профессионального разработчика. С точки зрения оппонента выше.
Еще, относительно цельную картину (правда только с точки зрения использования), как ни странно, имеют ручные тестировщики. В данном случае, это очевидно, люди со знанием как минимум фронтенд разработки. Ну должен же был кто-то перед тем как выкатывать на прод потестить — сгеренить токен, вставить его в html-шаблон, повесить на сайт, проверить что что карта открывается.
Вставить токен в пример, проверить что бабки списываются когда F5 нажимаешь. Ну вот тупо, пройти все те туториалы.
Неужели в голову этому человеку не пришло, что у него деньги списываются по открытому ключу?
Конкретно в данной ситуации мифический «менеджер» виноват лишь косвенно — из-за того что доверился не самым квалифицированным людям. Ну, либо все квалифицированные люди посваливали из яндекса. Что кстати, вполне вероятно.UserAd
21.11.2019 19:58Люди скорее заняты накручиванием своих метрик по типу tickets per day. И в такой атмосфере получается внутренний диалог:
— Блин, я же токен от другого аккаунта могу вставить куда угодно, проблема
— Да пофигу, щас напишу в тикете что косяк, потом прикопаются на ревью что слишком много тикетов возвращаю назад. Сделаю все по чертежу и если что скажу что написали, то и получили. Следующий тикет!
UserAd
21.11.2019 14:20+4Это попытка снять с себя ответственность и с одной стороны сказать «я творческая личность и хочу творить», а с другой «а что вы хотели еще и замок в дверь вставить? Может еще и стены вокруг сделать чтоб не обнесли?!».
В последнее время (лет 5-7) вообще какой-то шквал такого инфантильного отношения к своей работе из серии «я тут ничего не решаю, поэтому мне безразлично».vics001
21.11.2019 18:57В профессию пришло много вчерашних детей, которым много платят и которые пришли в основном доделывать программы, которые начинали не они.
justboris
21.11.2019 22:11Это с ремонтом все просто, что такое дверь и стена все знают. API токены — штука более тонкая, с ними так просто не объяснишь, почему грамотная реализация займёт не 2 дня, а 2 недели.
Вот поэтому и возникают такие ситуации иногда, от неправильной оценки рисков дешёвого решения
balexa
21.11.2019 11:49Прямо менеджеры придумывают авторизацию? Нет, я конечно слышал что в яндексе все становится хуже, но чтобы прямо вот менеджеры (которые, надо полагать ничего не понимают в API и авторизации) придумали, закодили и выкатили в прод (без участия программистов) — это сильно.
batyrmastyr
21.11.2019 14:35-1Бывают и чудаки считающие, будто маркетолог — руководящая должность и может командовать фабрике, как ей работать.
UserAd
21.11.2019 14:32+2А своя голова у программистов работает исключительно на расчет как используя наименьшие усилия закрыть тикет?
В данном случае цепочка исполнителей простой задачи «сделать API ключи для карт» полностью провалила задание (если их можно использовать без ограничения, то смысла в них как в двери без стен) рассуждая на каждой ступени примерно так «ну это же должны решать те кто выше». А потом это отдали Billing team которые посчитали что «не, ну защиту API ключей сделали в API team».
При этом тут нельзя сказать что программисты сделали все правильно, такую очевидную проблему в безопасности очень сложно пропустить если не идти по принципу «а мне больше всех надо чтоль?»
avost
21.11.2019 01:54+1Хм. Пару раз проходил в яндексе собеседования. Не знаю про каких гномиков вы толкуете, все собеседования были весьма адекватными даже при том, что интервьюировали сменяясь несколько человек несколько часов. А вопрос про права на ntfs очень сильно бы удивил своей полной бесполезностью и идиотизмом (поэтому, видимо, такую дичь не спрашивают) — мы ведь о разработчиках говорим? Для вынь-админа-то такой вопрос, наверное, хорош, но на кой чёрт об этом спрашивать разработчика карт или других сервисов? Где они и где нтфс?
YetAnotherSlava
22.11.2019 03:54Дичь, говорите? А почему бы программисту и не знать детали системы, с которой он работает? Я понимаю, что сейчас народишко разбогател безмерно и незаслуженно и нахватал себе макбуков, где оный народишко с увлечением пишет на NodeJS и Angular, потому что за это много платят, больше чем за десктопную разработку, которой посчитай, что и не осталось. Безопасность они обеспечивают докером, отключая selinux, потому что сложнааа-а. Ну и Рихтера с Руссиновичем они не читали, а зачем.
Но в общем-то нет особенной разницы между ACL на виндах (читай — на ntfs) и разделением доступа на Амазоне (IAM, Security Groups и прочее). Задачка же вида «придумать модель управления доступом на дереве объектов» ничуть не хуже любой другой яндексовой.
Это знать надо! Это классика!
mspain
21.11.2019 08:28-1Может яндексы предполагают, что вы немного в себе и будете ключ размещать внутри своего API, а клиенты должны ходить к вашему api? Как защищать (и защищать ли) свое апи уже решайте сами.
не яндекс, мимокрокодил.starkeen
21.11.2019 09:09Для доступа к картам в коммерческих приложениях нужно использовать платный ключ. И он таки светится наружу. Для доступа к API геокодера тоже нужен платный ключ. Эти ключи могут быть привязаны к разным аккаунта, но тогда придётся купить два платных аккаунта. А цены там такие, что и один потянуть непросто.
freeExec
21.11.2019 09:41Ключ указывается в html для загрузки скрипта, без него даже карта пользователю не покажется. О каком API вы ведёте речь?
WraithOW
21.11.2019 18:30Товарищ подразумевает, что вместо того, чтобы отдавать ключ от геокодера клиенту — вы храните его на своём бэке, и все запросы клиентов проксируете через него (при необходимости — еще и кешируете). Гугл, если мне память не изменяет, рекомендует именно так поступать.
Насколько это применимо к ключам яндекса — вопрос, разумеется, отдельный.mspain
22.11.2019 10:07Именно. К геокодированию 100% применимо, с картами особо не работал, но уверен, что есть варианты.
По существу, раньше все читерили: яндекс выдаёт вам ключ API и разрешает ВАМ 25к запросов в сутки. Ушлый норотт не заморачиваясь кидает запросы в яндекс с клиента… итого профит — каждый КЛИЕНТ вашего сервиса может делать по 25к запросов.
Технически отключили через 1.5 года после предупреждение, а читеры всё равно недовольны и вонь поднимают. Прекрасно…
p.s. Если в озоне так же сделано, это говорит об уровне тамошних мартышек
theRavel
21.11.2019 15:29Я бы не написал этот пост, если бы уважаемый valshavel не отклонил мой комментарий к статье
«отклонил» — это как? На хабре теперь тоже доступна цензура за бабло (в блогах компаний)?
TimurRyabinin
21.11.2019 16:02Привет! Спасибо за замечания. Мы уже работаем над привязкой ключа к домену. Что касается разделения ключей для JS API и HTTP API — про это тоже думаем. Сейчас для них можно получить разные ключи, но мы хотим выделить их в независимые продукты. На данный момент мы отслеживаем использование ключей и можем выявлять попытки фрода, и не учитывать запросы по ним при биллинге.
ReDev1L Автор
21.11.2019 18:41+1А продуктолог / продукт овнер, уже думает как сделать так, чтобы фрода не было или хотя бы, чтобы он был тяжело осуществим? Обратился к парочке сеньёров там, за консультациями?
Проблема критическая так то.
WebGL когда? mapbox, 2gis — уже впереди вас, хотя какое то время назад — вы были лучшие.
nnm2007
21.11.2019 18:37Проверил только что на ключах Озона и Циана — все работает. И вызов карты и геокодинг…
«Налетай торопись, покупай живопись»
ooprizrakoo
>На ключе отсутствуют настройки
С трудом верится. Может быть где-то в настройках аккаунта разработчика указан домен вашей компании?
В тех же гуглокартах с самого начала (2008?) надо было получать ключ чтоб отображать карты в вебе, иначе фрейм ругался на посторонний домен.
Вы пробовали открыть фрейм с Я.Картами с вашим ключом на совсем «левом» домене?
ReDev1L Автор
Я пробовал геокодировать с enterprise, не своего ключа, под VPN и у меня отлично получилось. Тарификация моих запросов ушла в этот ключ.
Upd:
У гугла — привязка к домену. А тут настроек вообще нет.