Закрываем доступ к сайту

[@windoctor]

А зачем такие извращения? Я делаю проще, открываю сайт для нужных IP адресов и всё, никаких ключей и кук.

[@danilissimus]

а если IP динамический?

[@windoctor]

Эм, честно говоря, в большинстве случаев, компании имеют статический IP адрес.
Но если IP динамический, то да, можно и такой вариант применить (:

[@danilissimus]

а кто сказал, что разрабатывают сайты только компании?

[@windoctor]

Возможно это мои иллюзии, но студии разрабатывают сайты именно для компаний и «физики» как правило не обращаются, хотя, возможно я опять заблуждаюсь (:
Суть такова:
Каждому по потребностям.

В моём случае достаточно проверки по IP, в вашем этого не достаточно и ваше решение, как временное, вполне применимо.

[@Artur]

Т.е. узнаете все возможные IP принимающих решения в компании, включая их динамические подключения с ноутбуков, домашние, а возможно и IP их друзей?

[@windoctor]

Нет, мне узнавать незачем, сами расскажут ;)

[@Cougar]

Ну да, присылает манагер/CEO гневное письмо вида «Йапонамать, почему сайт не работает?!?!11адинадин».
А потом посредством просмотра RFC-822 хидеров узнаем айпи отправившего и открываем ему доступ. :)

Это даже автоматизировать можно, и даже несложно :)

[@windoctor]

Хм, как мне известно и проверено на практике, как правило у всех сотрудников в офисе один IP адрес.
Не вижу смысла продолжать дискуссию, всё равно все останутся при своём мнении (:

[@TheTony]

а по моему неплохой вариант, только (Я понимаю. что это не система безопасности, а так, «штора»):
а) надо следить за «доверенной» ссылкой
б) надо чтобы именно эту куку не знали те, кто сайт видеть не должен (вроде того, что разных сайтов-разные куки)

[@deonis]

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

[@Mithgol]

А не проще ли тогда гиперссылку, ведущую на новый сайт (или на обновлённый функционал), никому не давать? Уровень защиты тот же, а возиться меньше.

[@deonis]

«или на обновлённый функционал»

это как? Если на сайт постоянно заходят посетители?

[@itspoma]

.htaccess? Allow \ Deny

з.ы.:
$AdminCookie = 'HOHOHO! I am super hacker!';
А у Вас все админы ханкеры?)

[@deonis]

нет, у нас люди с чувством юмора

[@itspoma]

как по мне, так лучше:

<?php
   $allow = '12.34.56.78';
   if (!substr($_SERVER['REMOTE_ADDR'],0,strlen($allow)) == $allow) {
       // вот это кусок скрипта для пользователей
       require_once 'page_park.html';
       die;
   }
   // а все, что будет дальше происходить - для администраторов
?>

[@deonis]

если вам хочется тратить время на выяснение IP пользователей, которым надо дать доступ к сайту и вписывать их сюда, то не проблема, можно и такой вариант использовать ;)

[@itspoma]

мой способ с ip-адресами такой же оригинальный, как и тс с куками

[@Elvis_the_King]

у вас не индийские корни случаем? =)

[@xadminx]

О родстве славян с индусами

[@smoked]

А если на сайте дофига ссылок, где нужно все тестить, этот «i-want-to-see-this-site», необходимо каждый раз в строку подставлять?

[@deonis]

зачем? в куку сохранился флаг, что вы уже вызывали ключ и его больше не надо вызывать

[@smoked]

это у вас полный кусок кода который проверят или нет?

if ($_COOKIE['AdminCookie'] != $AdminCookie && $_SERVER['QUERY_STRING'] != $SecretKey)
По данному условию должно быть все равно и куки и секреткей, если они не равны, то мы ничего не показываем,
иначе мы пишем в куку переменную и опять проверяем

if ($_SERVER['QUERY_STRING'] == $SecretKey)

и опять тут секреткей который нужен в URL

или я что-то не так понял…

[@deonis]

что-то не так

[@Gero]

ru.wikipedia.org/wiki/.htpasswd

[@itspoma]

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

[@deonis]

чтобы на работающем сайте вместо парковой страницы выскочил запрос на авторизацию?

[@Bonzo]

Я не спец конечно, а простая связка .htaccess + .htpasswd?

[@MiXei4]

Делаю по сути так же, только у меня строку $SecretKey не обязательно вводить на главной странице. example.com/path/?$SecretKey — так тоже работает.
Плюс есть SecretKey2 — строка, при вводе которой кука удаляется, и можно чувствовать себя обычным пользователем — убедиться что сайт реально закрыт.

[@deonis]

"$SecretKey не обязательно вводить на главной странице"

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

[@MiXei4]

Точно.
Мне почему то показалось, что в коде вместо QUERY_STRING что-то типа REQUEST_URI. Короче недосмотрел :)

[@unicast]

Этот вариант ещё хорошо применять, когда есть 2 версии сайта.
Первая эксплуатируется, а вторая тестовая — показывать заказчиками новые фичи. Мы долго думали как лучше это сделать, в итоге тоже к куке пришли.

[@IntenT]

в свое время делал подобную ерунду…
только немного по другой схеме.

есть отдельная страница авторизации, которая проверяет введенный логин-пароль.
если пароль и логин верный — ставим куку

на страницах сайта проверяем. если стоит кука — показать то что запросили, если нет — показываем заглушку.

[@Sk1nt]

а сделать ещё одну точку входа (какой-то __index.php) и писать в сессию параметр, потом просто проверять его наличие. Есть — показываем страничку… Нету — - до свидания, сайт на реконструкции… Врядли у кто-то из пользователей будет перебирать имена файлов… Да и смысла нету…

[@bio]

Забыли установить для cookies HttpOnly, хакеры не дремлют :)

[@deonis]

спасибо, единственный дельный совет из всего многообразия постов :)

[@Artur]

Все простое — гениально, а гениальное — просто.

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

[@kerrygun]

жесть какая…

[@Nail13]

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

RewriteCond %{HTTP_COOKIE} !hash276819937ee81772017638837ab49992heef78=true [NC]
RewriteCond %{QUERY_STRING} (i-want-to-see-this-site)
RewriteRule .+ setcookie.php?%1 [L]

RewriteCond %{HTTP_COOKIE} !hash276819937ee81772017638837ab49992heef78=true [NC]
RewriteRule .+ index.html [L]

RewriteRule .+ index.php

[@leonid-lapidus]

довольно простое (в хорошем смысле слова) решение. вполне подойдёт для небольших студий, фрилансеров и т.п.
Мы исповедуем религию, предложенную в RoR: есть продакш система — для конечных пользователей, есть девелопмент система — для разработки, есть тест-система — как раз для того, чтобы показать. Если нужно, то БД просто копируются из продакшн в тест или в девелопмент системы — и все счастливы: сайты никогда не лежат.

[@mshakhan]

Я может что-то не понимаю, но Basic Http Authentication разве не для этого придумали?

[@LifeMedia]

столько кода когда можно просто индексным файлом который открывается первым
по умолчанию оставить index2.php (html, htm).
А вторым в очереди стандартным index.php.
Когда надо что-то потестить загружате index2.php (к примеру) и все будет прекрасно.
Для пользователей сайт временно не будет существовать.

[@zooh]

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