Progress28.ru

IT Новости
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Разработка веб приложения на php

Создаем первое PHP приложение: Часть №1

Этот урок ориентирован на тех, кто совсем немного знаком с PHP и Объектно-Ориентированным Программированием (ООП) и хотят создать простое веб приложение.

Для более удобного восприятия материала урок состоит из 3-х частей.

Обзор серии уроков

Нам необходимо изучить очень много материала. Вот план:

Часть №1 — Создаем проект и создаем первый класс

— создаем набросок проекта
— создаем файлы и папки
— создаем класс для операций с базой данной: DB.class.php

Часть №2 — Доделываем серверную чаcть

— Создаем класс для пользователей (User)
— Создаем класс UserTools
— Регистрация Логин Выход

Часть №3 — Создаем внешний интерфейс

— Формы
— Обработка форм
— Отображение информации сессий

Начинаем наш проект!

Создаем план действий

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

Структура Файлов и Папок

ООП PHP программирование использует классы и объекты для выполнения необходимых для приложения операций. При планировке Вам необходимо подумать о том, какие классы Вам понадобятся. Для данного проекта мы создадим 3 класса. Первый класс — User (будет содержать информацию о пользователе с функцией простого сохранения save()), второй — UserTools (будет содержать функции, которые необходимы пользователям, такие как login(), logout() и другие. ), третий — класс БД (он будет выполнять роль связующего звена — подсоединение к БД, внесение изменений, вставка новых рядов, и многое другое).

Кроме классов, мы также будем использовать файл с названием global.inc.php. Этот файл будет вызываться с каждой страницы и выполнять обычные операции, которые нам понадобятся. К примеру, в этом файле мы будем выполнять подключение к БД на каждой странице.

Другие файлы — это страницы для пользователей: index.php, register.php, login.php, logout.php, settings.php и welcome.php.

Общая структура у нас будет выглядеть так:

Создание Базы Данных и таблицы users

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

Первичным ключом у нас выступает поле “id”, и именно его мы будем использовать для идентификации наших пользователей.

Уникальным полем у нас также будет “username”. Другие необходимые поля “password”, “email”, и “join_date”.

Создаем класс DB.class.php

Цель данного класса очень проста: как можно больше уменьшить использование SQL при обращении к БД, а также организовать данные в удобный для нас формат.

Ниже приведен код:

Объяснение кода

После создания класса Вы видите 4 переменные: $db_name, $db_user, $db_pass, и $db_host. В них необходимо внести данные для подключения к БД. $db_host обычно localhost. Перед этими переменными указано «protected» — это означает, что они будут не доступны вне этого класса. Внутри же класса их можно выводить используя $this->db_name, $this->db_user, и т.д.

Первая функция называется connect(). Эта функция содержит защищенные значения для соединения с БД. Это соединение будет открыто для использования в любом месте текущей страницы (не только внутри класса).

Вот пример использования этой функции вне класса:

Вторая функция называется processRowSet(). Цель данной функции — взять объект результата mysql и конвертировать его в ассоциативный массив, в котором ключами являются название колонок. Функция проходит по каждому ряду и функция mysql_fetch_assoc() преобразовывает каждый ряд в массив. Ряд далее передается массиву и возвращается с помощью функции.

Существует второй аргумент $singleRow, который содержит значение по умолчанию. Если значение true, выводится только один ряд вместо массива. Это очень полезно, если Вы ожидаете получить один результат (например, при выборе юзера из БД используя уникальный id).

Последние 3 функции выполняют простые функции MySQL: select, insert, update. Цель данных функций минимизировать количество SQL кода, который необходимо использовать где-либо в другом месте приложения. Каждая функция создает SQL запрос на основе переданного значения и выполняет этот запрос. В случае select(), результаты форматируются и выводятся. В случае update(), выводится true при успешном выполнении. В случае insert(), выводится id нового ряда.

