Что такое ручка в программировании
Перейти к содержимому

Что такое ручка в программировании

  • автор:

Повсеместное программирование: достаточно ручки и бумаги

Повсеместное программирование: достаточно ручки и бумаги

Новые идеи могут прийти на ум программисту в любое время — например, на прогулке или в очереди. Для обмена идеями отлично подходят рабочие планерки. Какой-то комментарий сам по себе может быть странным или предсказуемым, но в нем попадется несколько фраз, которые привлекут мое внимание. Они смешаются с какими-то незаконченными мыслями и впечатлениями вчерашнего дня.

Так рождаются новые идеи

Оставшаяся на настольном компьютере среда разработки никогда не кажется такой далекой и такой тяжелой на подъем, как в те моменты, когда у тебя в голове задыхается и чахнет новая идея, которой нужен «глоток воздуха», чтобы заявить миру о своем существовании.

Если мы спешим, то можем хотя бы законсервировать идею — набросать ее на бумаге, пока ее помним, а потом вернуться к ней, когда будет время. Но иногда этот момент бывает упущен, искра гаснет, а вернуть ее не удается. Требуется снова искать пищу для ума. Правда, сегодня уже есть Twitter. Этот сервис не назовешь отличным инструментом для записи идей программиста, но Twitter отлично подходит для записи тех кратких мыслей и остроумных замечаний, которые в другой среде остаются неуслышанными и неоцененными.

Я думаю, что Twitter не менее удобен для записи коротких программ и кратких программинг-сессий, длящихся от тридцати секунд до нескольких минут. Подобную роль Twitter может играть и в социальных взаимодействиях: отслеживание программ, которые находятся в процессе разработки, обмен предложениями, опровержение, расширение, интеграция идей.

Под «повсеместным программированием» (Ubiquitous programming) я понимаю возможность программировать где угодно и когда угодно, даже в такие короткие свободные минутки. Термин указывает на связь такого подхода с более масштабным явлением «повсеместных вычислений». Конечно, термин «повсеместное программирование» впервые употребил не я, но мне нечасто приходится встречать людей, которые буквально понимают это выражение (а не как «программирование для систем, обеспечивающих повсеместные вычисления»).

В последнее время я не раз задумывался о повсеместном программировании, так как меня одолевали новые идеи. Некоторые из них я изложил в статье «Abadoning Commitment in HCI» и в дискуссии с группой программистов, занимающихся технологией дополнения пользовательского ввода.

Как бы то ни было, после приобретения смартфона я не раз задумывался, как можно использовать его для программирования. Идей почти не было, пока один приятель не объяснил мне интерпретацию интерпретации замечательной статьи Брета Виктора «Доступное программирование», в которой Виктор критикует излюбленный способ записи моего друга. Не подумайте, что он стал жаловаться: «Ой-ой, не трогайте мою нотацию!», он просто натолкнул меня на интересные мысли. Я стал размышлять: какой способ записи идеально подошел бы для повсеместного программирования?

Ручка, бумага и камера

Уже сама идея писать код на сенсорном экране смартфона мне неприятна. Даже когда я ввожу через тачскрин информацию на естественном языке, я чувствую себя скованным — визуально, физически, духовно, эмоционально. Ладони у меня большие, они закрывают экран, правильно поставить курсор удается не с первого раза. Еще часть экрана закрывает виртуальная клавиатура. Если бы мне пришлось впихнуть на такой экранчик окно IDE — предложения, аннотации, ссылки и т.д., — то совершенно не было бы места не то что для кода и комментариев, а даже для моих собственных мыслей. Планшет и ноутбук неудобны по другим причинам. Они довольно тяжелые, их нужно слишком долго готовить к работе, и, конечно, они не находятся рядом в тот самый момент, когда тебя озарила идея. У меня нет карманов, в которые влезал бы планшет, а если бы и были, не представляю, как можно удобно усесться с такими карманищами.

