Непрезентабельный html signup php. Форма в вашем layout. Основной контент страницы

August 23, 03:17 pm

tutorials

articles

scripts

contact

Welcome to PHPRecipes, the starting place for PHP scripts, tutorials,

and gourmet cooking tips and recipes!

Copyright 2000 PHPRecipes. All rights reserved.

contact |

your privacy

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

Рис. 9.1. Внешний вид страницы, построенной в листинге 9.8

Оптимизация шаблонов

Во втором (на мой взгляд, более предпочтительном) варианте шаблоны оформляются в виде функций, находящихся в отдельном файле. Тем самым обеспечивается дополнительное структурирование ваших шаблонов. Я называю этот файл инициализационным файлом и храню в нем другую полезную информацию. Поскольку мы уже рассмотрели относительно длинные примеры заголовка и колонтитула, содержимое листингов 9.10 и 9.11 было слегка сокращено для наглядной демонстрации новой идеи.

Листинг 9.10. Оптимизированный шаблон сайта (site_init.tpl)

// Файл: site_init.tpl

// Назначение: инициализационный файл PhpRecipes

$site_name = "PHPRecipes";

$site_email = "[email protected]";

$site_path = "http://localhost/phprecipes/";

function show_header($site_name) {

This is the header

function show footer ()

This Is the footer

Листинг 9.11. Применение инициализационного файла

// Включить инициализационный файл

include("site_init.tpl");

// Вывести заголовок

show header ($site_name);

// Содержимое основной части This is some body information

// Вывести колонтитул Show_footer();

Проект: генератор страниц

Хотя в большинстве созданных мною web-сайтов основное содержимое страниц формировалось на основании информации, прочитанной из базы данных, всегда найдется несколько страниц, которые практически не изменяются. В частности, на них могут выводиться сведения о команде разработчиков, контактные данные, реклама и т. д. Я обычно храню эту «статическую» информацию в отдельной папке и использую сценарий PHP для ее загрузки при поступлении запроса. Конечно, у вас возникает вопрос -- если это статическая информация, для чего нужен сценарий PHP? Почему бы не загружать обычные страницы HTML? Преимущество PHP заключается в том, что вы можете использовать шаблоны и вставлять статические фрагменты по мере необходимости.

<а href = "/static.php?content=$content">Static Page Name

Начнем с создания статических страниц. Для простоты я ограничусь тремя страницами, содержащими информацию о сайте (листинг 9.12), рекламу (листинг 9.13) и контактные данные (листинг 9.14).

Листинг 9.12. Информация о сайте (about.html)

About PHPRecipes

What programmer doesn"t mix all night programming with gourmet cookies. Here at PHPRecipes. hardly a night goes by without one of our coders mixing a little bit of HTML with a tasty plate of Portobello Mushrooms or even Fondue. So we decided to bring you the best of what we love most: PHP and food!

That"s right, readers. Tutorials, scripts, souffles and more. 0nly at PHPRecipes.

Advertising Information

Regardless of whether they come to learn the latest PHP techniques or for brushing up on how

to bake chicken, you can bet our readers are decision makers. They are the Industry

professionals who make decisions about what their company purchases.

For advertising information, contact

">[email protected].

Листинг 9.14. Контактные данные (contact.html)

Contact Us

Have a coding tip?

Know the perfect topping for candied yams?

Let us know! Contact the team at [email protected].

Переходим к построению страницы static.php, которая выводит запрашиваемую статическую информацию. В этот файл (см. листинг 9.15) включаются компоненты страниц нашего сайта и инициализационный файл site_init.tpl.

Листинг 9.15. Общий вывод статических страниц (static.php)

// Файл: static.php

// Назначение: отображение запрашиваемых статических страниц.

// ВНИМАНИЕ: предполагается, что файл "site_init.tpl" и все

// статические файлы находятся в том же каталоге.

// Загрузить функции и переменные include("site_init.tpl"):

// Вывести заголовок show_header($site_name);

// Вывести запрашиваемое содержание include("$content.html"):

// Вывести колонтитул show footer();

Теперь все готово к построению основного сценария. Просто включите в страницу

<а href = "static.php?content=about">Static Page Name

Advertising Information

Contact Us

Если щелкнуть на любой из этих ссылок, в браузере загружается соответствующая статическая страница, внедренная в static.php!

Итоги

В этой главе вы познакомились с первоочередной задачей, для решения которой и создавался PHP, -- динамическим построением web-страниц. Были рассмотрены следующие вопросы:

• обработка URL;
• построение динамического содержания;
• включение и построение базовых шаблонов.

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

Следующая глава посвящена использованию PHP в сочетании с формами HTML, заметно повышающими степень интерактивности вашего сайта. А потом -- взаимодействие с базами данных! Вам предстоит узнать много интересного.

Я пытаюсь создать форму входа. Это мой код HTML-формы

Лично я получил за PDO.

Очки 4 и 5

$password = mysql_real_escape_string(stripslashes(md5($_POST["password"])));

Во-первых, порядок этого неверен. Вы хешируете $_POST["password"] а затем пытаетесь использовать stripslashes – после его хэши не будет никаких слэшей. Однако, если вы пытаетесь запретить людям использовать косые черты (или что-то еще) в паролях, вам необходимо удалить их перед тем, как хэшировать строку.

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

Да, вы должны хранить хэши или «отпечатки пальцев» паролей, а не сами пароли, но в идеале вы хотите солить и хэш (с хотя бы sha1) этими паролями, а не просто бросать их в функцию md5() .

И выполните поиск по «хэш-настройке пароля», используя вашу поисковую систему по выбору.

Пункт 6

SELECT id FROM $table WHERE username = "" . $username . "" and password = "" . $password . "";

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

SELECT user.id FROM user WHERE user.username = "fred" OR 1 = 1 -- AND user.password = "abc123"

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

Пункт 7

$_SESSION["user"] = $_POST["username"];

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

Идентификатор сеанса можно легко обнюхать из файла cookie в режиме реального времени, и это все, что потребуется для «заимствования» чужого имени пользователя. Вы должны хотя бы попытаться уменьшить вероятность захвата сеанса, связав IP-адрес пользователя, строку UserAgent или некоторую другую комбинацию относительно статических данных, которые можно сравнить с каждой страницей … есть недостатки практически любого подхода, хотя (особенно, как я уже нашел, если у вас есть посетители, использующие AOL), но вы можете сделать возможный 99% -ный эффективный сеанс отпечатка пальца, чтобы уменьшить захват с очень небольшим шансом, что сеанс пользователя будет ошибочно сброшен.

В идеале вы также можете создать токен для сеанса для смягчения атак CSRF, когда пользователю необходимо выполнить «привилегированное» действие в базе данных (обновить их данные или что-то еще). Маркер может быть абсолютно случайным и уникальным кодом, хранящимся в базе данных и / или в файле cookie SSL, когда пользователь входит в систему (при условии, что пользователь не может выполнять никаких действий, которые обновляют базу данных за пределами HTTPS, поскольку это просто передаст данные в ясном тексте через Интернет – что было бы плохой идеей ).

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

Это может быть несколько проблем.

Во-первых, в вашем заявлении $ match у вас отсутствует оператор равенства по паролю:

$match = "SELECT id FROM $table WHERE username = "".$username."" and password"".$password."";";

Должно быть:

$match = "SELECT id FROM $table WHERE username = "".$username."" and password = "".$password."";";

Во-вторых , вы вставляете пароль в базу данных после его использования с помощью md5?

Если нет, то ваш запрос пытается сопоставить md5 (пароль) с паролем.

П ри создании даже персонального сайта, далеко не каждый может предусмотреть все возможные способы его дальнейшего использования. Очень важно подготовить почву для дальнейшего развития сайта. Если в прошлом вы создали сайт и по умолчанию присвоили всем страницам расширение.html , а только потом решили использовать PHP, то тогда читайте дальше.

Раньше для использования SSI, названия страниц сайта должны были заканчиваться расширением.shtml , но сегодня большинство интернет-серверов сконфигурированы так, что SSI можно использовать и на страницах с расширением.html , что весьма удобно. С PHP совсем другая история — расширение.php является расширением по умолчанию. Разработчики сайтов, заранее зная, что будет использоваться данный язык программирования, стразу присваивают правильное расширение.

Но что делать, когда все страницы заканчиваются расширением.html ?

Заменяем расширение HTML на PHP

Это можно сделать несколькими способами. Самый явный способ — дать всем страницам расширение.php или изменить уже существующие расширения (.html, .shtml и т.д.). У этого способа есть недостатки. Например уже проиндексированным страницам с расширением.html придётся заново индексироваться поисковыми системами. Или ещё хуже — все внешние ссылки, которые ссылаются явным образом на ту или иную страницу, будут недействительны. И придется оповещать владельцев каждого сайта об этих изменениях и создавать для каждой страницы еще одну страницу с 301 ошибкой. Конечно, изменить одно расширение на другое допустимо, но что делать если сайт уже имеет много страниц и много ссылок на разные страницы с других сайтов?

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

Можно обойтись и другим способом. Если сервер, на котором размещается сайт, поддерживает mod_rewrite (в большинстве случаев поддерживает), и есть доступ к файлу.htaccess , то можно добавить следующие строки в этот самый файл:

RewriteEngine on RewriteRule ^(.*)\.html $1\.php

Добавив этот код в.htaccess , можно не волноваться. Все запрашиваемые несуществующие страницы с расширением.html будут автоматически заменяться расширением.php благодаря чудесам от Apache. Но и этот способ является не единственным. Можно прописать следующее в том же самом.htaccess файле:

AddHandler application/x-httpd-php .php .html .htm

На мой взгляд самый удачный способ. Это делает HTML-страницы равными PHP-страницам, то есть все функции PHP теперь могут быть использованы на страницах с расширением HTML. Если нет доступа к файлу.htaccess , то можно написать письмо хостинг компании, и вежливо попросить админов прописать в конфигурации Apache (httpd.conf) нужное значение для сайта.

Кстати, если до этого на сайте использовалось SSI следующим образом:

то тогда в новом PHP’шном состоянии этот код нужно заменить на:

Ну вот и всё, думаю какой-нибудь из вышеприведённых способов поможет.

Часто возникает вопрос о том, как расположить одну форму на всех страницах вашего Zend приложения. Допустим я хочу расположить форму подписки в файле layout.phtml для того, чтобы она располагалась на каждой странице. Команда layout->content() работает с действиями и контроллерами... Как же реализовать то, что нам нужно?

Одно из решений данной задачи - это создание помощника действия.

Начнём с настройки ZF приложения:

$ zf create project layoutform $ cd layoutform $ zf enable layout

Очистите файл application/views/scripts/index/index.phtml и вставьте что-то вроде этого:

application/views/scripts/index/index.phtml:

This is the home page

Теперь можем начинать.

Форма

Создадим новую форму:

$ zf create form signup

А так же поля, которые нам необходимы:

application/forms/Signup.php:

Class Application_Form_Signup extends Zend_Form { public $processed = false; public function init() { $this->addElement("text", "name", array("label" => "Name", "required" => true, "validators" => array(array("StringLength", false, array("max"=>75)),),)); $this->addElement("text", "email", array("label" => "Email", "required" => true, "validators" => array(array("StringLength", false, array("max"=>150)), "EmailAddress",),)); $this->addElement("submit", "go", array("label" => "Sign up",)); } }

Форма у нас есть. Осталось её вывести.

Помощник действия

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

Добавьте строку в application.ini:

application/configs/application.ini:

Resources.frontController.actionhelperpaths.Application_Controller_Helper = APPLICATION_PATH "/controllers/helpers"

Теперь система знает в каком месте искать помощники действий, так что можем идти дальше:

application/Bootstrap.php:

bootstrap("frontController"); $signup = Zend_Controller_Action_HelperBroker::getStaticHelper("Signup"); Zend_Controller_Action_HelperBroker::addHelper($signup); } }

Помощник действия будет выглядеть следующим образом:

application/controllers/helpers/Signup.php:

getActionController()->view; $form = new Application_Form_Signup(); $request = $this->getActionController()->getRequest(); if($request->isPost() && $request->getPost("submitsignup")) { if($form->isValid($request->getPost())) { $data = $form->getValues(); // process data $form->processed = true; } } $view->signupForm = $form; } }

Тут ничего особенного нет. Просто обратите внимание на класс родитель.

Помощник вида

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

application/views/helpers/SignupForm.php:

Sign up for our newsletter

Thank you for signing up

"; } else { $html .= $form->render(); } return $html; } }

Всё, что нам осталось, так это сделать вывод формы в layout.phtml:

application/layouts/scripts/layout.phtml:

headMeta()->prependHttpEquiv("Content-Type", "text/html; charset=UTF-8"); $this->headTitle("Layout form test"); echo $this->doctype(); ?> headMeta()->setIndent(4); ?> headTitle()->setIndent(4); ?>

Получилось

Вот и всё. Мы добились той функциональности, которую задумали.

Последние материалы раздела: