В техническом блоге «Спотифая» было опубликовано интересное исследование на тему взлома аккаунтов сервиса путём использования особенностей канонизации вводимых пользователем данных. Это стало возможным благодаря тому, чем спотифаевцы гордятся, — полностью юникодному логину. К примеру, пользователь легко может иметь снеговика в качестве имени аккаунта, если он того пожелает. Реализация подобного, впрочем, с самого начала доставляла некоторые неудобства.

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

Хакер действовал следующим образом: желая взломать аккаунт с именем, скажем, bigbird, он регистрировал аккаунт с именем ᴮᴵᴳᴮᴵᴿᴰ (в Пайтоне эта строчка выглядит как u’\u1d2e\u1d35\u1d33\u1d2e\u1d35\u1d3f\u1d30′). После запроса ссылки на сброс пароля задавался новый пароль, который подходил к аккаунту bigbird.

Интро

Это краткий перевод основных тезисов из брошюры «Web API Design. Crafting Interfaces that Developers Love» Брайана Маллоя из компании Apigee Labs. Apigee занимается разработкой различных API-сервисов и консталтингом. Кстати, среди клиентов этой компании засветились такие гиганты, как Best Buy, Cisco, Dell и Ebay.

В тексте попадаются комментарии переводчика, они выделены курсивом.

Собираем API-интерфейсы, которые понравятся другим разработчикам

Понятные URL для вызовов API

Первый принцип хорошего REST-дизайна — делать вещи понятно и просто. Начинать стоит с основных URL адресов для ваших вызовов API.

Ваши адреса вызовов должны быть понятными даже без документации. Для этого возьмите себе за правило описывать любую сущность с помощью коротких и ясных базовых URL адресов, содержащих максимум 2 параметра. Вот отличный пример:

/dogs для работы со списком собак
/dogs/12345 для работы с отдельной собакой

Не так давно мы начали рендерить 3D-модели на Гитхабе. Сегодня мы с удовольствием объявляем о новейшем прибавлении в семействе визуализаций — о геоданных. Любой файл .geojson в репозитории на Гитхабе теперь станет автоматически отображаться в качестве интерактивной карты (с возможностью листания), снабжённой вашими геоданными.



Люди ужé используют Гитхаб для хранения разных геоданных, от почтовых индексов Чикаго и до радиостанций сообществ да путей движения известных в истории ураганов, так что мы с нетерпением ожидаем увидеть дальнейшие плоды сотрудничества сообществ.

«Под капотом» мы используем Leaflet.js для отображения данных geoJSON поверх специальной версии базового слоя карты улиц MapBox — упрощённого, чтобы данные ваши на нём воссияли. Лучше же всего — то, что картооснова использует данные OpenStreetMap; так что, если пожелаете улучшить какой-либо участок её, редактируйте тотчас же.

Карты на Гитхабе поддерживают отображение данных ГИС как точек, линий и многоугольников. Вы даже можете донастроить способ отображения ваших данных — например, изменить цвета и размеры отдельных пометок, указать более понятные значки, указать дополнительные свéдения для чтения читателем, ткнувшим по заинтересовавшей его пометке на карте.

Вот некое простое значение:


И мы знаем, как к нему можно применить функцию:


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


Теперь, когда вы примените функцию к этому значению, результаты вы будете получать разные — в зависимости от контекста. Это основная идея, на которой базируются функторы, аппликативные функторы, монады, стрелки и т.п. Тип данных Maybe определяет два связанных контекста:

data Maybe a = Nothing | Just a

Позже мы увидим разницу в поведении функции для Just a против Nothing. Но сначала поговорим о функторах!

Хабр, привет!

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

Многим уже надоело лазить по куче сайтов и скачивать js библиотеки и плагины. Да и таскать когда-то скачанные, но уже давно протухшие версии не очень круто. Эти проблемы решает bower.

Но с ним тоже многое нужно делать вручную: следить за components каждого проекта, руками дёргать bower install. После pip с requirements.txt это делать даже как-то лень.

Поэтому представляю вам django-bower, который берёт на себя установку и обновление bower пакетов по списку из settings и прозрачную работу с staticfiles.

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

Какой метод определения языка пользователя подходит лучше – вопрос достаточно спорный. Мой личный ранг значимости языковой информации (в порядке убывания): cookie, настройки браузера, регион.

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

Распространенные варианты кодирования языковой информации о ресурсе следующие:

• каждая языковая версия на отдельном субдомене, например en.example.com, ru.example.com
• язык ресурса указывается в префиксе URI, например example.com/en/, example.com/ru
• язык ресурса указывается в GET параметре, например example.com?lang=en, example.com?lang=ru

Первый вариант наиболее радикальный, каждая языковая версия сайта рассматривается как отдельный ресурс. Могут возникнуть сложности с SSL сертификатом, необходимо заранее предусмотреть все возможные варианты в SAN DNS Host Name, или заказать сертификат с маской, например *.example.com.

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

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

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