Но когда я подумал об очках, они показались мне интересным вариантом

В очках для дополненной реальности есть встроенная камера, которая «видит» то же, что и я. Если я смотрю на код, то могу тут же загрузить этот код в программу. То же самое можно сделать и при помощи камеры смартфона: сфотографировать сделанные наброски. Тогда первое грубое редактирование можно выполнять уже не на экране. Достаточно иметь с собой небольшую стопку простой бумаги и ручку, эти вещи легко носить в кармане или кошельке. А более запасливый человек может носить с собой даже общую тетрадь или блокнот в переплете.

Ручка, бумага и камера становятся основными устройствами ввода. «Носитель» программы — бумага — может быть и большим, и маленьким, смотря как его сложить. Тонкая ручка — гораздо более удобное устройство ввода, чем палец. Кстати, возможно, кому-то будет удобнее работать карандашом.

Если выполнять редактирование на бумаге, то экран смартфона остается свободен для более сложных аспектов разработки: аннотаций, предложений, запросов на разъяснение, предупреждений, ошибок, выстраивания взаимосвязей с другими программами. При работе с очками подобные элементы могут отображаться в наложенном слое или на периферии.

Модульность, связывание, совместное использование

В таком случае мы не сможем напрямую подключать подпрограммы, которые пишутся на других «холстах». Допустим, мы записали их на других листах блокнота, которые не хотим вырывать. Соответственно, межпрограммные взаимосвязи также выстраиваются в виртуальном пространстве. Автор нарисует нужную связь на бумаге — например, начертив прямоугольник или добавив немного контекста (скажем, заголовок или другая надпись, может быть, дата, номер версии и имя автора). Имея такое представление в качестве подсказки, а также менее явные подсказки (это может быть история просмотренных автором программ), мы сможем отобразить на телефоне или в очках существенное количество вариантов.

Выбирая варианты, выстраивая взаимосвязи, мы превращаем программу в нечто большее, чем просто наброски на бумаге. Получается более значимая, точная, логичная, правильная, интегрированная сущность. Разработка и редактирование превращаются в смешанную картину, состоящую из виртуальных операций и реальных дополнений (а иногда и сокращений — допустим, нам потребовалось стереть или зачеркнуть элемент). Фактически программа это виртуальный объект, поддерживаемый в среде программирования. Программу желательно располагать в облаке (общедоступном или закрытом) и синхронизировать с локальным хранилищем данных (на случай неожиданного вылета в оффлайн). Программа останется таким объектом, если не будет повреждена и до тех пор, пока она будет доступна для понимания. Виртуальные программы индексируются по многим показателям: автор, дата, местоположение, содержание, комментарии, взаимосвязи, история и прочая визуальная информация, находящаяся «на кончиках пальцев».

Если у вас есть доступ «только для чтения» к моему облаку, я могу дать вам блокнот, и вы сможете читать программы. Не только рассматривать мою полуразборчивую писанину, но и улавливать связи, читать разъяснения. Моя библиотека станет для вас досягаема. Повсеместное программирование предполагает совместное использование именно таким чудесным осязаемым образом, напоминающим обмен книгами. Разумеется, вы сможете воспользоваться и методом «электронной книги», просматривая облако непосредственно с экрана. Но это, пожалуй, будет намного менее удобно.

Схемы и заметки в произвольной форме

Современное программирование — это в первую очередь написание текста, так как именно текст набирается на клавиатуре. Для ввода в произвольном формате можно использовать мышь, но мне это показалось довольно неудобным. А вот работая с ручкой и бумагой, мы можем рисовать какие угодно графики, схемы, стрелки, функциональные кривые, наброски (символы, карты, взаимодействия), специальные математические символы и т.д.

Это особая свобода, которая и привлекает меня возможностью делать наброски параллельно с обдумыванием идей. Я охотно покупаю общие тетради, наборы ручек, с которыми хожу и в парк, и в ресторан. Мне уже зачастую нелегко вернуться к написанию программ обычным негибким текстом.