Вот пример как Вы можете изменить данные пользователя в БД используя функцию update():

Вот и все на сегодня! До следующих частей!

Вторая часть урока тут, третья — тут

Данный урок подготовлен для вас командой сайта ruseller.com
Источник урока: www.buildinternet.com
Перевел: Максим Шкурупий
Урок создан: 14 Декабря 2009
Просмотров: 197935
Правила перепечатки

5 последних уроков рубрики «PHP»

Фильтрация данных с помощью zend-filter

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

Контекстное экранирование с помощью zend-escaper

Обеспечение безопасности веб-сайта — это не только защита от SQL инъекций, но и протекция от межсайтового скриптинга (XSS), межсайтовой подделки запросов (CSRF) и от других видов атак. В частности, вам нужно очень осторожно подходить к формированию HTML, CSS и JavaScript кода.

Подключение Zend модулей к Expressive

Expressive 2 поддерживает возможность подключения других ZF компонент по специальной схеме. Не всем нравится данное решение. В этой статье мы расскажем как улучшили процесс подключение нескольких модулей.

Совет: отправка информации в Google Analytics через API

Предположим, что вам необходимо отправить какую-то информацию в Google Analytics из серверного скрипта. Как это сделать. Ответ в этой заметке.

Подборка PHP песочниц

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

Чем так хорош язык веб-разработки PHP

Дата публикации: 2018-10-26

От автора: пришла пора рассказать о языке, который формирует большинство современных веб-страниц. Кто-то отзывается о нем хорошо, кто-то плохо, но не существует разработчиков, которые бы игнорировали его существование. Сегодня разберем все основные моменты, которые таит в себе язык веб-разработки PHP. Заодно выясним, как использовать его с максимальной эффективностью.

Все преимущества

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

Предназначение: для чего создан язык

Днем рождения принято считать 8 июня 1995 года, когда Расмус Лердорф выпустил первую версию Personal Home Page Tools (PHP Tools). За основу он взял Perl и создал интерпретатор шаблонов, который должен был ускорить веб-разработку. Через два года он выпустил вторую версию шаблонизатора, разработка которого велась с помощью С.

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Но настоящее рождение «препроцессора», как языка, который известен сегодня, произошло в 1998 году, когда был полностью переписан код. Увидев перспективную разработку, программисты со всего мира принялись совершенствовать ее. Именно благодаря общему труду, сегодня язык поддерживает создание wеб-приложений на основе различных серверов и баз данных. Ну, а тот «препроцессор», который вдохновил Цукерберга на создание Facebook, появился в 2004.

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

Так много на PHP

Хотя и программисты любят наговорить плохого о «препроцессоре», они знают, как много удачных проектов взяли его за основу. Самыми популярными из них являются Facebook и WordPress. C первым вы знакомы давно: это самая большая социальная сеть в мире. Они даже выпустили собственный транслятор для языка, который называется HipHop. Для Цукерберга, скорее всего, выбор был обусловлен простотой языка. Изначально, FB не планировался настолько масштабным, потому разработка с помощью «гипертекстового препроцессора» казалась хорошей идеей.

Все страницы и веб-приложения работали на языке долгие годы, пока команда не решила отказаться от этого. Они создали новый, чтобы с его помощью продолжить поддержку сайта. Но правда в том, что даже новый язык — это тот же «препроцессор», только с некоторыми дополнениями. В основе языка Hack лежит PHP, но разработанный для нужд Facebook. Скорее всего, разработка с помощью уникального языка была скорее коммерческим ходом, чем необходимостью.

О том, что в основе WordPress лежит PHP, не знает разве что ленивый. При этом сама платформа работает отлично, особенно в новых версиях. Самые любопытные даже знают о том, что в свое время проблемы с сериализацией создавали опасность для сайтов, сделанных в WP. Некоторые даже пророчили крах CMS, но 12 июля 2018 года компания выпустила версии, где все проблемы были устранены. Кстати, при помощи того же «препроцессорa».

Читать еще:  Division by zero php

Но социальная сеть и система управления могут показаться не самыми весомыми доказательствами эффективности PHP. Нужно привести web-приложение, которое полностью работает на этом языке, решает глобальные проблемы и имеет коммерческий успех. Что ж, платформа электронной коммерции WooCommerce тоже полностью разработана с помощью «препроцессорa». Через нее проходит почти половина всех интернет-покупок в мире. Кстати, в основе их ближайшего конкурента — Magento — тоже лежит PHP.

Почему же все эти проекты и web-приложения взяли такой критикуемый шаблонизатор за основу? Об этом далее!

О достоинствах

Надо сказать, что большинство позитивных сторон PHP и так известны программистам. Вот перечень преимуществ, которые делают широко применимым его в веб-разработке:

разработка с помощью PHP дает много возможностей. При должном уровне владения, с помощью шаблонизатора можно создавать не только сценарии для веб-приложений, но и полноценные программы. Существуют решения, позволяющие создавать мобильные приложения на PHP;

изучение PHP не требует много времени. Это одновременно и плюс, и минус. Ведь основательное знание требует практики, но об этом позже;

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

поддержка веб-серверов. Сложно найти тот, который бы не работал с PHP;

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

бесплатное распространение. Возможно, PHP не был так популярен для создания web-приложений, если бы не был бесплатным, как и большинство инструментов для работы с ним. Аналоги, которые, в основном, могут выполнить ту же работу, обычно стоят дороже;

имеет достаточную произвольность для web-разработки. Конечно, такие базовые языки, как C-семейство, работают быстрее, но для веба это не критично;

наличие учебных материалов. Все знают о «косяках» PHP лишь потому, что разработку, в основном, ведут с его помощью. Попробуйте найти в Google недостатки «Virtual Reality Modeling Language». Будет сложно, ведь его мало кто знает. Зато основу недостатков «препроцессорa» уже все выучили наизусть из-за широкой используемости языка. Именно потому, если у вас что-то не получается, всегда можно заглянуть в поисковик: с вашей проблемой, вероятнее всего, кто-то уже сталкивался;

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

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

Проблемы, требующие решения

Несмотря на широкую используемость в сфере создания сайтов и web-приложений, у «препроцессорa» действительно есть недостатки. Но если одни видят в них причины не изучать язык, то другие видят предупреждение, которое нужно воспринимать как путеводитель. Среди проблем:

узкопрофильность. Если вы выучили разработку с помощью PHP, то у вас одна дорога — в веб. И хотя возможности расширены различными реализациями, все же он «заточен» под программирование для Интернета;

безопасность. У PHP есть средства безопасности уровня системы и уровня web-приложения. Но, опять же, широкая используемость сыграла злую шутку: дыры в PHP находят быстрее, чем разработчики успевают их закрывать. В PHP 7 множество проблем решено, но злоумышленник всегда впереди. В силу того, что массы знают «препроцессор», трудно предугадать всё;

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

Но основы всех проблем, с которыми связывают PHP, спровоцированы не самим шаблонизатором, а скорее, с окружающими обстоятельствами. Сам по себе язык отлично интегрировался в разработку современных веб-приложений. И такая ситуация сохраняется уже много лет. Начиная с 1998 года веб-разработка с помощью PHP проводится в 8 случаях из 10. Таких долгожителей в программировании не так уж много: тренды меняются очень быстро.

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

Впереди развитие

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

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

Но в отличие от растущего конкурента Go — малоиспользуемого, но эффективного Ruby — новому PHP уже есть, у кого поучиться. Он используется настолько широко, что материалы для освоения выходят почти синхронно с самими версиями. Каждый год ему пророчат полную замену аналогами по разным причинам: считается, что серверная сторона на языке не будет нужна, а ее полностью заменит клиентский JavaScript. Но несмотря на предсказания, новые фреймворки выходят, а самих сайтов на шаблонизаторе меньше не становится.

