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

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

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

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

    $SecretKey = 'i-want-to-see-this-site';
    $AdminCookie = 'HOHOHO! I am super hacker!';
    if ($_COOKIE['AdminCookie'] != $AdminCookie && $_SERVER['QUERY_STRING'] != $SecretKey) {
        require_once 'page_park.html';
        exit;
    } else {
        setcookie('AdminCookie', $AdminCookie, time()+3600*24*365, '/');
        if ($_SERVER['QUERY_STRING'] == $SecretKey) {
            header('Location: /');
            exit;
        }
    }
    

    Благодаря этому небольшому коду все люди будут попадать на page_park.html, а избранным достаточно зайти по ссылки http://наш_сайт/?i-want-to-see-this-site, чтобы получить полноценный доступ к сайту. И что самое главное, при последующих заходах избранные сразу без проблем будут попадать на работающий сайт, что очень полезно, если сайт настраивается и запускается в течении нескольких дней.

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

    P.S. Как раз сегодня утром настраивали новый сайт на сервере, вот и решил поделиться с общественностью такой незатейливой фишкой.

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 43

      +1
      А зачем такие извращения? Я делаю проще, открываю сайт для нужных IP адресов и всё, никаких ключей и кук.
        0
        а если IP динамический?
          0
          Эм, честно говоря, в большинстве случаев, компании имеют статический IP адрес.
          Но если IP динамический, то да, можно и такой вариант применить (:

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

              В моём случае достаточно проверки по IP, в вашем этого не достаточно и ваше решение, как временное, вполне применимо.
          +2
          Т.е. узнаете все возможные IP принимающих решения в компании, включая их динамические подключения с ноутбуков, домашние, а возможно и IP их друзей?
            –1
            Нет, мне узнавать незачем, сами расскажут ;)
              0
              Ну да, присылает манагер/CEO гневное письмо вида «Йапонамать, почему сайт не работает?!?!11адинадин».
              А потом посредством просмотра RFC-822 хидеров узнаем айпи отправившего и открываем ему доступ. :)

              Это даже автоматизировать можно, и даже несложно :)
                0
                Хм, как мне известно и проверено на практике, как правило у всех сотрудников в офисе один IP адрес.
                Не вижу смысла продолжать дискуссию, всё равно все останутся при своём мнении (:
          0
          а по моему неплохой вариант, только (Я понимаю. что это не система безопасности, а так, «штора»):
          а) надо следить за «доверенной» ссылкой
          б) надо чтобы именно эту куку не знали те, кто сайт видеть не должен (вроде того, что разных сайтов-разные куки)
            0
            Да, это временная «шторка», а ключ и значение куки специально вынесены в переменные, чтобы их можно было менять от обновления к обновлению и от проекта к проекту.
            –1
            А не проще ли тогда гиперссылку, ведущую на новый сайт (или на обновлённый функционал), никому не давать? Уровень защиты тот же, а возиться меньше.
              +1
              «или на обновлённый функционал»

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

              0
              .htaccess? Allow \ Deny

              з.ы.:
              $AdminCookie = 'HOHOHO! I am super hacker!';
              А у Вас все админы ханкеры?)
                0
                нет, у нас люди с чувством юмора
                  –7
                  как по мне, так лучше:

                  <?php
                     $allow = '12.34.56.78';
                     if (!substr($_SERVER['REMOTE_ADDR'],0,strlen($allow)) == $allow) {
                         // вот это кусок скрипта для пользователей
                         require_once 'page_park.html';
                         die;
                     }
                     // а все, что будет дальше происходить - для администраторов
                  ?>
                    +1
                    если вам хочется тратить время на выяснение IP пользователей, которым надо дать доступ к сайту и вписывать их сюда, то не проблема, можно и такой вариант использовать ;)
                      0
                      мой способ с ip-адресами такой же оригинальный, как и тс с куками
                      +12
                      у вас не индийские корни случаем? =)
                  0
                  А если на сайте дофига ссылок, где нужно все тестить, этот «i-want-to-see-this-site», необходимо каждый раз в строку подставлять?
                    0
                    зачем? в куку сохранился флаг, что вы уже вызывали ключ и его больше не надо вызывать
                      –1
                      это у вас полный кусок кода который проверят или нет?

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

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

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

                      или я что-то не так понял…
                        –3
                        что-то не так
                    0
                      0
                      .htpasswd не подходит,
                      т.к. в конкретном случае надо скрыть главную страницу,
                      и админам показывать одну, а пользователям другую.
                      а htpasswd ограничивает доступ для всех
                        0
                        чтобы на работающем сайте вместо парковой страницы выскочил запрос на авторизацию?
                        0
                        Я не спец конечно, а простая связка .htaccess + .htpasswd?
                          +1
                          Делаю по сути так же, только у меня строку $SecretKey не обязательно вводить на главной странице. example.com/path/?$SecretKey — так тоже работает.
                          Плюс есть SecretKey2 — строка, при вводе которой кука удаляется, и можно чувствовать себя обычным пользователем — убедиться что сайт реально закрыт.
                            0
                            "$SecretKey не обязательно вводить на главной странице"

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

                              0
                              Точно.
                              Мне почему то показалось, что в коде вместо QUERY_STRING что-то типа REQUEST_URI. Короче недосмотрел :)
                            +1
                            Этот вариант ещё хорошо применять, когда есть 2 версии сайта.
                            Первая эксплуатируется, а вторая тестовая — показывать заказчиками новые фичи. Мы долго думали как лучше это сделать, в итоге тоже к куке пришли.
                              0
                              в свое время делал подобную ерунду…
                              только немного по другой схеме.

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

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

                                    Хороший толковый пример и решение для описанной ситуации. Комментарии жаль удивили. Похоже комментировали либо те, кто слабо отрезает или просто по-жизни любит поспорить :)
                                      0
                                      жесть какая…
                                        +3
                                        Буквально недавно озадачился такой же проблемой, и (о чудо!) пришел точь-в-точь к такому же решению.
                                        Мое отличие заключается в том, что я вынес код проверки секретного урла, куков и перенаправления в .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
                                          +2
                                          довольно простое (в хорошем смысле слова) решение. вполне подойдёт для небольших студий, фрилансеров и т.п.
                                          Мы исповедуем религию, предложенную в RoR: есть продакш система — для конечных пользователей, есть девелопмент система — для разработки, есть тест-система — как раз для того, чтобы показать. Если нужно, то БД просто копируются из продакшн в тест или в девелопмент системы — и все счастливы: сайты никогда не лежат.
                                            0
                                            Я может что-то не понимаю, но Basic Http Authentication разве не для этого придумали?
                                              0
                                              столько кода когда можно просто индексным файлом который открывается первым
                                              по умолчанию оставить index2.php (html, htm).
                                              А вторым в очереди стандартным index.php.
                                              Когда надо что-то потестить загружате index2.php (к примеру) и все будет прекрасно.
                                              Для пользователей сайт временно не будет существовать.
                                                0
                                                Я обычно отладку такого рода вывожу на поддомен или в подпапку, и то и другое прекрасно паролится через .htaccess. Но способ имеет право на жизнь, безусловно.

                                                Only users with full accounts can post comments. Log in, please.