Мне нравится делать наброски, заметки на полях. Я объединяю идеи. Я не в восторге от структурных редакторов, а вот совершенно «неструктурированное» редактируемое пространство, в котором можно представить хорошо структурированный объект виртуальной программы (при помощи объяснений и ограничивающих условий), очень меня привлекает.

Не только текст

Обычно мои наброски из рабочих тетрадей превращаются в путаные обрывки информации, к которым я никогда не возвращаюсь (они мне просто не нужны после того, как я полностью усвою записанные в них концепции). Но если бы все эти эскизы, наброски, схемы и прочая информация индексировалась, становилась доступной для поиска, изучения, воспроизводилась на носителе, который не горит, то это значительно обогатило бы текстовую информацию (не обязательно связанную с программированием). Часто на рабочих собраниях люди фотографируют схемы, сделанные на маркерных досках. Почему всю эту информацию никто еще не сохраняет и не индексирует? Есть ли в наличии подходящий для этого инструмент? Дарю идею для революционного приложения, которое озолотит своего создателя, — развивайте!

REPL, виджеты, живой кодинг

Независимо от того, работаем ли мы с умными очками или камерой, наши программы, написанные на бумаги, будут отличаться высокой интерактивностью. В частности, это касается вычисления выражений. Как записать серию выражений и сразу же узнать их значения? Запросто, если программа создается ручкой на бумаге.

Интересная возможность связана с развитием концепции REPL-среды полнофункциональных виджетов. Выражение должно результировать не в обычную величину, а в осязаемое значение, или оголенный объект, или в подобную сущность, которую можно представить в виде виджета, наблюдать ее и манипулировать ею. В частности, такие виджеты могли бы управляться голосом или жестами.

Виджеты, разработанные таким образом, могут управлять состоянием в реальных системах и оказаться удобной основой для повсеместных человеко-компьютерных взаимодействий (HCI). Открываем блокнот на нужной странице. Настраиваем несколько необходимых виртуальных ползунков и флажков. Берем чистый лист бумаги и записываем на нем несколько программ или ссылок на них. Загоняем это в нашу среду разработки — всё, виджет готов.

Понятие «живого кодинга» противоречит повсеместному программированию, но я считаю, что две эти методики могут хорошо взаимодействовать на стыке программирования и человеко-компьютерных взаимодействий: при разработке таких виджетов и REPL-сред.

Как максимально эффективно использовать цвет?

Программируя ручкой на бумаге, мы теряем подсветку синтаксиса. Разработчики, которые не желают от нее отказываться, могут воспользоваться разноцветными ручками или цветными карандашами. Но при повсеместном программировании, как и в повсеместных вычислениях, я не склонен использовать семантический цвет как минимум по шести причинам:

  • если у цветов разная семантика, то перед наброском идеи требуется тратить драгоценное время на сортировку карандашей;
  • при использовании нескольких цветов потребуется носить с собой гораздо больше карандашей или ручек, такое количество может не уместиться в кармане;
  • чем проще контрастность, тем лучше ее будут обрабатывать алгоритмы машинного зрения;
  • с цветами неудобно работать при изменяющемся освещении (особенно при необычном, например, неоновом свете);
  • в повсеместном программировании/HCI могут прижиться невидимые ссылки (инфракрасные, ультрафиолетовые, использующие дифракцию на кристаллах), но обычно таким ссылкам не хватает гибкости при представлении цветовой информации;
  • чем проще контрастность, тем более повсеместным получается программирование

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

Что дальше

Думаю, повсеместное программирование при помощи ручки и бумаги — многообещающая и интересная возможность, которую можно реализовать уже сегодня. При такой работе предпочтительно было бы использовать умные очки (особенно при работе стоя или в движении), но смартфоны более распространены, доступны и лучше подойдут для начала. Существующие сегодня алгоритмы машинного зрения в принципе достаточно совершенны для достижения этой цели. Нужное для работы облако также несложно реализовать (предпочтительно на базе свободного ПО).