«Препроцессор», как язык web-приложений, однозначно нужно учить. Человеку, который уже знает С или подобные, он «зайдет» на ура. А тому, кто только пришел в разработку, он не доставит много хлопот. Это настоящий подарок: интересное начинается с самого начала. Так что:

Приемы безопасного программирования веб-приложений на PHP

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

Первой заповедью веб-программиста, желающего написать более-менее защищенное веб-приложение, должно стать «Никогда не верь данным, присылаемым тебе пользователем». Пользователи — это по определению такие злобные хакеры, которые только и ищут момента, как бы напихать в формы ввода всякую дрянь типа PHP, JavaScript, SSI, вызовов своих жутко хакерских скриптов и тому подобных ужасных вещей. Поэтому первое, что необходимо сделать — это жесточайшим образом отфильтровать все данные, присланные пользователем.
Допустим, у нас в гостевой книге существует 3 формы ввода: имя пользователя, его e-mail и само по себе тело сообщения. Прежде всего, ограничим количество данных, передаваемых из форм ввода чем-нибудь вроде:

На роль настоящей защиты, конечно, это претендовать не может — единственное назначение этого элемента — ограничить пользователя от случайного ввода имени длиннее 20-ти символов. А для того, чтобы у пользователя не возникло искушения скачать документ с формами ввода и подправить параметр maxlength, установим где-нибудь в самом начале скрипта, обрабатывающего данные, проверку переменной окружения web-сервера HTTP-REFERER:

Теперь, если данные переданы не из форм документа, находящегося на сервере www.myserver.com, хацкеру будет выдано деморализующее сообщение. На самом деле, и это тоже не может служить 100%-ой гарантией того, что данные ДЕЙСТВИТЕЛЬНО переданы из нашего документа. В конце концов, переменная HTTP_REFERER формируется браузером, и никто не может помешать хакеру подправить код браузера, или просто зайти телнетом на 80-ый порт и сформировать свой запрос. Так что подобная защита годится только от Ну Совсем Необразованных хакеров. Впрочем, по моим наблюдениям, около 80% процентов злоумышленников на этом этапе останавливаются и дальше не лезут — то ли IQ не позволяет, то ли просто лень. Лично я попросту вынес этот фрагмент кода в отдельный файл, и вызываю его отовсюду, откуда это возможно. Времени на обращение к переменной уходит немного — а береженого Бог бережет.

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

Не дадим пользователю использовать пустое поле имени — просто так, чтобы не давать писать анонимные сообщения:

Запретим пользователю использовать в своем имени любые символы, кроме букв русского и латинского алфавита, знака «_» (подчерк), пробела и цифр:

Я предпочитаю везде, где нужно что-нибудь более сложное, чем проверить наличие паттерна в строке или поменять один паттерн на другой, использовать Перл-совместимые регулярные выражения (Perl-compatible Regular Expressions). То же самое можно делать и используя стандартные PHP-шные ereg() и eregi(). Я не буду приводить здесь эти примеры — это достаточно подробно описано в мануале.

Читать еще:  Php ldap bind

Для поля ввода адреса e-mail добавим в список разрешенных символов знаки «@» и «.», иначе пользователь не сможет корректно ввести адрес. Зато уберем русские буквы и пробел:

Поле ввода текста мы не будем подвергать таким жестким репрессиям — перебирать все знаки препинания, которые можно использовать, попросту лень, поэтому ограничимся использованием функций nl2br() и htmlspecialchars() — это не даст врагу понатыкать в текст сообщения html-тегов. Некоторые разработчики, наверное, скажут: «а мы все-таки очень хотим, чтобы пользователи _могли_ вставлять теги». Если сильно неймется — можно сделать некие тегозаменители, типа «текст, окруженный звездочками, будет высвечен bold’ом.». Но никогда не следует разрешать пользователям использование тегов, подразумевающих подключение внешних ресурсов — от тривиального до супернавороченного .

