Спустя 1 минута, 46 секунд (16.03.2010 - 00:00) phz написал(а):
Вот читайте http://www.phpfaq.ru/sessions
Спустя 3 минуты, 35 секунд (16.03.2010 - 00:04) Awilum написал(а):
в БД должна быть таблица users где и будет ваш админ с особыми правами
делаете формочку для авторизации.
проверяете то что в формочке и то что в таблице users
если такой юзер найден "выдаете ему права админа" создаете сессию с его правами и id и на нужной странице
проверяете на существование в сессии юзера и именно такого с такими правами...
делаете формочку для авторизации.
проверяете то что в формочке и то что в таблице users
если такой юзер найден "выдаете ему права админа" создаете сессию с его правами и id и на нужной странице
проверяете на существование в сессии юзера и именно такого с такими правами...
Спустя 4 минуты, 34 секунды (16.03.2010 - 00:08) Awilum написал(а):
быстрый вариант, на скорую руку
if(($_SESSION['login'] == 'admin') and ($_SESSION['pass'] == 'password')) {
// вся админка тут
} else {
// показываем формочку для авторизации
}
Спустя 7 минут, 20 секунд (16.03.2010 - 00:16) Гость_Дмитрий написал(а):
Уважаемый "Старик",
а где нужно написаь то, что вы указали выше?
а где нужно написаь то, что вы указали выше?
Спустя 6 часов, 29 минут, 11 секунд (16.03.2010 - 06:45) Игорь_Vasinsky написал(а):
Пока попробуйте самостоятельно разобрать такой пример, ответы вечером, щас работа ждёт:
Авторы - Семенов А.Н., Симдянов И.В.
Чтобы обезопасить себя от такого вида атак, следует отфильтровать значение, передаваемое через параметр username, например, при помощи регулярных выражений:
Можно заострить внимание посетителя на том, что введённые им данные содержат недопустимые символы, за счёт вывода в окно браузера "предупреждения".
Что предпринять — выбор за вами. Лучше написать о разрешенных символах где-нибудь рядом с соответствующим полем HTML-формы, иначе посетитель может вести свое имя и обнаружить что оно отображается не совсем так, как он ожидал (например Elvi$ как Elvi) и ему придется проходить процедуру регистрации повторно. Кроме того, посетитель может случайно вести неверный символ и устрашающий вид страницы plz_die.php, может его отпугнуть.
Пусть имеется база данных пользователей users, содержащая три поля: первичный ключ (id_user), имя пользователя (name) и его пароль (pass). SQL-оператор CREATE, создающий данную таблицу приведён ниже.
Авторизация пользователей производится через HTML-форму.
<form action=handler.php method=post>
Имя посетителя : <input type=text name=name >
Пароль : <input type=password name=pass >
Обработчик handler.php проверяет соответствие введённого имени паролю
Данный метод авторизации обходиться указанием следующего значения для пароля pass:
123' AND 1=1
Или даже еще проще, например вводом следующего значения в качестве имени name:
admin'/*
Все что следует за "/*" считается комментарием. В любом из этих случаев будет получен допуск в защищенную область сайта. Как вы уже, наверное, успели заметить, атака основывается через указание кавычки, позволяющей выйти за рамки, отведенных программистом.
Методом защиты служит, как и предыдущем случае, фильтрацией данных.
Вот несколько вариантов. Приведено только для переменной name, лишь для экономия места.
Может быть использован любой из них или их комбинации.
В некоторых случаях для в формирования SQL используется не строчка, а цифра. Это наиболее опасно, потому что злоумышленнику даже не надо добавлять кавычку, а сразу добавлять код после пробела.
Параметр $id злоумышленника тогда будет иметь такой вид:
1/*
ВСЕ!
Проблема числовых параметров, встала еще более остро, начиная с MYSQL 4, где появился SQL-оператор UNION, который позволяет объединить результаты нескольких запросов. Пусть страницу с информацией о пользователе формирует скрипт user.php, который принимает в качестве параметра первичный ключ id_user из таблицы users.
Результатом работы скрипта при обращении к странице по адресу users.php?id_user=1 является вывод имени посетителя: user1
Теперь помещая в адресную строку следующий адрес
http://localhost/user.php?id_user=-1%20UNI...ERE%20id_user=1
можно получить пароль пользователя с первичным ключом id_user = 1: pass1.
Поэтому необходимо подвергать пароли в базе данных необратимому шифрованию, например при помощи встроенных функций MySQL: MD5 и PASSWORD. Проверить содержимое числового параметра можно при помощи следующего регулярного выражения:
Или при помощи функции is_numeric()
Третий вид атаки, который может быть произведён на сайт — это флуд, часто в автоматической форме.
Злоумышленник может загрузить страницу с формой добавления сообщения к себе на локальный компьютер и добавить несколько сотен сообщений в гостевую книгу или форум. Для предотвращения такого вида атак существует два метода борьбы.
ОСОБОЕ ВНИМАНИЕ
Проверка элемента суперглобального массива $_SERVER['REFERRER'] на предмет содержания в нём адреса исходного сайта, позволяет устранить данный вид атаки
Не стоит сильно надеяться на эту защиту, ведь HTTP_REFERER формируется браузером, а значит, может быть подделан. Поэтому когда необходима более надёжная защита необходимо прошить HTML-форму сессией.
<?php
// Инициируем сессию
session_start();
?>
Как видно HTML-форма содержит дополнительное поле с именем session_id. После того как пользователь нажимает на кнопку "Отправить" данные отправляются обработчику:
В котором значение поля session_id проверяется с текущим идентификатором сессии
Теперь несколько рекомендаций по защите сайта.
1. Не используйте проверку на возращение строки (mysql_num_rows()), а применяйте следующий подход:
2. Не используйте на прямую foreach() для массивов переменных переданных от пользователя
Злоумышленник может подправить код и добавить еще один параметр к массиву.
Как альтернативу можно предложить следующий код:
3. Там где не требуется ввод большого объёма данных ограничивайте число вводимых в HTML-форму символов, за это несёт ответственность параметр maxlength тега input. Например, в следующем текстовом поле ввести можно не более 32 символов:
Можно организовать проверку и непосредственно в скрипте
И напоследок несколько блиц-советов:
• лучше использовать "белый" список чем "черный" (Лучше разрешать только нужное, чем запрещать ненужное)
• помните, что картинка может на самом деле оказать скриптом!
• когда дело доходит до взлома, злоумышленник проявляет всю изобретательность, заложенную в него природой, в тоже время, когда дело доходит защиты, программист же демонстрирует верх скудоумия и однообразности, так как ему чисто психологически не хочется ломать собственное творение. Для тестирования своего сайта приглашайте сторонних людей.
• если код Web-приложения неизвестен злоумышленнику, его гораздо сложнее ломать. Не ленитесь – напишите собственное Web-приложение, на своём уникальном движке – не используйте готовые широкоизвестные Web-приложения. В тоже время постарайтесь не выводить полный отчёт при возникновении ошибки по которому легко восстановить логику Web-приложения.
Вот теперь, пожалуй, и все. Конечно, затронуты далеко не все вопросы создания безопасного кода на PHP и не так подробоно, как хотелось бы... но мы надемся продолжить рассмотрение данного вопроса в следующих статьях.
Авторы - Семенов А.Н., Симдянов И.В.
Чтобы обезопасить себя от такого вида атак, следует отфильтровать значение, передаваемое через параметр username, например, при помощи регулярных выражений:
<?php
// Удаляем все символы кроме букв и цифр
$username = preg_replace("/[^a-z0-9]/i", "", $_GET['username']);
?>
Можно заострить внимание посетителя на том, что введённые им данные содержат недопустимые символы, за счёт вывода в окно браузера "предупреждения".
<?php
// Проверяем все символы на буквы и цифры
if( !( preg_match("/^([a-z0-9]*)$/i", $_GET['username']) ) )
{
header("plz_die.php");
}
?>
Что предпринять — выбор за вами. Лучше написать о разрешенных символах где-нибудь рядом с соответствующим полем HTML-формы, иначе посетитель может вести свое имя и обнаружить что оно отображается не совсем так, как он ожидал (например Elvi$ как Elvi) и ему придется проходить процедуру регистрации повторно. Кроме того, посетитель может случайно вести неверный символ и устрашающий вид страницы plz_die.php, может его отпугнуть.
Пусть имеется база данных пользователей users, содержащая три поля: первичный ключ (id_user), имя пользователя (name) и его пароль (pass). SQL-оператор CREATE, создающий данную таблицу приведён ниже.
CREATE TABLE users (
id_user int(11) NOT NULL auto_increment,
name tinytext,
pass tinytext,
PRIMARY KEY (id_user)
) TYPE=MyISAM;
INSERT INTO users VALUES (1, 'user1', 'pass1');
INSERT INTO users VALUES (2, 'user2', 'pass2');
INSERT INTO users VALUES (3, 'user3', 'pass3');
Авторизация пользователей производится через HTML-форму.
<form action=handler.php method=post>
Имя посетителя : <input type=text name=name >
Пароль : <input type=password name=pass >
<input type=submit value=Отправить>
</form>
Обработчик handler.php проверяет соответствие введённого имени паролю
<?php
// Устанавливаем соединение с базой данных
include "config.php";
// Осуществляем соответствия имени паролю
$query = "SELECT * FROM users
WHERE name = '$_POST[name]' AND
pass = '$_POST[pass]'";
$usr = mysql_query($query);
if(!$usr) exit("Ошибка в SQL-запросе");
if(mysql_num_rows($usr)>0)
{
// Вход в защищённую область сайта
}
?>
Данный метод авторизации обходиться указанием следующего значения для пароля pass:
123' AND 1=1
Или даже еще проще, например вводом следующего значения в качестве имени name:
admin'/*
Все что следует за "/*" считается комментарием. В любом из этих случаев будет получен допуск в защищенную область сайта. Как вы уже, наверное, успели заметить, атака основывается через указание кавычки, позволяющей выйти за рамки, отведенных программистом.
Методом защиты служит, как и предыдущем случае, фильтрацией данных.
Вот несколько вариантов. Приведено только для переменной name, лишь для экономия места.
<?php
// добавляем слеши перед кавычками, чтобы они стали виде escape-последовательности,
// например ' замениться на ', " замениться на "
$_POST['name'] = addslashes($_POST['name']);
// заменяем все специальные символы эквивалентом
$_POST['name'] = htmlspecialchars ($_POST['name']);
// отрезаем все ненужные симовлы
$_POST['name'] = preg_replace("/[^a-z0-9]/i", "", $_POST['name']);
?>
Может быть использован любой из них или их комбинации.
В некоторых случаях для в формирования SQL используется не строчка, а цифра. Это наиболее опасно, потому что злоумышленнику даже не надо добавлять кавычку, а сразу добавлять код после пробела.
<?php
$id = $_POST['id'];
$pass = $_POST['passw'];
$sql = "SELECT info FROM users WHERE user_id = $id AND pass = '$pass'"
// если запрос не вернул результат, то пользователь не найден
if( !( mysql_num_rows( mysql_query( $sql ) ) ) )
{
echo 'Нет такого пользователя';
}
?>
Параметр $id злоумышленника тогда будет иметь такой вид:
1/*
ВСЕ!
Проблема числовых параметров, встала еще более остро, начиная с MYSQL 4, где появился SQL-оператор UNION, который позволяет объединить результаты нескольких запросов. Пусть страницу с информацией о пользователе формирует скрипт user.php, который принимает в качестве параметра первичный ключ id_user из таблицы users.
<?php
// Устанавливаем соединение с базой данных
include "config.php";
// Осуществляем запрос к базе данных,
// извлекая запись из таблицы user
if(isset($_GET['id_user']))
{
// Формируем SQL-запрос
$query = "SELECT * FROM users WHERE id_user = ".$_GET['id_user'];
// Выполняем SQL-запрос
$usr = mysql_query($query);
if($usr) exit("Ошибка при обращении к таблице пользователей");
$user = mysql_fetch_array($usr);
// Выводим имя пользователя
echo $user['name'];
}
?>
Результатом работы скрипта при обращении к странице по адресу users.php?id_user=1 является вывод имени посетителя: user1
Теперь помещая в адресную строку следующий адрес
http://localhost/user.php?id_user=-1%20UNI...ERE%20id_user=1
можно получить пароль пользователя с первичным ключом id_user = 1: pass1.
Поэтому необходимо подвергать пароли в базе данных необратимому шифрованию, например при помощи встроенных функций MySQL: MD5 и PASSWORD. Проверить содержимое числового параметра можно при помощи следующего регулярного выражения:
<?php
if(!preg_match("|^[d]*$|", $_GET['id_theme'])) exit();
?>
Или при помощи функции is_numeric()
<?php
// Проверяем значение на число
if( !is_numeric($id) )
{
die("Неверное значение в строке запроса!");
}
// Или же так преобразуем значение
$id = intval($id);
?>
Третий вид атаки, который может быть произведён на сайт — это флуд, часто в автоматической форме.
Злоумышленник может загрузить страницу с формой добавления сообщения к себе на локальный компьютер и добавить несколько сотен сообщений в гостевую книгу или форум. Для предотвращения такого вида атак существует два метода борьбы.
ОСОБОЕ ВНИМАНИЕ
Проверка элемента суперглобального массива $_SERVER['REFERRER'] на предмет содержания в нём адреса исходного сайта, позволяет устранить данный вид атаки
<?php
// $site_addres можете поменять на свое
// но лучше определить его в "общем" файле
if ($_SERVER['HTTP_REFERER'] =! $site_address) die;
?>
Не стоит сильно надеяться на эту защиту, ведь HTTP_REFERER формируется браузером, а значит, может быть подделан. Поэтому когда необходима более надёжная защита необходимо прошить HTML-форму сессией.
<?php
// Инициируем сессию
session_start();
?>
<form action=handler.php method=post>
Имя : <input type=text name=name>
Пароль : <iput type=password name=pass>
<input type=submit name=send value=Отправить>
<input type=hidden name=session_id value=<?php echo session_id();?>>
</form>
Как видно HTML-форма содержит дополнительное поле с именем session_id. После того как пользователь нажимает на кнопку "Отправить" данные отправляются обработчику:
<?php
// Инициируем сессию
session_start();
// Сравниваем переданный идентификатор из формы с
// текущим идентификатором сессии
if($_POST['session_id'] != session_id())
{
exit("Попытка передачи данных с другого хоста. Скрипт остановлен.");
}
// Дальнейшая обработка данных...
?>
В котором значение поля session_id проверяется с текущим идентификатором сессии
Теперь несколько рекомендаций по защите сайта.
1. Не используйте проверку на возращение строки (mysql_num_rows()), а применяйте следующий подход:
<?php
$user = $_POST['user'];
$pass = $_POST['pass'];
$sql = "SELECT user, pass FROM users WHERE user = '$user'";
list($m_user, $m_pass) = mysql_fetch_row( mysql_query($sql) );
if ( $pass != $m_pass or // даст TRUE, если пароли не равны
$user != $m_user // данная проверка даст TRUE, если была sql инъекция
)
{
die("die");
}
?>
2. Не используйте на прямую foreach() для массивов переменных переданных от пользователя
<?php
foreach ($user as $k => $v)
{
$sql = "UPDATE users SET $k = $v WHERE user ='$user['name']'";
mysql_query($sql);
}
?>
Злоумышленник может подправить код и добавить еще один параметр к массиву.
Как альтернативу можно предложить следующий код:
<?php
$users_vars = array('Date' => 'Date', 'City' => 'City', 'ZIP' => 'ZIP');
foreach ($user as $k => $v)
{
if( isset($_POST[$users_vars[$k]]) )
{
$sql = "UPDATE users SET $k = $v WHERE user ='$user['name']'";
mysql_query($sql);
}
}
?>
3. Там где не требуется ввод большого объёма данных ограничивайте число вводимых в HTML-форму символов, за это несёт ответственность параметр maxlength тега input. Например, в следующем текстовом поле ввести можно не более 32 символов:
<input name="user" maxlength="32" value="">
Можно организовать проверку и непосредственно в скрипте
<?php
// Не будим доверять пользователю, ведь подправить значение maxlength
// можно и на локальной машине
substr($_POST['user'], 0, 32);
?>
И напоследок несколько блиц-советов:
• лучше использовать "белый" список чем "черный" (Лучше разрешать только нужное, чем запрещать ненужное)
• помните, что картинка может на самом деле оказать скриптом!
• когда дело доходит до взлома, злоумышленник проявляет всю изобретательность, заложенную в него природой, в тоже время, когда дело доходит защиты, программист же демонстрирует верх скудоумия и однообразности, так как ему чисто психологически не хочется ломать собственное творение. Для тестирования своего сайта приглашайте сторонних людей.
• если код Web-приложения неизвестен злоумышленнику, его гораздо сложнее ломать. Не ленитесь – напишите собственное Web-приложение, на своём уникальном движке – не используйте готовые широкоизвестные Web-приложения. В тоже время постарайтесь не выводить полный отчёт при возникновении ошибки по которому легко восстановить логику Web-приложения.
Вот теперь, пожалуй, и все. Конечно, затронуты далеко не все вопросы создания безопасного кода на PHP и не так подробоно, как хотелось бы... но мы надемся продолжить рассмотрение данного вопроса в следующих статьях.
Спустя 2 часа, 25 минут, 35 секунд (16.03.2010 - 09:11) phz написал(а):
Уважаемый Игорь_Vasinsky, что это за инфу выложили?
Написали:
Вот теперь, пожалуй, и все. Конечно, затронуты далеко не все вопросы создания безопасного кода на PHP и не так подробоно, как хотелось бы... но мы надемся продолжить рассмотрение данного вопроса в следующих статьях.
Как писал Twin, скрипт должен быть:
Требования
1. В имени могут присутствовать абсолютно любые символы, включая пробел. Исключением является только пробел в чистом виде, без других символов.
2. Имя должно выводиться в браузер без искажений.
3. Скрипт не должен зависеть от настройки magic_quotes.
Безопасность
1. Скрипт должен быть защищен от SQL-инъекций
2. Должна быть защита от F5
3. Страница должна быть защищена от XSS атак.
Что это за кусок индусcкого кода?
Может лучше:
А вот это фильтрация данных при входе, к чему она?
Может лучше один раз на выходе?
Пройдите задание http://phpforum.ru/index.php?showtopic=19168
Что-то я со многим не согласен... хм
Написали:
Вот теперь, пожалуй, и все. Конечно, затронуты далеко не все вопросы создания безопасного кода на PHP и не так подробоно, как хотелось бы... но мы надемся продолжить рассмотрение данного вопроса в следующих статьях.
Как писал Twin, скрипт должен быть:
Требования
1. В имени могут присутствовать абсолютно любые символы, включая пробел. Исключением является только пробел в чистом виде, без других символов.
2. Имя должно выводиться в браузер без искажений.
3. Скрипт не должен зависеть от настройки magic_quotes.
Безопасность
1. Скрипт должен быть защищен от SQL-инъекций
2. Должна быть защита от F5
3. Страница должна быть защищена от XSS атак.
Что это за кусок индусcкого кода?
<?php
// Устанавливаем соединение с базой данных
include "config.php";
// Осуществляем соответствия имени паролю
$query = "SELECT * FROM users
WHERE name = '$_POST[name]' AND
pass = '$_POST[pass]'";
$usr = mysql_query($query);
if(!$usr) exit("Ошибка в SQL-запросе");
if(mysql_num_rows($usr)>0)
{
// Вход в защищённую область сайта
}
?>
Может лучше:
<?php
// Устанавливаем соединение с базой данных
include "config.php";
// Осуществляем соответствия имени паролю
$query = mysql_query("SELECT `name`,`pass` FROM `users` WHERE
`name` = '".mysql_real_escape_string($_POST['name'])."' AND
`pass` = '".md5($_POST['pass'])."'")
or die(mysql_error() ."<br/>". $query);
if(mysql_num_rows($query) > 0)
{
// Вход в защищённую область сайта
}
?>
А вот это фильтрация данных при входе, к чему она?
<?php
// добавляем слеши перед кавычками, чтобы они стали виде escape-последовательности,
// например ' замениться на ', " замениться на "
$_POST['name'] = addslashes($_POST['name']);
// заменяем все специальные символы эквивалентом
$_POST['name'] = htmlspecialchars ($_POST['name']);
// отрезаем все ненужные симовлы
$_POST['name'] = preg_replace("/[^a-z0-9]/i", "", $_POST['name']);
?>
Может лучше один раз на выходе?
htmlspecialchars
Пройдите задание http://phpforum.ru/index.php?showtopic=19168
Что-то я со многим не согласен... хм
Спустя 17 минут, 15 секунд (16.03.2010 - 09:28) Что то я ничего не понял написал(а):
Что то я ничего не понял, вы что уже между собой разбираете какие- то варианты, а как же мой вопрос в начале темы, я так и не понял как и что можно сделать чтобы админ часть магазина закрыть паролем только для администратора, подскажите пожалуйста
Спустя 12 минут, 21 секунда (16.03.2010 - 09:40) Nikitian написал(а):
Тут написано
Свернутый текст
В папке, доступ к которой необходимо ограничить, размещаете файл .htaccess, в котором должны быть ниже приведенные строки:
AuthType Basic
AuthName имя
AuthUserFile “/usr/local/www/vhosts/имя.сайта/httpdocs/имя.папки/.htpasswd”
<Limit GET POST>
Require valid-user
</Limit>
где имя - имя Вашего ресурса (может быть любым), которое будет выведено при запросе авторизации, логин - имя Вашей учетной записи (находится в договоре ), имя.сайта - название папки, где хранится Ваш сайт в Вашей домашней папке у нас на сервере, имя.папки - имя защищаемой папки. Далее создаем файл .htpasswd в той же папке, где и .htaccess. В нем нужно разместить логин пользователя, которому Вы разрешаете доступ к сайту (их может быть несколько), а также заши фрованный по алгоритму UNIX Crypt пароль, отделенный от логина двоеточием. Зашифровать пароль можно, например, здесь: https://www.ripe.net/cgi-bin/crypt.cgi. После выполнения этих действий доступ к сайту или его части будет возможен только по логину и паролю.
AuthType Basic
AuthName имя
AuthUserFile “/usr/local/www/vhosts/имя.сайта/httpdocs/имя.папки/.htpasswd”
<Limit GET POST>
Require valid-user
</Limit>
где имя - имя Вашего ресурса (может быть любым), которое будет выведено при запросе авторизации, логин - имя Вашей учетной записи (находится в договоре ), имя.сайта - название папки, где хранится Ваш сайт в Вашей домашней папке у нас на сервере, имя.папки - имя защищаемой папки. Далее создаем файл .htpasswd в той же папке, где и .htaccess. В нем нужно разместить логин пользователя, которому Вы разрешаете доступ к сайту (их может быть несколько), а также заши фрованный по алгоритму UNIX Crypt пароль, отделенный от логина двоеточием. Зашифровать пароль можно, например, здесь: https://www.ripe.net/cgi-bin/crypt.cgi. После выполнения этих действий доступ к сайту или его части будет возможен только по логину и паролю.
Спустя 24 минуты, 46 секунд (16.03.2010 - 10:05) Guest написал(а):
спасибо nikitian за подробное описание, ушёл пробовать
Спустя 6 минут, 58 секунд (16.03.2010 - 10:12) Игорь_Vasinsky написал(а):
//Переход на личности потёр. Для этого есть личка //Nikitian
Теперь для Гостя
разместите свою админку в отдельной директории, а дерикторию закройте .htaccess
Что это за файл и как им закрыть дерикторию - посмотрите на поисковиках, т.к. желание содействовать почти пропало.
p.s. А кусок индусского кода показывает наглядно как сверять введённые логин и пароль с теме данными которые храняться в базе....
Теперь для Гостя
разместите свою админку в отдельной директории, а дерикторию закройте .htaccess
Что это за файл и как им закрыть дерикторию - посмотрите на поисковиках, т.к. желание содействовать почти пропало.
p.s. А кусок индусского кода показывает наглядно как сверять введённые логин и пароль с теме данными которые храняться в базе....
Спустя 7 минут, 12 секунд (16.03.2010 - 10:19) phz написал(а):
| Цитата (Что то я ничего не понял @ 16.03.2010 - 06:28) |
| Что то я ничего не понял, вы что уже между собой разбираете какие- то варианты, а как же мой вопрос в начале темы, я так и не понял как и что можно сделать чтобы админ часть магазина закрыть паролем только для администратора, подскажите пожалуйста |
Второй пост ссылка, читали? Там в конце готовый пример есть.
Спустя 2 минуты, 1 секунда (16.03.2010 - 10:21) phz написал(а):
| Цитата (Игорь_Vasinsky @ 16.03.2010 - 07:12) |
| p.s. А кусок индусского кода показывает наглядно как сверять введённые логин и пароль с теме данными которые храняться в базе.... |
Дак некоторые и знать не будут что этот пример не правильный и скопируют для дела...
Спустя 3 минуты, 41 секунда (16.03.2010 - 10:25) Игорь_Vasinsky написал(а):
я отписал ему простейший пример паролирования директории, только забыл что создание логина и пароля с помощью утилиты, которая входит в состав апача - /usr/local/apache/bin/htpasswd)
как это сделать - воспользуйтесь поиском
а по повуду кода для phz
ежу понятно что входящие данные надо обезопасить, вопрос стаял не в этом а в организации доступа
как это сделать - воспользуйтесь поиском
а по повуду кода для phz
ежу понятно что входящие данные надо обезопасить, вопрос стаял не в этом а в организации доступа
Спустя 1 минута, 21 секунда (16.03.2010 - 10:26) попробовал, но есть вопрос написал(а):
Уважаемый Nikitian, сделал как вы сказали, теперь просто страница админ части не открывается, пишет ошибка HTTP 500 , возможно что то я не так написал, и я так и не понял где прописывать логин и если правило для его написания и правила для написания пароля?
вот что я написал в .htaccess
AuthType Basic
Authhttp://p8o8uk8o8an.ru/admin/
AuthUserFile "/usr/local/www/vhosts/http://p8o8u8o8an.ru/admin/httpdocs/admin/.htpasswd"
<Limit GET POST>
Require valid-user
</Limit>
и вот что в .htaccess
login:admin
password:55655
вот что я написал в .htaccess
AuthType Basic
Authhttp://p8o8uk8o8an.ru/admin/
AuthUserFile "/usr/local/www/vhosts/http://p8o8u8o8an.ru/admin/httpdocs/admin/.htpasswd"
<Limit GET POST>
Require valid-user
</Limit>
и вот что в .htaccess
login:admin
password:55655
Спустя 2 минуты, 50 секунд (16.03.2010 - 10:29) Nikitian написал(а):
попробовал, но есть вопрос
Для вас это будет примерно так:
/usr/local/www/vhosts/p8o8uk8o8an.ru/httpdocs/admin/ - этот путь у вас может быть другим. Для того, чтобы узнать его, положите в папку /admin/ скрипт и посмотрите что он выведет:
Для вас это будет примерно так:
AuthType Basic
AuthName admin
AuthUserFile "/usr/local/www/vhosts/p8o8uk8o8an.ru/httpdocs/admin/.htpasswd"
<Limit GET POST>
Require valid-user
</Limit>
/usr/local/www/vhosts/p8o8uk8o8an.ru/httpdocs/admin/ - этот путь у вас может быть другим. Для того, чтобы узнать его, положите в папку /admin/ скрипт и посмотрите что он выведет:
<?php
echo dirname(__FILE__);
Спустя 1 минута, 45 секунд (16.03.2010 - 10:31) Игорь_Vasinsky написал(а):
Спустя 2 часа, 13 минут, 39 секунд (16.03.2010 - 12:44) еще не все решил написал(а):
вообщем прибывая в ожидании ответа от гуру php нашел несколько своих косяков синтаксических и исправил, но сейчас открывается окно запроса для ввода пароля и логина и если один раз ввел неправильно, то следующая авторизация на этой же машине возможна только после перезагрузки компьютера а вот пароль как и логин сгенерить так и не понял. Что делать? Как я буду дальше жить я незнаю.
Спустя 7 минут, 16 секунд (16.03.2010 - 12:52) Игорь_Vasinsky написал(а):
дружище.. своими словами писать некогда по этому вот...читай внимательно
http://akak.ru/recipes/6266-kak-sozdat-fayl-htpasswd
http://akak.ru/recipes/6266-kak-sozdat-fayl-htpasswd
Спустя 25 минут, 23 секунды (16.03.2010 - 13:17) Спсаибо Игорь написал(а):
Подробнейший ответ, огромное спасибо, как раз для тех кто ничего незнает 
вот только вопрос почему после неверного ввода пароля сайт блокируется и не хочет выводить попуп для пароля и приходиться грузить машину
вот только вопрос почему после неверного ввода пароля сайт блокируется и не хочет выводить попуп для пароля и приходиться грузить машину Спустя 1 минута, 31 секунда (16.03.2010 - 13:19) новость написал(а):
Игорь по вашей ссылки есть путь на прогу для создания пароля, но ссылка мервая на депозит, проги нет, где взять прогу и как она называется
Спустя 53 минуты, 31 секунда (16.03.2010 - 14:12) Nikitian написал(а):
Спустя 1 час, 21 минута, 2 секунды (16.03.2010 - 15:33) Игорь_Vasinsky написал(а):
Эта утилита идет в комплекте с апачем допустим у меня она в
E:\WebServis\usr\local\apache\bin
E:\WebServis\usr\local\apache\bin