Здесь я не затронул еще одного аспекта, необходимого для реализации этой модели, — речь об интеграции такого гибкого синтаксиса с моделью программирования. При этом можно обойтись и без протокола RDP (хотя я бы только приветствовал это). Несколько лет назад я много размышлял о синтаксисе и пришел к выводу, что его стоило бы упростить по максимуму, ради сохранения статического восприятия кода.

Интересно, может ли какой-либо подход, связанный с пользовательским синтаксисом, помочь развить специализированный визуальный и схематический синтаксис. Объединив такой подход с применением виртуального объекта программы, мы сможем значительно отложить выстраивание синтаксиса. Достаточно начать писать, а синтаксис разъяснить уже потом (ведь синтаксис — это просто еще один вид связей внутри программы!).

Что такое ручки в прграммировании?

Угу. Если handle, то это «дескриптор», или «числовой идентификатор»
А если просто ручки, то ими стучат по клаве.

Кирилл ИнжуватовУченик (134) 8 лет назад
Там имелось ввиду, что они выдерживают нагрузку 100 и 1000rps
Кирилл ИнжуватовУченик (134) 8 лет назад
Там имелось ввиду, что они выдерживают нагрузку 100 и 1000rps

Ирина В Просветленный (49017) Кино не смотрела конечно, но rps это «обороты в секунду», в программировании таких объектов нет. Но если Вы приведете фрагмент текста, и название продукта, то попробую понять. Возможно, что речь о гироскопах, в навигационных чипах, для мобильников?

Кирилл ИнжуватовУченик (134) 8 лет назад

Браузер использовал Cocaine потому что он позволял делать ручки которые выдерживают нагрузку 100 rps и 10000rps.
То чем мы занимаемся в серверной стороне яндекс браузера это ручки начиная с аджеста api turbo.

Что такое API?

Фотография

Я посмотрел один интересный видеоролик об API и хочу узнать, правильно ли я понял, что такое API.

В моем понимании, API — это набор функций. Апи может быть как одно, так и несколько, в каждом Апи есть n-ное количество функций.