Как-то раз меня попросили потестировать html-чат. Первым же замеченным мной багом было именно разрешение вставки картинок. Учитывая еще пару особенностей строения чата, через несколько минут у меня был файл, в котором аккуратно были перечислены IP-адреса, имена и пароли всех присутствовавших в этот момент на чате пользователей. Как? Да очень просто — чату был послан тег , в результате чего браузеры всех пользователей, присутствовавших в тот момент на чате, вызвали скрипт myscript.pl с хоста myserver.com. (там не было людей, сидевших под lynx’ом 🙂 ). А скрипт, перед тем как выдать location на картинку, свалил мне в лог-файл половину переменных окружения — в частности QUERY_STRING, REMOTE_ADDR и других. Для каждого пользователя. С вышеупомянутым результатом.
Посему мое мнение — да, разрешить вставку html-тегов в чатах, форумах и гостевых книгах — это красиво, но игра не стоит свеч — вряд ли пользователи пойдут к Вам на книгу или в чат, зная, что их IP может стать известным первому встречному хакеру. Да и не только IP — возможности javascript’a я перечислять не буду 🙂

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

Допустим, вся система модерирования книги также состоит из двух частей — страницы со списком сообщений, где можно отмечать подлежащие удалению сообщения, и непосредственно скрипта, удаляющего сообщения. Назовем их соответственно admin1.php и admin2.php.

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

Первый, самый простой способ — авторизация средствами HTTP — через код 401. При виде такого кода возврата, любой нормальный браузер высветит окошко авторизации и попросит ввести логин и пароль. А в дальнейшем браузер при получении кода 401 будет пытаться подсунуть web-серверу текущие для данного realm’а логин и пароль, и только в случае неудачи потребует повторной авторизации. Пример кода для вывода требования на такую авторизацию есть во всех хрестоматиях и мануалах:

Разместим этот кусочек кода в начале скрипта admin1.php. После его выполнения, у нас будут две установленные переменные $PHP_AUTH_USER и PHP_AUTH_PW, в которых соответственно будут лежать имя и пароль, введенные пользователем. Их можно, к примеру, проверить по SQL-базе:

*** Внимание. ***
В приведенном ниже фрагменте кода сознательно допущена серьезная ошибка в безопасности. Попытайтесь найти ее самостоятельно.

Упомянутая ошибка, между прочим, очень распространена среди начинающих и невнимательных программистов. Когда-то я сам поймался на эту удочку — по счастью, особого вреда это не принесло, не считая оставленных хакером в новостной ленте нескольких нецензурных фраз.
Итак, раскрываю секрет: допустим, хакер вводит заведомо несуществующее имя пользователя и пустой пароль. При этом в результате выборки из базы переменная $rpassword принимает пустое значение. А алгоритм шифрования паролей при помощи функции СУБД MySQL Password(), так же, впрочем, как и стандартный алгоритм Unix, при попытке шифрования пустого пароля возвращает пустое значение. В итоге — $password == $rpassword, условие выполняется и взломщик получает доступ к защищенной части приложения. Лечится это либо запрещением пустых паролей, либо, на мой взгляд, более правильный путь — вставкой следующего фрагмента кода:

То есть — проверкой наличия одного и только одного пользователя в базе. Ни больше, ни меньше.
Точно такую же проверку на авторизацию стоит встроить и в скрипт admin2.php. По идее, если пользователь хороший человек — то он приходит к admin2.php через admin1.php, а значит, уже является авторизованным и никаких повторных вопросов ему не будет — браузер втихомолку передаст пароль. Если же нет — ну, тогда и поругаться не грех. Скажем, вывести ту же фразу «hacker? he-he…».
К сожалению, не всегда удается воспользоваться алгоритмом авторизации через код 401 и приходится выполнять ее только средствами приложения. В общем случае модель такой авторизации будет следующей:

  • Пользователь один раз авторизуется при помощи веб-формы и скрипта, который проверяет правильность имени и пароля.
  • Остальные скрипты защищенной части приложения каким-нибудь образом проверяют факт авторизованности пользователя.

Такая модель называется сессионной — после прохождения авторизации открывается так называемая «сессия», в течение которой пользователь имеет доступ к защищенной части системы. Сессия закрылась — доступ закрывается. На этом принципе, в частности, строится большинство www-чатов: пользователь может получить доступ к чату только после того, как пройдет процедуру входа. Основная сложность данной схемы заключается в том, что все скрипты защищенной части приложения каким-то образом должны знать о том, что пользователь, посылающий данные, успешно авторизовался.
Рассмотрим несколько вариантов, как это можно сделать:

  1. После авторизации все скрипты защищенной части вызываются с неким флажком вида adminmode=1. (Не надо смеяться — я сам такое видел). Ясно, что любой, кому известен флажок adminmode, может сам сформировать URL и зайти в режиме администрирования. Кроме того — нет возможности отличить одного пользователя от другого.
  2. Скрипт авторизации может каким-нибудь образом передать имя пользователя другим скриптам. Распространено во многих www-чатах — для того, чтобы отличить, где чье сообщение идет, рядом с формой типа text для ввода сообщения, пристраивается форма типа hidden, где указывается имя пользователя. Тоже ненадежно, потому что хакер может скачать документ с формой к себе на диск и поменять значение формы hidden. Некоторую пользу здесь может принести вышеупомянутая проверка HTTP_REFERER — но, как я уже говорил, никаких гарантий она не дает.
  3. Определение пользователя по IP-адресу. В этом случае, после прохождения авторизации, где-нибудь в локальной базе данных (sql, dbm, да хоть в txt-файле) сохраняется текущий IP пользователя, а все скрипты защищенной части смотрят в переменную REMOTE_ADDR и проверяют, есть ли такой адрес в базе. Если есть — значит, авторизация была, если нет — «hacker? he-he…» 🙂
    Это более надежный способ — не пройти авторизацию и получить доступ удастся лишь в том случае, если с того же IP сидит другой пользователь, успешно авторизовавшийся. Однако, учитывая распространенность прокси-серверов и IP-Masquerad’инга — это вполне реально.
  4. Единственным, известным мне простым и достаточно надежным способом верификации личности пользователя является авторизация при помощи random uid. Рассмотрим ее более подробно.

После авторизации пользователя скрипт, проведший авторизацию, генерирует достаточно длинное случайное число:

Это число он:
а) заносит в локальный список авторизовавшихся пользователей;
б) Выдает пользователю.

Пользователь при каждом запросе, помимо другой информации (сообщение в чате, или список сообщений в гостевой книге), отправляет серверу свой uid. При этом в документе с формами ввода будет присутствовать, наряду с другими формами, тег вида:

Форма uid невидима для пользователя, но она передается скрипту защищенной части приложения. Тот сличает переданный ему uid с uid’ом, хранящимся в локальной базе и либо выполняет свою функцию, либо… «hacker? he-he…».
Единственное, что необходимо сделать при такой организации — периодически чистить локальный список uid’ов и/или сделать для пользователя кнопку «выход», при нажатии на которую локальный uid пользователя сотрется из базы на сервере — сессия закрыта.

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

Читать еще:  Asp phpsessid непостижимость court