Буквально несколько часов назад на HTML5 Rocks появилась замечательная статья о текущем положении дел, касающихся загрузки скриптов на странице. Представляю вашему вниманию ее перевод. Поправки можете присылать в личные сообщения.

Для работы мы используем postgresql + postgis базу данных с данными для всей планеты от osm.org. На диске она занимает около 350 Gb и работает не быстро, да и хранится на обычном винчестере 2Tb 7200rpm, без RAID-a. Т.к. нагрузка на базу данных постепенно растет, было решено ускорить дисковую подсистему, потратив при этом минимум денег. Вариантов было не много:

• купить еще один такой же винчестер и объединить их в raid-0.
• купить небольшой SSD и организовать на нем быстрый кэш:
  
  • dm-cache. Был добавлен в ядро 3.9, ставится просто.
  • bcache. Судя по обзорам самый быстрый. Основной минус — надо форматировать диски перед началом использования. Официально добавлен в ядро 3.10, распространяется как пропатченое ядро 3.9.
  • EnhanceIO. В обзорах я встретил упоминание его, как самого медленного, но простого в использовании.

Взвесив плюсы и минусы, а так же спросив отзывы знакомых, я решил остановиться на bcache. О нем и расскажу подробнее.

Бывает что есть сайт, но пользоваться им с мобильного телефона не очень удобно и было бы замечательно иметь отдельное приложение для него. Любители веб разработки легко смогут это сделать использую phoneGap. Под катом речь пойдет про сервис отслеживания почтовых отправлений, которым я часто пользуюсь и написанный для него демонстрационный клиент с базовым функционалом: авторизация, получение списка треков и описания к ним и возможность добавить новый трек. Я не связывался с разработчиком по этому поводу и очень надеюсь что он на меня не обидится за наглость, за копание в JavaScript коде и за то что в приложении не будет показана реклама. Так же прошу простить за костыльность и велосипедность кода, воспринимайте его как пример.

На этой неделе вышла первая альфа-версия Django 1.6. Этот выпуск посвящается активному участнику Django-сообщества — Малкольму Трединнику (Malcolm Tredinnick), погибшему 17 марта.

В новой версии фреймворка заметно упростили файл с конфигурацией. Теперь django.contrib.admin включен по-умолчанию, а django.contrib.sites наоборот — выключен. Кроме того, теперь определение локали и защита от кликджекинга включены по-умолчанию.

Вы когда-нибудь интересовались механизмом работы ssh-ключей? Или тем, насколько безопасно они хранятся?

Я использую ssh каждый день много раз — когда запускаю git fetch или git push, когда развертываю код или логинюсь на сервере. Не так давно я осознал, что для меня ssh стал магией, которой я привык пользоваться без понимация принципов ее работы. Мне это не сильно понравилось — я люблю разбираться в инструментах, которые использую. Поэтому я провел небольшое исследование и делюсь с вами результатами.

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

Итак, если вам доводилось прибегать к аутентификации по ключу, то у вас, скорее всего, есть файл ~/.ssh/id_rsa или ~/.ssh/id_dsa в домашнем каталоге. Это закрытый (он же приватный) RSA/DSA ключ, а ~/.ssh/id_rsa.pub или ~/.ssh/id_dsa.pub — открытый (он же публичный) ключ. На сервере, на котором вы хотите залогиниться, должна быть копия открытого ключа в ~/.ssh/authorized_keys. Когда вы пытаетесь залогиниться, ssh-клиент подтвержает, что у вас есть закрытый ключ, используя цифровую подпись; сервер проверяет, что подпись действительна и в ~/.ssh/authorized_keys есть открытый ключ, и вы получаете доступ.

Что же хранится внутри закрытого ключа?

Библиотека для работы HTML5 History API

Изначально этот проект был задуман добавить поддержку HTML5 History API в старые HTML4 браузеры. Первые версии библиотеки были нацелены именно на эти потребности, но с учетом прошедшего времени и пожеланий многоуважаемых разработчиков использующих эту библиотеку, она выросла до уровня того, что выполняет некие промежуточные действия по добавлению/исправлению того функционала что описаны в спецификациях по интерфейсу History.

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

Если у вас есть сайт, которым часто пользуются с мобильных устройств (таких как телефоны и планшетные ПК), то вы, возможно, задавались вопросом, как реализовать быстрый вход — так, чтобы пользователю не требовалось вводить ни адрес сайта, ни логин и пароль (либо E-mail и пароль).

На некоторых сайтах вы, возможно, видели возможность отправить SMS-сообщение со ссылкой для быстрого входа — это, по сути, приблизительно то же самое. Основное отличие описанного в данной заметке подхода в том, что вместо отправки SMS-сообщения мы будем генерировать QR-код, который содержит ссылку, позволяющую войти на сайт без ввода авторизационных данных.



Кстати, весь процесс написания приложения, которое приводится далее, можно посмотреть в скринкасте (есть на YouTube, либо в более хорошем качестве в виде файла MPEG2 в 1080p).

Не так давно, разрабатывая очередной программный продукт, наша команда разработчиков столкнулись с задачей реализации полноценной системы синхронизации пользовательских данных в реальном времени, путем рассылки (PUSH метод) изменений сервером. В самом приложении объем данных был не велик, но они могли просматриваться несколькими пользователями одновременно. Поэтому нам был необходим легковесный и достаточно производительный подход к синхронизации данных в рамках Веб-приложения. После того как были рассмотрены различные пути к решению этой задачи, мы остановили свой выбор на достаточно популярном эмуляторе WebSocket’ов – SockJS, который использует различные алгоритмы обмена данными между клиентом и сервером, в зависимости от браузера, которым пользуется клиент. В рамках данной статьи я не буду заострять внимание на том, почему был сделан именно такой выбор (по этому поводу написано немало статей, в том числе и на хабрахабре), а просто скажу, что мы ещё ни разу об этом не пожалели.

Изначально при изучении стандартных подходов к реализации подобного рода задач мы столкнулись с одной проблемой. Эта проблема заключалась в том, что взаимодействие с нашей системой производилось не только посредством веб интерфейса, но также посредством использования API сторонними продуктами, которые мы не могли контролировать. И конечный пользователь нашего продукта, безусловно, ожидает увидеть всю информацию об изменениях в данных, которые его касаются. Стандартный подход использования sockjs сервера подразумевает, что уведомления об изменении каких-либо данных в системе будут посылаться с использованием того же самого JS клиента, который используется для получения информации об этих изменениях. Именно поэтому в нашем случае такой подход был бы неприменим.

В этой статье я хотел бы рассказать о том, как мы решили эту задачу.

Формат представления данных в форме JSON встречается нередко. К примеру, одним из применений может быть обмен JSON данными при работе с API стороннего сервиса, а в других случаях JSON данные могут храниться внутри модели приложения. В некоторых случаях данные необходимо изменить и отправить обратно удалённому сервису, в других сохранить в модели.

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

Я постараюсь донести основные идеи, показать как эта VCS помогает разрабатывать проект. Надеюсь, что после прочтения вы сможете ответить на вопросы:

• можно ли git «подстроить» под тот процесс разработки, который мне нужен?
• будет ли менеджер и заказчик удовлетворён этим процессом?
• будет ли легко работать разработчикам?
• смогут ли новички быстро включиться в процесс?
• можно ли процесс относительно легко и быстро изменить?

Конечно, я попытаюсь рассказать обо всём по-порядку, начиная с основ. Поэтому, эта статья будет крайне полезна тем, кто только начинает или хочет разобраться с git. Более опытные читатели, возможно, найдут для себя что-то новое, укажут на ошибки или поделятся советом.

Уровень подготовки веб-мастера: любой

Теперь наша система поддерживает разметку schema.org для логотипов организаций. Это позволит вам выбрать логотип, который будет представлять ваш сайт в результатах поиска Google.

С помощью этой разметки вы можете указать системе, где находится ваш логотип. Например, если вы – владелец сайта www.example.com, можно использовать следующую разметку элементов на странице:

<div itemscope itemtype="http://schema.org/Organization">
<a itemprop="url" href="http://www.example.com/">Главная</a>
<img itemprop="logo" src="http://www.example.com/logo.png" />
</div>

Как известно, мир GNU/Linux многообразен. Для одной и той же задачи существует множество решений.

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

Топик, в котором была затронута тема удаления файлов с неправильными именами находится здесь. Далее будут приведены иные методы решения той же задачи.

Предполагается, что использовать возможно только командную строку без файловых менеджеров. Под «правильным» файлом будем понимать файл с именем вида number.txt, под «неправильным» — все прочие.

Думаю многим фотографам приходилось чистить отснятые фотографии от пылинок на матрице. Не имея полного Photoshop-a или LightRoom-a быстро обработать большое количество фотографий крайне трудно.
Но у нас есть Gimp и желание написать к нему скрипт.
На Хабре уже было не мало статей про возможность написания скриптов в Gimp.
Вот самый подробные обзор самого языка Script-fu и возможности написания на нём расширений к Gimp
Вот тут статья про пакетную обработку.
По идее, прочитав 2 эти статьи, можно сделать что угодно. Но вот только при решении обозначенной в заголовке проблемы, я столкнулся с многими нюансам, на преодоление которых ушло не мало времени, и которые мало где описаны. Даже в англоязычных Tutorial-ах и Help-ах. О них и пойдёт речь.