То есть, получается, что тестирование API — это, в каком-то роде, интеграционное функциональное тестирование(или просто функциональное тестирование(если рассматривать функционал в одном Апи)?

Интеграционное тестирование, я имею ввиду, что мы тестируем взаимодействие между Апи созданым нашим разработчиком и инным, с которым разработчик установил взаимодействие, что бы не писать с нуля и не тратить свое время. (Пример из видео: сайт кинотеатра(наш Апи) имеет взаимодействие с платежной системой(не наш Апи).

#2 e_white

Отправлено 02 апреля 2020 — 10:06

На конференциях часто слышу термин «крутить ручки». Т.е. дергать те или иные АПИшки. Этот оборот очень хорошо раскрывает то, как работает АПИ.

Детальнее: Бэкенды пишут бэк. Фронты пишут фронт. Вторым нужно что-то, через что можно общаться с бэком, т.е. слать/получать/изменять/удалять данные.

Для этого нужен какой-то интерфейс. API(endpoint) — и есть такой интерфейс( Application Programming Interface ).

Так как все нагляднее на примерах, вот два варианта АПИ с внешними интерфейсами(«ручками» торчащими наружу:)

1. Всеми нами любимый пример — автомобиль.

Современные авто — это уже очень серьезные технологические вещи, внутри крепко напичканные самими разными агрегатами и механизмами. Тонкости работы большинства из них нам не неведома, да и не должна быть. Так вот все, что происходит условно «под капотом» — это бэкенд. Фронт — это красивая приборная панель, которую видит водитель. АПИ в этом случае — это точки под капотом, куда подключаются провода, идущие на приборку.

Но это закрытое АПИ. Что тогда тут будет внешний интерфейсом?

В любом современном авто есть специальный разъем(ODB), куда можно подключить внешние системы диагностики, или другие приборы, получающие информацию «из под капота» в обход приборной панели. И получить можно куда больше информации.

Резюме вкратце. Есть автомобиль — внутрянка + интерфейсы для водителя, чтобы управлять внутрянкой. Это цельный продукт, все работает вместе. Но есть еще и интерфейсы выходящие наружу, дающие доступ кому угодно извне, но без нарушения механизмов работы бэкенда.

2. Интеграция почтовых сервисов и онлайн магазинов(по аналогии с кинотеатром и платежкой).

Думаю все мы когда-то заказывали что-то онлайн, и в конце указывали отделение почты, куда бы ты хотел оформить доставку. Так вот вопрос? Откуда эти онлайн магазины знают всю информацию о всех почтовых отделениях, их адресах, названиях, актуальном списке, ведь они все время меняются? Не нанимать же онлайн магазину специального человека, который будет сидеть и актуализировать эту информацию? Конечно нет:)

У почты есть сайт(бэк + фронт), и бэк дает пользоваться определенными интерфейсами кому угодно. Такими интерфейсами может быть как раз та самая информация о почтовых отделениях, их адресах, названиях, актуальном списке. Онлайн магазины просто используют АПИ почты в рамках сотрудничества. Более продвинутые почтовые сервисы делают целые виджеты, которые может добавить себе на сайт кто угодно, чтобы упростить работу с оформлением доставки. Почему это выгодно? Онлайн — магазин решает проблему доставки товара, Почта — имеет площадку для рекламы и распространяет свои услуги. По этому очень важно поддерживать внешние АПИ в актуальном состоянии, если от этого зависит бизнес.

Резюме вкратце. Есть сервис(сайт) почты, почта дает доступ к внешнему АПИ кому угодно, чтобы они могли использовать услуги почты, всегда имея актуальную информацию о услугах и точках почты.

Зачем нам тестировать АПИ?

Чтобы удостовериться, правильно ли работают «ручки», используемые внешними модулями. Так как АПИ — это по сути JSON схемы, они должны быть правильно описаны. Если схема говорит, что поле принимает int или bool, значит нужно проверить, что это так и есть. Это очень кратко. Тема тестирования АПИ это совсем отдельный разговор 🙂

Что касается интеграционного тестирования.

Википедия гласит — «это одна из фаз тестирования программного обеспечения , при которой отдельные программные модули объединяются и тестируются в группе.»
Есть по сути тестирование АПИ — это НЕ интеграционное тестирование, но тестирование конкретного модуля, которому принадлежит это АПИ. Интеграцию мы тестируем, когда есть несколько модулей, общающихся посредством АПИ, а мы при этом получаем информацию через их общее АПИ или другие интерфейсы, отображающие их комплексную работу.

#3 Kukuh

Отправлено 02 апреля 2020 — 12:11

Привет!

На конференциях часто слышу термин «крутить ручки». Т.е. дергать те или иные АПИшки. Этот оборот очень хорошо раскрывает то, как работает АПИ.

Детальнее: Бэкенды пишут бэк. Фронты пишут фронт. Вторым нужно что-то, через что можно общаться с бэком, т.е. слать/получать/изменять/удалять данные.

Для этого нужен какой-то интерфейс. API(endpoint) — и есть такой интерфейс( Application Programming Interface ).

Так как все нагляднее на примерах, вот два варианта АПИ с внешними интерфейсами(«ручками» торчащими наружу:)

1. Всеми нами любимый пример — автомобиль.

Современные авто — это уже очень серьезные технологические вещи, внутри крепко напичканные самими разными агрегатами и механизмами. Тонкости работы большинства из них нам не неведома, да и не должна быть. Так вот все, что происходит условно «под капотом» — это бэкенд. Фронт — это красивая приборная панель, которую видит водитель. АПИ в этом случае — это точки под капотом, куда подключаются провода, идущие на приборку.

Но это закрытое АПИ. Что тогда тут будет внешний интерфейсом?

В любом современном авто есть специальный разъем(ODB), куда можно подключить внешние системы диагностики, или другие приборы, получающие информацию «из под капота» в обход приборной панели. И получить можно куда больше информации.

Резюме вкратце. Есть автомобиль — внутрянка + интерфейсы для водителя, чтобы управлять внутрянкой. Это цельный продукт, все работает вместе. Но есть еще и интерфейсы выходящие наружу, дающие доступ кому угодно извне, но без нарушения механизмов работы бэкенда.

2. Интеграция почтовых сервисов и онлайн магазинов(по аналогии с кинотеатром и платежкой).

Думаю все мы когда-то заказывали что-то онлайн, и в конце указывали отделение почты, куда бы ты хотел оформить доставку. Так вот вопрос? Откуда эти онлайн магазины знают всю информацию о всех почтовых отделениях, их адресах, названиях, актуальном списке, ведь они все время меняются? Не нанимать же онлайн магазину специального человека, который будет сидеть и актуализировать эту информацию? Конечно нет:)

