Используем сервис Gravatar

Вячеслав Гринин, June 27, 2011

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

Все URL-ы в системе gravatar имеют одну общую ключевую деталь – хеш адрсеса электропочты пользователя. Именно этот хеш уникально идентифицирует пользователя в рамках сервиса gravatar. Хеш формируется очень просто. Для этого нужно взять e-mail, убедиться, что в нем отсутствуют начальные и конечные пробелы, привести его в нижний регистр, и взять MD5-хеш полученной строки.

На языке PHP этот код будет выглядеть так:

    $email = "vgrinin@gmail.com";
    echo md5(strtolower(trim($email)));

А на C# – вот так:

string email = "vgrinin@gmail.com";
byte[] hash = MD5.Create().ComputeHash(Encoding.Default.GetBytes(
  email.Trim().ToLower()));
StringBuilder hashString = new StringBuilder();
for (int i = 0; i < hash.Length; i++)
{
  hashString.Append(hash[i].ToString("X2"));
}
Console.WriteLine(hashString.ToString().ToLower());

Гм… получилось несколько длиннее, чем на PHP.
(more…)

Редиректы

Кирилл Евсеев, June 10, 2011

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

В общем, на сегодня наша задача разобраться с тем, как работает редирект, посмотреть примеры и разобраться в разнице подходов.
Мы рассмотрим следующие типы редиректа в PHP/HTML

- Стандартная функция header. Редирект с помощью отправки заголовков Location и Refresh
- Разница между 301 и 302 кодами состояния HTTP-протокола
- Редирект с помощью мета тега.
- Попытаемся ввести браузер в ступор ссылками на перекрёстные файлы и посмотрим, что будет. (more…)

Пул данных

Кирилл Евсеев, May 30, 2011

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

Итак, зачем вообще нужен пул данных? Основной принцип разработки софта – модульность. То есть мы стремимся к тому, чтобы минимизировать зависимости между классами, чтобы наша программа была не монолитным куском кода, а набором некоторых подпрограмм, которые можно комбинировать друг с другом, добиваясь гибкости и расширяемости системы. Понятное дело, такой подход – результат эволюции. И его преимущества сложно переоценить. Хотя бы тот факт, что в монолитной программе исправление какого-нибудь участка кода может запросто привести к веерным изменениям по всему монолиту, в то время, как в хорошо продуманной модульной структуре любые изменения останутся локальными, главное только сохранить формат и логику входных и выходных параметров.

Проблема заключается в следующем – большую модульную систему могут разрабатывать не то, что разные отделы внутри одной компании, а и вообще разные компании. При этом, каждый модуль будет замечательно работать, но все эти модули будут работать с данными в разных форматах. Я сейчас объясню, что я имею ввиду. Считается, что системе достаточно быть хорошо задокументированной, чтобы избежать этих проблем. Фактически, происходит следующее.
(more…)

Переменные переменных. Зачем они нужны?

Кирилл Евсеев, April 25, 2011

Всем привет. Сегодня мы поговорим о переменных переменных и выясним, зачем они всё таки нужны (или не нужны).

В самом простом виде переменные переменных показаны в справке PHP. А именно –

$a = 'hello';
$$a = 'world';
echo $a . ${$a}; 

Подобная кривая конструкция выдаст на экран hello world. Другими словами, ${$a} эквивалентна вызову $hello. Не правда ли.. ужасно? Добавим сюда проблему неоднозначности, которая возникает при попытке обратиться к элементам массива (это подробно описано в справке по адресу http://ua.php.net/manual/en/language.variables.variable.php), добавим сюда возможность добавлять к имени переменной любое количество знаков доллара, о которой обычно не пишут в учебниках, и возникнет вполне закономерное недоумение – зачем это вообще нужно?

Самое главное правило, которого должен придерживаться любой разработчик в любом проекте – код пишется для людей, а не для машин. Это правило помимо негласного этикета в среде профессионалов в виде комментариев и отступов, ещё и экономически обоснованно. Дело в том что сегодня разработка ПО стремительно дешевеет (не без помощи демпинга индусов). Прямым следствием является то, что поддерживать код должно быть дешевле, чем его писать. Т.о. становится понятно, что читабельный, понятный и простой в понимании код, куда как более ценен, чем процессинг формы на Brainfuck’e (кто не в курсе, пусть насладится http://en.wikipedia.org/wiki/Brainfuck), пусть даже на Brainfuck’e этот процессинг работает на 0.0001 секунду быстрее.

Добавим сюда огромные вычислительные возможности современных серверов, которые могут прожевать мегаметры самого бездарного кода в течение секунды и станет понятно, что деньги, затрачиваемые на поддержку, должны быть минимальными. Разработчик должен иметь возможность спокойно и быстро разобраться в коде, написанном соседней командой, даже через пару лет после финального релиза проекта. Реалии PHP вполне это позволяют – всё таки это скриптовый язык, а не ассемблер.
(more…)

Создаём собственный API – 7

Кирилл Евсеев, April 12, 2011

Приветствую всех, вытерпел до этого момента и не уснул на предыдущих частях статьи :) Сегодняшняя статья последняя в цикле статей об API. Надеюсь, в качестве наглядного материала и источника новых идей вам этого хватит. А если не хватит, – задавайте свои вопросы в комментариях. Если так случится, что понадобятся новые дополнительные статьи на эту тему, то не думаю, что это будет очень большой проблемой :)

Но вернёмся к нашему API. В заключительной части статьи я покажу то, с чего начал во второй статье, а именно – фильтрация кода от нежелательных данных, полученных от пользователей. Прежде всего, давайте прикинем, что мы уже защитили.Итак:

  1. Мы можем без труда зашифровать протокол передачи данных и воспользоваться HTTPS
  2. Мы обеспечиваем жёсткий формат запроса. Любой запрос, в котором отсутствуют необходимые данные, игнорируется. Любой запрос, в котором есть дополнительные данные, непредусмотренные нашей логикой, отсекаются и игнорируются.
  3. Для выполнения запроса мы заставляем пользователя пройти авторизацию. Т.о. мы отфильтровываем пользователей, которым можно доверять от тех, которых мы вообще не знаем.
  4. Авторизованные пользователи отличаются друг от друга уровнем доступа – что позволено Юпитеру, не позволено быку(с).
  5. Запрос содержит пару – имя функции и массив аргументов.Мы проверяем, существует ли в нашем API такая функция и тестируем массив аргументов на количество переданных параметров и их типы. Таким образом, мы уже предотвращаем попытки смержить строку с целой переменной id, которые используются у нас в запросах.

Мы не проверяем синтаксис запросов, да это и ненужно. В случае проблем, API просто вернёт вызывающему хосту false. Мы не проверяем результат, который возвращают API функции, хотя у нас есть такая возможность. Однако, мы возвращаем вызывающему хосту результат as is. Для демонстрационной API-системы вполне нормально.

Сейчас мы реализуем последний штрих к этой картине. (more…)

Поиск по блогу:
Подписаться:
Популярные:
Облако тегов:
Разное:
Счетчик: