|
|
|
|
Анимация
JavaScript
|
Главная Библионтека пропуская первые 5 символов (часть "name=") - получим как раз текст пользователя strcpy(Buf, Query + 5); Пользователь ввел имя - значит, нужно установить Cookie printf("Set-cookie: cook=%s; " "expires=Friday,31-Dec-01 23:59:59 GMT", Buf); Теперь это - новое значение Cookie Cook=Buf; в1водим страницу с формой printf("Content-type: text/html\n\n"); printf("<html><body>\n"); если имя задано (не пустая строка), приветствие if(strcmp(Cook, "")) printf("<h1>Привет, %s!</h1>\n",Cook); продолжаем printf("<form action=/cgi-bin/script.cgi method=get>\n"); printf("Ваше имя: printf("<input type=text name=name value=%s>\n",Cook); printf("<input type=submit value=Отправить>\n"); printf("</form>\n"); printf("</body></html>"); Теперь при первом заходе на этот URL пользователь получит форму с пустым полем для ввода имени. Если он что-то туда напечатает и нажмет кнопку отправки, его информация запомнится браузером. Итак, посетив в любое время до 31 декабря 2001 года этот же URL, он увидит то, что напечатал давным-давно в текстовом поле. И, что самое важное, - его информацию "увидит" также и сценарий. Кстати, у злоумышленника нет никаких шансов получить значение Cookie посетителя, потому что оно хранится у него на компьютере, а не на сервере. И опять я намекаю на то, что использование Си и на этот раз довольно затруднительно. Неудобно URL-декодировать и кодировать при установке Cookies, накладно разбирать их на части, да и вообще наша простая программа получилась слишком длинной. Не правда ли, приятно будет обнаружить, что в PHP все это реализовано автоматически: для работы с Cookies существует всего одна универсальная функция SetCookie() , а получение Cookies от браузера вообще не вызовет никаких проблем, потому что оно ничем не отличается от получения данных формы. Это логично. В самом деле, какая нам разница, какие данные пришли из формы, а какие - из Cookies? С точки зрения сценария - все равно... Но не буду забегать вперед. Займемся пока теорией авторизации. авторизация Часто бывает нужно, чтобы на какой-то URL могли попасть только определенные пользователи. А именно, только те, у которых есть зарегистрированное имя (login) и пароль (password). Механизм авторизации как раз и призван упростить проверку данных таких пользователей. Я не буду здесь рассматривать все возможности этого механизма по трем причинам. Во-первых, существует довольно много типов авторизации, различающихся степенью защищенности передаваемых данных. Во-вторых, при написании обгчных CGI-сценариев для того, чтобы включить механизм авторизации, необходимо провести некоторые манипуляции с настройками (файлами конфигурации) сервера, что, скорее всего, будет затруднительно (ведь обычно компания, которая предоставляет услуги по обслуживанию виртуального хоста, не позволяет вмешиваться в настройки сервера). И наконец, в-третьих, весь механизм авторизации значительно упрощается и унифицируется при использовании PHP, и вам не придется ничего исправлять в этих злополучных настройках сервера. Так что давайте отложим практическое знакомство с авторизацией и займемся ее теорией. Расскажу вкратце о том, как все происходит на нижнем уровне при одном из самых простых типов авторизации - basic-авторизации. Итак, предположим, что сценарий посылает браузеру пользователя следующий заголовок: WWW-Authenticate: Basic realm="имя зонI" HTTP/1.0 401 Unauthorized" Обратите внимание на то, что последний заголовок несколько отличается по форме от обычных заголовков. Так и должно быть. Строка имя зоны в первом из них задает некоторый идентификатор, который будет определять, к каким ресурсам будет разрешен доступ зарегистрированным пользователям. При программировании CGI-сценариев этот параметр используется в основном исключительно для формирования приветствия (подсказки) в диалоговом окне, появляющемся в браузере пользователя (там отображается имя зоны), так что мы не будем вдаваться в детали относительно него. Затем, как обычно, посылается тело документа (сразу отмечу, что именно это тело ответа будет вхдано пользователю, если он нажмет в диалоговом окне (см. ниже) кнопку Cancel, т. е. отменит вход). В этом случае происходит нечто удивительное: в браузере пользователя появляется небольшое диалоговое окно, в котором предлагается вести login и password. После того как пользователь это сделает, управление пере- дается обратно серверу, который среди обычных заголовков запроса (которые посылает браузер) получает примерно такой: Authorization: Basic TG9naW46UGFzcw== Это - ни что иное, как закодированные данные, введенные пользователем. Теоретически, далее этот заголовок должен каким-то образом передаться сценарию (для этого как раз и необходимо добавление команд в файлы конфигурации сервера). Сценарий, декодировав его, может решить: то ли повторить всю процедуру сначала (если имя или пароль неправильные), или же начать работать с сообщением "OK, все в порядке, вы - зарегистрированный пользователь". Предположим, что сценарий подтвердил верность данных и "пропустил" пользователя. В этом случае происходит еще одна вещь: login и password пользователя запоминаются в скрытом Cookie, "живущем" в течение одной сессии работы с браузером. Затем, что бы мы ни делали, заголовок Authorization: Basic значение Cookie будет присылаться для любого сценария (и даже для любого документа) на нашем сервере. Таким образом, посетителю, зарегистрировавшемуся однажды, нет необходимости каждый раз заново набирать свое имя и пароль в течение текущего сеанса работы с браузером, т. е., пока пользователь его не закроет. И еще: после верной авторизации при вызове любого сценария будет установлена переменная окружения remoteuser, содержащая имя пользователя. Так что в дальнейшем можно ее задействовать для определения того, какой же посетитель зарегистрировался. 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 [ 23 ] 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 |
 |