У почты есть сайт(бэк + фронт), и бэк дает пользоваться определенными интерфейсами кому угодно. Такими интерфейсами может быть как раз та самая информация о почтовых отделениях, их адресах, названиях, актуальном списке. Онлайн магазины просто используют АПИ почты в рамках сотрудничества. Более продвинутые почтовые сервисы делают целые виджеты, которые может добавить себе на сайт кто угодно, чтобы упростить работу с оформлением доставки. Почему это выгодно? Онлайн — магазин решает проблему доставки товара, Почта — имеет площадку для рекламы и распространяет свои услуги. По этому очень важно поддерживать внешние АПИ в актуальном состоянии, если от этого зависит бизнес.

Резюме вкратце. Есть сервис(сайт) почты, почта дает доступ к внешнему АПИ кому угодно, чтобы они могли использовать услуги почты, всегда имея актуальную информацию о услугах и точках почты.

Зачем нам тестировать АПИ?

Чтобы удостовериться, правильно ли работают «ручки», используемые внешними модулями. Так как АПИ — это по сути JSON схемы, они должны быть правильно описаны. Если схема говорит, что поле принимает int или bool, значит нужно проверить, что это так и есть. Это очень кратко. Тема тестирования АПИ это совсем отдельный разговор 🙂

Что касается интеграционного тестирования.

Википедия гласит — «это одна из фаз тестирования программного обеспечения , при которой отдельные программные модули объединяются и тестируются в группе.»
Есть по сути тестирование АПИ — это НЕ интеграционное тестирование, но тестирование конкретного модуля, которому принадлежит это АПИ. Интеграцию мы тестируем, когда есть несколько модулей, общающихся посредством АПИ, а мы при этом получаем информацию через их общее АПИ или другие интерфейсы, отображающие их комплексную работу.

Окей, тогда тестирование АПИ ( как я понял ) — тестирование конкретного модуля и, в каком-то роде, это тестирование бэкэнда.

То есть, если брать к примеру автомобиль, то тут будет два тестирования АПИ — АПИ двигателя и АПИ всего остального.

В случае онлайн-магазинов это будет тестирование АПИ подсказок адресов, тестирование АПИ платежной системы и тестирование АПИ конкретно нашего сайта.

#4 e_white

Отправлено 02 апреля 2020 — 12:48

Окей, тогда тестирование АПИ ( как я понял ) — тестирование конкретного модуля и, в каком-то роде, это тестирование бэкэнда.

Это не будет исчерпывающим тестированием бэкенда, но это есть тестирование интерфейсов бэкенда.

Другими словами, если вас спросят, что вы проверили, тестируя ваше внутреннее АПИ, вы:

— можете сказать, что АПИ правильно обрабатывают запросы, и делают то, что должны так, как требуется. То есть для внешних относительно этого АПИ модулей(например фронт) все будет работать верно. Приборная доска автомобиля будет показывать актуальные параметры, а виджет почты на сайте магазина покажет правильные адреса и список отделений.

— но НЕ сможете сказать, что весь бэкенд работает верно. Опять же по аналогии с автомобилем, у вас на приборке может быть все ок, но при этом могут подтекать стойки, масло, и так далее. Тут уже нужен более глубокий осмотр, конкретно открывать капот и лезть смотреть конкретные узлы(писать юнит тесты).

То есть, если брать к примеру автомобиль, то тут будет два тестирования АПИ — АПИ двигателя и АПИ всего остального.

Не уверен, что можно говорить о таком разделении.

АПИ — это не что-то, что генерируется само исходя из написанного кода(хотя и так тоже бывает). Это ровно те «ручки», которые спланированы в приложении для требуемого взаимодействия с внешними модулями.

В случае онлайн-магазинов это будет тестирование АПИ подсказок адресов

Если это конкретная внешняя апишка, которая возвращает список адресов почты, то да. Тестируя тут вы должны проверить:

1. Что вы правильно обрабатываете полученные от почты данные у себя на стороне(формат данных, список полей и тд). Это в том числе является объектом тестирования — как вы работаете с внешними АПИ.

2. Пункт более спорный, но можете проверить что вам приходит все что нужно, если список адресов является конечным. Спорный потому что логика эта лежит у них на стороне, и если придет на один адрес больше или меньше, вы ничего не сможете с этим сделать и не узнаете, баг это или нет.

тестирование АПИ платежной системы

Надо понимать, что внешние АПИ как таковые тестировать не надо. Это полноценный инструмент(third-part) других компаний, который уже протестирован их специалистами, и если вы имеете к нему доступ, значит он уже «в проде». Тем более что такие комплексные решения как платежные системы — это немного другое. Вы можете встроить их себе в приложение, да, но из-за соображений безопасности основная их работа часто происходит у них на стороне. Опять таки повторюсь, здесь я бы проверял больше не их работу, а то, что вы предоставляете все что им нужно для корректной работы и в правильном формате. А уж они, если они внешние и достоверные, скорее всего работают правильно 🙂

Браузер на страже API-запросов: строим безопасное общение фронтенда с бэкендом

Тут ошибка. mc.yandex.ru это только один из доменов метрики. Для пользоватей из других регионов метрика перестанет работать. Самое неприятное здесь это то что нельзя применить плейсхолдеры как у Гугл аналитики, потому что метрика не использует поддомены. Перечислять все 20+ доменов метрики в заголовках это дичь. К тому же они могут измениться.
Поэтому придётся полностью отказаться от CSP либо от метрики.

Комментарий пока не оценивали 0
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий

Безусловно, вы правы. Для регионов надо указывать альтернативные домены (которые есть в документации яндекса), в статье я привёл ознакомительный пример конфига. Не думаю, что стоит совсем отказываться от CSP или метрики. Тут всё зависит от направленности самого приложения и тем, на сколько часто будут возникать блокировки csp. Если такие визиты единичны, то ими можно пренебречь.

Комментарий пока не оценивали 0
Ответить Добавить в закладки Ещё
Вам надо что-то с ручками делать…
Всего голосов 1: ↑1 и ↓0 +1
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
Что вы имеете в виду?
Комментарий пока не оценивали 0
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий

Лучше вы поясните, что вы имели в виду под ручками в вашем тексте (переводе?)… поищите, если вы читали его, конечно))

REST API ручками

Пусть ручка получения POST

В ручке POST

Всего голосов 2: ↑2 и ↓0 +2
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
дак у буржуев эт endpoint же…
Комментарий пока не оценивали 0
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий

С буржуями всё понятно, и с точками входа, и с обработчиками и другими адекватными словами-переводами и не очень. Но вот ручка… даже по смыслу бред, ручка двери только на ум приходит. Откуда этот «сленг»?)