В заключение стоит упомянуть и о такой полезной вещи, как ведение логов. Если в каждую из описанных процедур встроить возможность занесения события в лог-файл с указанием IP-адреса потенциального злоумышленника — то в случае реальной атаки вычислить хакера будет гораздо проще, поскольку хакеры обычно пробуют последовательно усложняющиеся атаки. Для определения IP-адреса желательно использовать не только стандартную переменную REMOTE_ADDR, но и менее известную HTTP_X_FORWARDED_FOR, которая позволяет определить IP пользователя, находящегося за прокси-сервером. Естественно — если прокси это позволяет.
При ведении лог-файлов, необходимо помнить, что доступ к ним должен быть только у Вас. Лучше всего, если они будут расположены за пределами дерева каталогов, доступного через WWW. Если нет такой возможности — создайте отдельный каталог для лог-файлов и закройте туда доступ при помощи .htaccess (Deny from all).

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

Учимся писать веб-приложения

Итак, вот список тем, с которыми надо познакомиться, уроков, которые надо изучить, и, самое главное — задач, которые надо решить:

Изучаем веб-сервер и устанавливаем PHP

Для начала, надо научиться выводить результат выполнения программы на PHP в браузер в виде веб-страницы. Для этого придется изучить, как работает браузер и веб-сервера, познакомиться с протоколом HTTP. Надо будет прочесть:

Возможно, придется также прочитать эти уроки:

При установке PHP или Апача может понадобиться пользоваться командной строкой. На этот случай у нас есть урок по использованию командной строки.

При верстке веб-страниц используются языки HTML и CSS и их надо освоить хотя бы на начальном уровне. Не надо бояться, они относительно простые и изучить их проще, чем PHP. У нас нет своего большого учебника по ним, а есть небольшой курс, который содержит ссылки на другие учебники, краткие пояснения и самое главное — задачи, каждая из которых помогает понять ту или иную особенность верстки. Итак, вот он:

HTML/CSS можно изучать параллельно с написанием веб-приложений на PHP, чтобы не терять время.

Ах да, ты еще не начал изучать английский? Тогда начинай. Стать профессиональным разработчиком без английского будет сложно.

Пробуем писать более сложные приложения

Теперь можно переходить от написания отдельных страниц к интерактивным простым сайтам. Для начала надо решить первую и очень важную задачу под названием «Список абитуриентов»:

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

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

Решение задачи желательно выложить на Гитхаб (или аналогичный сайт), где его смогут увидеть все желающие. Github — это сайт, который позволяет создавать на нем git-репозитории (хранилища кода), и загружать туда свой код. Для этого надо изучить программу для работы с git-репозиториями под названием git. Она подробно описана на русском языке в Git Book: https://git-scm.com/book/ru/v2

В задаче используется база данных. У нас есть что-то вроде небольшого урока по базам данных и языку SQL: https://gist.github.com/codedokode/10539213

Для взаимодействия с базой данных я советую изучить расширение PDO.

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

Осваиваем фреймворки

Задача про абитуриентов учит писать простые веб-приложения с нуля. Но реальные проекты обычно пишут на основе — специальных библиотек, которые содержат основу, каркас приложения. Это позволяет избежать «изобретения велосипеда и позволяет использовать готовый код, а также грамотно организовать архитектуру приложения. Мы начнем с изучения относительно несложных микрофреймворков, для этого у нас есть задача:

Параллельно с решением задачи стоит продолжить изучать верстку. Кроме HTML и CSS, надо знать еще язык Javascript — он позволяет внедрять в страницы простые программки (, которые делают ее более интерактивной). У нас есть курс задач по языку javascript. Там же дана ссылка на учебник по JS (learn.javascript.ru) и автоматизированную проверялку для части задач.

Также, эта задача — хороший повод познакомиться с ORM, в случае PHP главный ORM — это Doctrine. Ее конечно не обязательно использовать, но с ней решать задачу будет интереснее.

Для установки библиотек и фреймворков стоит использовать composer.

Переходим к сложным приложениям

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

Я рекомендую решать ее с использованием Symfony (или же с использованием отдельных компонент Симфони) и ORM Doctrine. Это непросто, но даст много полезных навыков и знаний.

Написанный код надо тестировать. Обычно мы это делали вручную, открывая страницы и нажимая кнопочки, но со временем эта рутина начинает надоедать. Значит, надо осваивать автоматизированное тестирование, и у нас есть урок на эту тему:

Дополнительное чтение

Вот еще список ссылок, которые стоит почитать:

  • Официальный мануал, который должен быть у тебя на первом месте по числу посещений: http://www.php.net/manual/ru/langref.php
  • Сайт про «правильный» PHP: http://getjump.me/ru-php-the-right-way/
  • Мой гитхаб, где выкладываются самые новые уроки и черновики: https://github.com/codedokode/pasta/
  • Почитать про паттерны проектирования http://designpatternsphp.readthedocs.org/ru/latest/README.html (если ты не изучил ни одного фреймворка, то это будет рановато). Имей в виду что без примеров использования их учить бесполезно — не поймешь, хочешь увидеть примеры использования паттернов — ковыряй исходники Симфони, например Symfony Forms. Не заучивай паттерны — смотри код и думай, зачем тут они использованы. Не усложняй код! Ты не должен использовать все паттерны подряд без необходимости!
  • Также, я советую учиться решать олимпиадные задачи. Они помогают находить правильные алгоритмы, оптимизировать код. Есть хороший сайт, где представлены задачи самой разной сложности и есть возможность проверки решения: http://codeforces.com/problemset
  • Также, есть такой учебник по алгоритмам и структурам данных: http://aliev.me/runestone/

Хочется поломать голову?

Пройдя все задачи выше, ты скорее всего станешь неплохим начинающим разработчиком. Однако, наверняка тебе захочется решить что-то посложнее, задачу, на которой споткнутся даже опытные программисты. Ну разумеется, у нас есть такая задача! Сейчас (в конце 2016 года) много внимания уделяется написанию клиентских («одностраничных») приложений, на слуху названия вроде Angular или React, и у нас есть задачка по теме:

Она довольно сложная, и пока даже автор не представляет полностью, как ее лучше решить. Увы, не понаступав на грабли, и не попробовав разные подходы, это не понять. (Кстати, автор хочет похвастаться: он участвовал в написании одностраничных приложений когда это еще не было в тренде).

Куда вводить код? Что надо скачать? Читай первый урок.

Есть вопросы? Задай гуглу или автору.

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

Как связаться с автором? Я хочу переодеть его в платье школьницы и жениться на нем. Ящик codedokode (кот) gmail.com ждет ваших писем. А вконтактик и фейсбучек ждут ваших лайков. Но ответ на банальные вопросы лучше искать в Гугле или на stackoverflow.

Я решил задачку. Молодец, делай следующий урок

Ideone не работает!11 Ну так открой Гугл и найди сайты вроде https://repl.it/languages/php , http://phptester.net/ , http://sandbox.onlinephpfunctions.com/ , http://codepad.org/ или http://www.runphponline.com/ . Не ленись.

Почему так много рекламы? Всю рекламу на сайте ставит юкоз (бесплатный хостинг же), а не я.

На сайте установлена система Google Analytics (и еще несколько аналогичных систем от юкоза). Данные о твоем IP-адресе, посещаемых страницах, времени посещения отправляются в Google Corporation, США. Хочу знать, кто и зачем сюда заходит. Поверь, другие сайты делают точно так же. Все сайты пишут логи.

  • Начало
    • Переменные
    • Условия и игра в кубики
    • Циклы и айфон в кредит
    • Массивы и рулетка
    • Строки, хакеры и шифровки
    • Функции и новый айпад
    • Регулярные выражения
    • Повторим?
    • Бонусные задачки
    • Пасты и ООП
    • Учим сами
  • Что делать дальше?
  • Я у мамы умный

Что это?

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

Скачивать и устанавливать тоже ничего не надо, делать уроки можно даже с айпада или ведроида.

Ссылка на основную публикацию
Adblock
detector