Всего голосов 1: ↑1 и ↓0 +1
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий

В паре проектов, в которых я участвовал сленговое «ручка» тоже вполне себе использовалось. Цепочка аналогий такая: у нас есть метод, что-то обрабатывающий, он же handler -> hand -> ручка 🙂

Комментарий пока не оценивали 0
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий

Ручка — это endpoint API-интерфейса. Например GET /user — endpoint получения информации о пользователе. В русском языке закрепился немного сленговый термин «ручка»)

Всего голосов 6: ↑3 и ↓3 0
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий

В русском языке закрепился немного сленговый термин «ручка»

Первый раз про него слышу.
Всего голосов 5: ↑5 и ↓0 +5
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий

Я полагаю имелось ввиду = handle

Комментарий пока не оценивали 0
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий

handle как «ручка» тоже нечасто переводится. Обычно это «дескриптор».

Комментарий пока не оценивали 0
Ответить Добавить в закладки Ещё
НЛО прилетело и опубликовало эту надпись здесь
Показать предыдущий комментарий
Принял ваше замечание, спасибо) исправил. Надеюсь, так понятнее)
Комментарий пока не оценивали 0
Ответить Добавить в закладки Ещё

Хранение refresh_token в любых куках плохая идея. А тут ещё он превратился из токена в обычную сесионую куку, которой и нужна защита от CSRF. Ну и дальнейшая идея использовать в качестве CSRF токена протухший acess-token ещё хуже.

Всего голосов 1: ↑1 и ↓0 +1
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий

В статье я как раз говорил, что хранить надо только в httpOnly. Это не совсем сессионная кука, это кука, нужна только для обновления токена доступа. Если злоумышленник не будет иметь прежний токен доступа (который не достать csrf атакой), то воспользоваться рефреш токеном он не сможет.

Всего голосов 2: ↑1 и ↓1 0
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий

Признак httpOnly говорит только о том, что эта кука недоступна из javaScript и для всех запросов она работает как обычная кука. CSRF как раз и основан на автоматической отправке кук, и для него глубоко паралельно она htpOnly или нет. Поэтому ваш refresh-token для CSRF ПОЛНОСТЬЮ аналогичен обычной куке.
В обычной ситуации считается, что access-token может быть перехвачен, но из-за его короткого действия похититель ним воспользоваться не может (не успеет). А вот своровать refresh-token сложно (в идеале вообще невозможно). А у вас вы refresh-token положили вору на блюдечке (он отдается автоматически при запросе), да ещё и разрешили воспользоваться протухшим acces-token — это просто праздник для хакера.
ЗЫ: При разработке системы безопасности есть основное правило: ЕСЛИ ВЫ НЕ ЭКСПЕРТ ПО БЕЗОПАСНОСТИ СЛЕДУЙТЕ ИНСТРУКЦИИ И НЕ ПРИДУМЫВАЙТЕ СВОЮ СИСТЕМУ, ТАК КАК В ВАШЕЙ СИСТЕМЕ С ВЕРОЯТНОСТЬЮ 100% ЕСТЬ ДЫРА. 🙂

Всего голосов 3: ↑2 и ↓1 +1
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий

Каким образом в этой схеме злоумышленник с помощью одного лишь csrf-атаки прочитает токен, хранящийся в httpOnly cookie? Он может послать запрос через браузер с этой куки в заголовке, не отрицаю. Но что он этим добьётся? Как вы верно заметили, такую куку он с помощью js прочитать не сможет. А одного рефреш токена не достаточно для того, чтобы выполнить какое-либо действие или получить пользовательские данные.

ЗЫ: Нужно больше капса)

Всего голосов 3: ↑1 и ↓2 -1
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий

Мне кажется если вы критикуете в чем то оппонента, то может стоит предложить верный алгоритм, хотя бы в одной фразе?

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *