Monthly Archives: Октябрь 2015

Сессии. Подробное описание работы и объяснение механизма

Введение
Как устроены, и как работают сессии?
Область применения.
Возможные проблемы и их устранение.
Безопасность
Дополнительная информация:
Пример авторизации с помощью сессий
ОПС! Очень Полезные Ссылки:
Comments

Введение
Сессии — это на самом деле очень просто.
Надо только понимать, для чего они нужны и как устроены.
Ответим сначала на первый вопрос.
Как показано в соответствующем разделе этого FAQ, веб-сервер не поддерживает постоянного соединения с клиентом, и каждый запрос обрабатывается, как новый, безо всякой связи с предыдущими.
То есть, нельзя ни отследить запросы от одного и того же посетителя, ни сохранить для него переменные между просмотрами отдельных страниц. Вот для решения этих двух задач и были изобретены сессии.
Собственно, сессии, если в двух словах — это механизм, позволяющий однозначно идентифицировать браузер и создающий для этого браузера файл на сервере, в котором хранятся переменные сеанса.

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

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

Как устроены, и как работают сессии?
Для начала надо как-то идентифицировать браузер. Для этого надо выдать ему уникальный идентификатор и попросить передавать его с каждым запросом. Стыдно признаться, но когда я впервые узнал о сессиях, я думал, что это какой-то особый механизм, некий новый способ общения браузера с сервером — «сессии». Что идентификатор сессии передается каким-то особым образом. Разочарование было жестоким.
Сессии используют стандартные, хорошо известные способы передачи данных. Собственно, других-то просто и нет.
Идентификатор — это обычная переменная. По умолчанию ее имя — PHPSESSID.
Задача PHP отправить ее браузеру, чтобы тот вернул ее со следующим запросом. Из уже упоминавшегося раздела FAQ ясно, что переменную можно передать только двумя способами: в куках или POST/GET запросом.
PHP использует оба варианта.
За это отвечают две настройки в php.ini:
session.use_cookies — если равно 1, то PHP передает идентификатор в куках, если 0 — то нет.
session.use_trans_sid если равно 1, то PHP передает его, добавляя к URL и формам, если 0 — то нет.
Менять эти и другие параметры сессий можно так же, как и другие настройки PHP — в файле php.ini, а так же с помощью команды ini_set() или в файлах настройки веб-сервера

Если включена только первая, то при старте сессии (при каждом вызове session_start()) клиенту устанавливается кука. Браузер исправно при каждом следующем запросе эту куку возвращает и PHP имеет идентификатор сессии. Проблемы начинаются, если браузер куки не возвращает. В этом случае, не получая куки с идентификатором, PHP будет все время стартовать новую сессию, и механизм работать не будет.

Если включена только вторая, то кука не выставляется. А происходит то, ради чего, в основном, собственно, и стоит использовать встроенный механизм сессий. После того, как скрипт выполняет свою работу, и страница полностью сформирована, PHP просматривает ее всю и дописывает к каждой ссылке и к каждой форме передачу идентификатора сессии. Это выглядит примерно так:
<a href="/index.php">Index</a> превращается в
<a href="/index.php?PHPSESSID=9ebca8bd62c830d3e79272b4f585ff8f">Index</a>
а к формам добавляется скрытое поле
<input type="hidden" name="PHPSESSID" value="00196c1c1a02e4c37ac04f921f4a5eec" />
И браузер при клике на любую ссылку, или при нажатии на кнопку в форме, пошлет в запросе нужную нам переменную — идентификатор сессии!
По очевидным причинам идентификатор добавляется только к относительным ссылкам.

Теоретически, в наших с вами самодельных сессиях на куках и базе, можно самому, руками приписать ко всем ссылками передачу ид — и тогда наши собственные сессии будут работать независимо от кук. Но, согласитесь — приятнее, когда эту работу делает кто-то другой? 😉

По умолчанию в последних версиях PHP включены обе опции. Как PHP поступает в этом случае? Кука выставляется всегда. А ссылки автодополняются только если РНР не обнаружил куку с идентификатором сессии. Когда пользователь в првый раз за этот сеанс заходит на сайт, ему ставится кука, и дополняются ссылки. При следующем запросе, если куки поддерживаются, PHP видит куку и перестает дополнять ссылки. Если куки не работают, то PHP продолжает исправно добавлять ид к ссылкам, и сессия не теряется.
Пользователи, у которых работают куки, увидят длинную ссылку с ид только один раз.

Фух. С передачей идентификатора закончили.
Теперь осталось привязать к нему файл с данными на стороне сервера.
PHP это сделает за нас. Достаточно просто написать

И PHP запишет в файл, связанный с этой сессией, переменную test.
Здесь очень важное замечание.
Массив $_SESSION — особенный.
В нем, собственно, и находятся переменные, которые мы ходим сделать доступными в различных скриптах.
Чтобы поместить переменную в сессию, достаточно присвоить ее элементу массива $_SESSION.
Чтобы получить ее значение — достаточно обратиться к тому же элементу. Пример будет чуть ниже.

Cборкой мусора — удалением устаревших файлов PHP тоже занимается сам. Как и кодированием данных и кучей всяких других нужных вещей. В результате этой заботы работа с сессиями оказывается очень простой.
Вот мы, собственно, и подошли к примеру работы сессий.
Пример очень маленький:

Мы проверяем, есть ли у нас в сессии переменная counter, если нет, то создаем ее со значением 0, а дальше выводим ее значение и увеличиваем на единицу. Увеличенное значение запишется в сессию, и при следующем вызове скрипта переменная будет иметь значение 1, и так далее.
Все очень просто.

Для того, чтобы иметь доступ к переменным сессии на любых страницах сайта, надо написать ТОЛЬКО ОДНУ(!) строчку в самом начале КАЖДОГО файла, в котором нам нужны сессии:

И далее обращаться к элементам массива $_SESSION. Например, проверка авторизации будет выглядеть примерно так:

Удаление переменных из сессии.
Если у вас register_globals=off, то достаточно написать

Если же нет, то тогда рядом с ней надо написать

Область применения.
Очень важно понимать, для чего сессии стоит использовать, а для чего — нет.

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

Во-вторых. Важно четко себе представлять тот факт, что сессия — это сеанс работы с сайтом, так как его понимает человек. Пришел, поработал, закрыл браузер — сессия завершилась. Как сеанс в кино. Хочешь посмотреть еще один – покупай новый билет. Стартуй новый сеанс. Этому есть и техническое объяснение. Гарантированно механизм сессий работает только именно до закрытия браузера. Ведь у клиента могут не работать куки, а в этом случае, естественно, все дополненные идентификатором ссылки пропадут с его закрытием.
Правда, сессия может пропасть и без закрытия браузера. В силу ограничений, рассмотренных в самом главном разделе этого FAQ, механизм сессий не может определить тот момент, когда пользователь закрыл браузер. Для этого используется таймаут – заранее определенное время, по истечении которого мы считаем, что пользователь ушел с сайта. По умолчанию этот параметр равен 24 минутам.
Если вы хотите сохранять пользовательскую информацию на более длительный срок, то используйте куки и, если надо — базу данных на сервере. В частности, именно так работают все популярные системы авторизации:
— по факту идентификации пользователя стартует сессия и признак авторизованности передается в ней.
— Если надо «запомнить» пользователя, то ему ставится кука, его идентифицирующая.
— При следующем заходе пользователя на сайт, для того, чтобы авторизоваться, он должен либо ввести пароль, либо система сама его опознает по поставленной ранее куке, и стартует сессию. Новую сессию, а не продолжая старую.

В-третьих, не стоит стартовать сессии без разбору, каждому входящему на сайт. Это создаст совершенно лишнюю нагрузку. Не используйте сессии по пустякам – к примеру, в счетчиках. То, что спайлог называет сессиями, считается, конечно же, на основе статистики заходов, а не с помощью механизма сессий, аналогичного пхп-шному.
К тому же, возьмем поисковик, который индексирует ваш сайт. Если поисковый робот не поддерживает куки, то пхп по умолчанию будет поставлять к ссылкам PHPSESSID, что — согласистесь — может не сильно понравится поисковику, который, по слухам, и так-то динамические ссылки не жалует, а тут вообще при каждом заходе — новый адрес!
Если сессии используются для ограничения доступа к закрытому разделу сайта, то все просто поисковик и не должен его индексировать.
Если же приходится показывать одну и ту же страницу как авторизованным, так и не авторизованным пользователям, то тут поможет такой трюк – стартовать сессию только тем, кто ввел пароль, или тем, у кого уже стартовала сессия.
Для этого в начало каждой страницы вместо просто session_start() пишем

таким образом, Мы стартуем сессию только тем, кто прислал идентификатор.
Соответственно, надо еще в первый раз отправить его пользователю – в момент авторизации.
Если имя и проль верные – пишем session_start()!

Возможные проблемы и их устранение.

Самыми распространенными ошибками, которые выдает РНР при попытке работать с сессиями, являются такие:
Две из них,
Warning: Cannot send session cookie - headers already sent
Warning: Cannot send session cache limiter - headers already sent

вызваны одной и той же причиной, решение описано в этом факе здесь
Третья,
Warning: open(/tmp\sess_SID, O_RDWR) failed: No such file or directory (2) in full_script_path on line number (ранее она выглядела, как Warning: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp)),
если перевести ее с английского, подробно объясняет проблему: недоступен указанный в php.ini путь к каталогу, в который пишутся файлы сессий. Эту ошибку исправить проще всего. Просто прописать каталог, который существует, и доступен на запись, например,
session.save_path = c:\windows\temp
И не забыть перезагрузить апач после этого.

Как выясняется, сообразительность людская не имеет пределов, и поэтому я вынужден пояснить:
сообщение о третьей ошибке (невозможно найти каталог) НЕИЗБЕЖНО приведет к появлению первых двух, поскольку сообщение об ошибке — это вывод в браузер и после него заголовками пользоваться нельзя. Поэтому не спешите искать преждевременный вывод, а сначала пропишите правильный путь!

Следующей по распространенности проблемой при работе с сессиями является тяжелое наследие register_globals. НЕ давайте переменным скрипта имена, совпадающие с индексами массива $_SESSION!
При register_globals=on значения будут перезаписывать друг друга, и вы запутаетесь.
А при register_globals=off появится другая ошибка: «Your script possibly relies on a session side-effect which existed until PHP 4.2.3.», в случае, если в скрипте есть переменная сессии не имеющая значения, и глобальная переменная с тем же именем. Чтобы от неё избавиться, надо всегда инициализировать переменные перед использованием (или хотя бы проверять на существование) и не давать глобальным переменным имена, совпадающие с индексами массива $_SESSION.

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

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

Если вы уверены, что ошибок нет, но приведенный пример не работает все равно, то, возможно, в PHP не включена передача ид через урл, а куки по каким-то причинам не работают.
Смотрите, что у вас с куками.
Вообще, если у вас «не работают» сессии, то сначала попробуйте передать идентификатор сессии руками, то есть, сделать ссылку и приписать к ней идентификатор:

При этом следует убедиться, что не включена директива session.use_only_cookies, которая запрещает PHP принимать идентификатор сессии, если он был передан через URL

Если этот пример не заработает, то проблема либо в банальных опечатках (половина «проблем» с сессиями происходит от неправильно написанного имени переменной), либо в слишком старой версии PHP: поддержка сессий появилась в версии 4.0, а массив $_SESSION — в 4.1 (До этого использовался $HTTP_SESSION_VARS).
Если же заработает — то проблема в куках. Отслеживайте — что за куку ставит сервер браузеру, возвращает ли браузер ее. Искать очень полезно, просматривая просматривая обмен HTTP-заголовками между браузером и сервером.
Объяснение принципа работы кук выходит за рамки этого и так уж слишком большого текста, но хотя бы убедитесь, что сервер куку с идентификатором посылает, а браузер — возвращает. И при этом идентификаторы совпадают друг с другом =)
Установка куки должна выглядеть, как
Set-Cookie: PHPSESSID=prlgdfbvlg5fbsbshch6hj0cq6;
или как
Set-Cookie: PHPSESSID=prlgdfbvlg5fbsbshch6hj0cq6; path=/
(если вы запрашиваете скрипт не из корневого каталога)
Ответ сервера должен выглядеть, как
Cookie: PHPSESSID=prlgdfbvlg5fbsbshch6hj0cq6
либо
Cookie: PHPSESSID=prlgdfbvlg5fbsbshch6hj0cq6; b=b
если браузер возвращает другие куки, кроме идентификатора сессии.

Если браузер куки не возвращает — проверьте, работают ли куки вообще.
Убедитесь, что домен, к которому вы обращаетесь, имеет нормальное имя (в котором есть хотя бы одна точка и не содержится запрещенных символов, например подчеркивания) и почистите кэш браузера — это две основные причины, по которм куки могут не работать.

Если пример отсюда работает, а ваш собственный код — нет, то проблема, очевидно, не в сессиях, а в алгоритме. Ищите, где потеряли переменную, по шагам переносите пример отсюда, отлаживайте свой скрипт.

Еще одна проблема может возникнуть, если вы используете перенаправление через header или навигацию с помощью JavaScript.
Дело в том, что РНР автоматически дописывает идентификатор сессии только к ссылкам вида <a href=>, но не делает этого для header-ов, яваскрипта, мета-тегов.
Поэтому надо добавлять идентификатор руками, например, так:

Следует помнить, что пхп лочит файл сессии. То есть, если один ваш скрипт стартует сессию и долго выполняется, а другой пытается в это время стартовать её с тем же идентификатором, то он зависнет. Поэтому в долго выполняющихся скриптах следует стартовать сессию только тогда, когда она нужна, и тут же закрывать её, с помощью session_write_close()

Так же, весьма редкая, и совершенно непонятно, откуда появляющаяся, проблема бывает в том, что настройка session.save_handler имеет значение, отличное от files. Если это не так — исправляйте.

Безопасность
Безопасность сессий — тема обширная. Поэтому остановлюсь на нескольких основных моментах.
Самый хрестоматийный — не передавать идентификатор через адресную строку. Об этом написано даже в php.ini, но это ограничивает функциональность сессий. Если вы решите последовать этому совету, то кроме session.use_trans_sid = 0 не забудьте session.use_only_cookies = 1
Желательно привязывать сессию к IP адресу: таким образом, если идентификатор будет украден, то злодей все равно не сможет им воспользоваться в большинстве случаев.
Рекомендуется пользоваться директивой session.save_path, с помощью которой задать собственный каталог для сохранения файлов сессий. Это более безопасно, чем когда они хранятся в общем временном каталоге сервера по умолчанию.

Дополнительная информация:

  • Кроме кук, механизм сессий посылает еще и заголовки, запрещающие кэширование страниц (тот самый cache limiter). Для html это правильно и необходимо. Но вот когда вы пытаетесь скриптом, проверяющим авторизацию, отдать файл, то интернет эксплорер отказывается его скачивать. Именно из-за этого заголовка. Вызов

 

  • перед стартом сессии должен решить проблему.
  • Как это ни кажется странным, но в массиве $_SESSION нельзя использовать числовые индексы — $_SESSION[1], $_SESSION['10'] — cессии работать не будут.
  • Где-то между версиями 4.2 и 5.0 невозможно было установить session.use_trans_sid с помощью ini_set(). Начиная с 5.0 уже можно снова.
  • До версии 4.3.3 куку PHP отправлял куку только если при старте сессии в запросе отсутстввал идентификатор. Теперь же кука посылается при каждом вызове session_start()

Пример авторизации с помощью сессий
Проиллюстрируем все вышенаписанное небольшим примером:
создадим файл auth.php:

теперь достаточно написать во всех защищаемых скриптах строчку
require «auth.php»;

ОПС! Очень Полезные Ссылки:
http://www.php.net/manual/ru/ref.session.php — самая последняя и свежая информация о поддержке сессий в PHP в официальной документации, плюс многочисленные комментарии пользователей. Настоятельно рекомендуется к прочтению.
http://phpclub.ru/manrus/f/ref.session.html — ВЕСЬМА устаревший перевод этой главы на русский, из документации в переводе Александра Пирамидина.
http://phpclub.ru/detail/article/sessions
Статья с пафосным названием «Правда о сессиях». Двойственное впечатление оставляет. Вначале автор ОЧЕНЬ доступно рассказывает о механизме сессий, но методы, которые он предлагает к концу статьи — совершенно мутные.

Хрестоматийная статья Дмитрия Бородина с сайта
http://php.spb.ru/ настоятельно НЕ рекомендуется.
Ребята, она страшно устарела. Мало того, что в ней есть фактические неточности, так с сессиями в PHP уже давно просто не работают.
Огромное Диме спасибо за нее, это была первая статья по сессиям на русском языке, я сам по ней учился, но сейчас надо ее отправить на заслуженный отдых.
Так же, устарели к сожалению, и многие другие статьи, лежащие в интернете и не обновлявшиеся годами.

Источник: http://phpfaq.ru/sessions

Разработка и создание сайтов, интернет-магазинов, веб-приложений, порталов, лэндингов, мобильных приложений (Киев)

Ubuntu: установка и настройка связки nginx + apache + php + mysql

В это статье я расскажу как быстро развернуть LAMP сервер на Ubuntu с кеширующим nginx

Для всех команд необходим sudo, потому сразу войдем для удобства в этот режим:

Далее, обновляем данные из репозитариев:

Установка MySQL сервер:

Во время установки нас попросят ввести пароль root для сервера MySQL, вводим 2 раза. Дожидаемся окончания установки.

Установка Apache, nginx, php:

Дожидаемся окончания установки.
Включаем модули rewrite и include в apache2 при помощи утилиты — a2enmod:

Меняем порт в apache2 со стандартного 80 на 8080 (2 строчки):

Создаем новый веб сервер (VirtualHost), создаем файл конфигурации:

И вставляем в него следующий текст:

Далее, создаем папку сайта и запускаем сайт:

Проверяем в браузере — http://domain.com:8080

Конфигурируем nginx:

Приводим конфиг к такому виду:

Далее создаем и правим конфиг нашего сайта:

Вносим в него следующие записи:

Перезапускаем сервисы и проверяем работу:

Источник: http://evolan.org/linux/ubuntu-ustanovka-i-nastrojka-svyazki-nginx-apache-php-mysql/

Разработка и создание сайтов, интернет-магазинов, веб-приложений, порталов, лэндингов, мобильных приложений (Киев)

Сброс пароля локального администратора Windows Server 2008R2 / 2008

Случился такой казус. Как то месяцев восемь назад установил сервер клиенту под управлением Windows Server 2008R2 Foundation. Поставил пароль, записал на всякий случай. И вот недавно потребовалось поднять на этом сервере, сервер терминалов для работы пользователей в «1С:Підприємство». Система все это время отлично шуршала, делался backup баз, ИБП не подводил, и все работало 24\7 как положено. Соответственно сервер залочился и ждал ввода пароля для входа в систему. На ввод моего записанного пароля получил ответ «Неверно указан пользователь или пароль». Соответственно согрешив на раскладку, сменил и ввел пароль на русской раскладке. Эффект такой же. Покопавшись часик, перепробовав все мыслимые и не мыслимые пароли пришел к выводу что пароль и правда, кто то сменил. Войти в систему нужно, а пароля нет. Учетка только «Гость» и из под нее ничего не сделаешь. Попробовал загрузиться со старенького LiveCD который все время с собой таскаю, получил ошибку про не найденный драйвер к RAID контроллеру. Но выход нашелся. Итак, сегодня мы сбросим пароль локального Администратора на Windows Server 2008R2. (Пробовал так же на Windows Server 2008, сбрасывает отлично.) Способ так же подходит для Windows Seven, Vista, и возможно XP. НО! Это не способ сброса пароля Администратора Active Directory. Для тех кто не понял. Пароль администратора домена этим способом не сбросить. Про сброс паролей AD я напишу позднее.

Перед тем как пробовать выполнить рекомендации данной статьи, советую посмотреть другую мою статью про Сброс пароля локального администратора на Windows Server 2008R2, возможно предложенное в ней решение, будет более простым для Вас. Кроме того, описанный на этой странице способ, в некоторых случаях не срабатывает. Причин, к сожалению, я назвать не могу, ибо не знаю.

Для начала нам потребуется небольшой LiveCD который вы можете скачать тут. Размер образа всего 5Мб. Качаем архив, распаковываем и записываем на болванку. И загружаемся с него. И видим следующее:

DropPass1Просто жмем Enter. В большинстве случаев настроек по умолчанию хватает. Следующий экран предложит найденные партиции жёсткого диска. Снова жмем Enter:

DropPass2Если работа вашей ОС на которой вы собираетесь сбросить пароль была завершена не корректно то будет предложено сбросить систему. Вводим Y и жмем Enter. Теперь выбор расположения папки конфигурации. Обычно это «Windows/System32/config». Жмем Enter.

DropPass3Выбор операции которую мы хотим произвести: 1 –Сброс паролей. 2 – Консоль восстановления. q – выход. Вводим 1 и жмем Enter.

DropPass4Выбираем «1» – Редактирование пользователей и паролей. («9» редактор реестра. Будьте аккуратнее, поддерживается не полностью и есть очень большой шанс грохнуть систему.) Ввeли «1» и нажали enter.

DropPass5Итак Вы попали в самое «сердце». Пользователи, имеющие привилегии Администратора помечены меткой Admin. Графа «Lock» указывает, стоит ли пароль на учетной записи. Если пароль пустой будет *BLANK*. Что бы отредактировать пользователя нужно ввести либо имя пользователя, либо его RID. Так как имя пользователя у меня на кириллице я ввожу RID в формате 0x. В моем случае RID Администратора будет 01f4, и я вожу 0x01f4. RID для каждого пользователя указаны в колонке с права:

DropPass6Выбираем действие, которое нужно произвести. «1» – очистка пароля выбранного пользователя. «2» – Редактирование пароля пользователя. «3»– Повысить пользователя до администратора. «4» – Разблокировать заблокированную или отключенную учетную запись. «q» – выход. Жмем 1 и Enter.

DropPass7И если все прошло удачно получим вот такой экран:

DropPass8Осталось дело за малым, сохранить сделанные изменения. Вводим «!» и жмем Enter. На следующем экране вводим «q» и снова Enter. Получим запрос на подтверждение сохранения изменений:

DropPass9Вот и все. Перезагружайте систему удобным для вас способом, например Ctrl + Alt + Delete и входите на свой сервер.

DropPass11

Источник: http://melfis.ru/%D1%81%D0%B1%D1%80%D0%BE%D1%81-%D0%BF%D0%B0%D1%80%D0%BE%D0%BB%D1%8F-%D0%BB%D0%BE%D0%BA%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B3%D0%BE-%D0%B0%D0%B4%D0%BC%D0%B8%D0%BD%D0%B8%D1%81%D1%82%D1%80%D0%B0%D1%82/#comment-5255

Сброс пароля локального Администратора Windows Server 2008 R2 (Еще способ)

Была как то у меня на обслуживании не большая организация, внедрял я там Windows Server 2008 R2, поднял терминальный сервер.
Притеры, пользователи, пароли, все как обычно. Ну, пароль Администратора у меня остался. Через некоторое время,
по не понятным причинам, они взяли системного администратора на полную ставку. Ну причины мне не особо интересны.
Сдал я сервер мальчику заочнику-первокурснику, и спокойненько ушел. Первая мысль была примерно такая: «Ломать тут нечего, сервер терминалов будет крутить, надет все в интернете, почтовый вряд ли тронет.»
Ну и ушел с почти спокойной душой. Прошло пол года, звонят, у нас вот так и так что то не так. (Ну как всегда у пользователей. «У нас что то не так, а что сказать не можем, приходите»). Спросил про мальчика админа, сказали уволили нафиг. Ну думаю бывает.
Собираюсь, приезжаю. Мальчик смог поломать сервер терминалов, саму Windows Server 2008 R2 тоже потрепал не плохо (Контроллер домена на 15 пользователей? Нафига вот? Да еще и не поднятый. Как он вообще эту роль НеДоподнял, не понимаю. :( ), почтовый сервер, и понаставить кучу нелицензионного ПО на клиентские места. (Ну фиг с ней с лицензией, а вот, то что это ПО просто бесполезное…)

Пробую залогинится на остатках сервера, пароль не принимает. Сменил. Ну оно и понятно. Звоню, диктует, не подходит (Мальчик как то ехидно посмивается.). Ну думаю фиг с тобой. Попробовал сбросить пароль способом уже ранее описанным тут.
Сбросил, зашел, требует перезагрузку. Перезагрузжаюсь, пароль не верный. Приехали. Пытаюсь снова сбросить, не сбрасывает. Типа пароль пустой и бла бла бла. Сегодня опишу еще один способ сброса пароля на Windows Server 2008 R2.

В отличии от предыдущей статьи, никакого стороннего ПО использовать не будем. Все что потребуется, пара рук, внимательность при прочтении этой статьи, и установочный диск от Windows Server 2008 R2. (к слову сказать, я всегда такой с собой тоскаю. Вообще в моей аптечке много всего, мало ли что :) )
Итак, вставляем диск в привод и грузимся с него.
С лева, в низу, будет «Ссылка» под названием «Восстановление системы» (англ. «Repair your computer«), вот ее и жмем.

OneВсе параметры оставляем по умолчанию, и ничего не меняем. Жмем «Далее»

TwoВыбираем как средство восстановления «Командная строка»

ThreeДалее все достаточно просто. Вводим несколько не замысловатых команд:

Получим ответ: Перемещено файлов: 1
Вводим:

Получи ответ: Скопировано файлов: 1

Four

Этими командами, мы подменили программу запуска «Специальных возможностей«, командной строкой. Вся соль в том, что на экране входа, «Специальные возможности» запускаются от имени системы. Вот это и будем использовать.

Теперь перезагружаем систему, до экрана входа. Да, того экрана который говорит что пароль не верный.

fiveИ жмем на кнопку «Специальные возможности«, после чего будет запущена командная строка.

sixМожете выполнить команду whoami, что бы удостоверится что на данный момент командная оболочка выполняется от имени системы:

seven1Далее все просто и весьма не замысловато. Теперь осталось просто сменить пароль нужного пользователя простой командой net. Сменим пароль для учетной записи Администратор:

nine Ну в принципе на этом вроде бы и все. Но! Обязательно, снова загрузитесь с диска, как в начале, и верните файлы на свои места. Если все оставить как есть, то в системе останется дыра размером с железнодорожный туннель. Представьте себе, если например инициировать автоматическую загрузку «центра специальных возможностей» (Да, кавычки тут по тому что это уже центр в кавычках :) ) с какими либо параметрами. И все команды исполняются от имени системы. Воспользовавшись этим, можно расширить дыру от масштабов «железнодорожного тоннеля», до космической черной дыры! Так что не откладывайте возвращение файлов на свои места.

Этот способ испытан мной только на системе Windows Server 2008 R2 и только на учетной записи локального администратора. Сбросить пароль администратора домена, так не выйдет.

 

Источник: http://melfis.ru/%D1%81%D0%B1%D1%80%D0%BE%D1%81-%D0%BF%D0%B0%D1%80%D0%BE%D0%BB%D1%8F-%D0%BB%D0%BE%D0%BA%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B3%D0%BE-%D0%B0%D0%B4%D0%BC%D0%B8%D0%BD%D0%B8%D1%81%D1%82%D1%80%D0%B0%D1%82-2/

Регистры сведений в языке «1С:Підприємство» (в примерах)

Регистры сведений

Описание:

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

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

Регистр сведений, фактически, представляет собой массив данных, необходимый, чтобы реализовать функцию, которая может выдать необходимую информацию по определенному набору аргументов. Аргументы функции называются измерениями, а результат функции — ресурсами. В приведенном выше примере регистр «ЦеныКонкурентов» будет содержать измерения «Конкурент» и «Товар», и ресурс «Цена». Ресурсов может быть больше чем один: например, можно хранить оптовую и розничную цены.

Для разворота этой информации во времени используется поле «Период» регистра. Оно не вносится в качестве измерения, а добавляется системой автоматически при создании периодического регистра.

Для периодических регистров сведений система поддерживает такие стандартные операции, как получение наиболее позднего или наиболее раннего значения по определенной комбинации измерений (например, получение последней введенной цены по конкретному товару и конкретному конкуренту), а также получения среза наиболее поздних или ранних значений. Например, могут быть получены все последние введенные цены по различным товарам и конкурентам.

Если регистр не периодический, то поле «Период» для него не создается. В приведенном примере регистр «ЦеныКонкурентов» может быть непериодическим, если мы не хотим хранить историю изменения цен, а хотим иметь только актуальные цены. Тогда функция регистра сможет ответить на вопрос «какая сейчас цена у такого-то конкурента на такой-то товар», но не сможет ответить на вопрос «какая была цена у такого-то конкурента на такой-то товар в начале года».

Из описанных принципов работы регистра сведений вытекает то, что в системе может быть только одна запись с определенным набором и периодом измерений.

Действительно, по одному товару по одному конкуренту может быть только одна цена. Если по какой-либо причине мы можем получить несколько цен и хотим занести эту информацию в базу данных, то нам нужно создать еще одно измерение для хранения того значения, по которому эти цены могут различаться. Например, можно завести измерение «ИсточникИнформации». Тогда можно будет вводить цены конкурентов в разрезе источников.

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

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

Эти два варианта влияют на способ внесения информации, а не на основную логику работы регистра.

Документ, которым вносится запись в регистр сведений, называется регистратором.
Регистры, записываемые независимо, могут свободно редактироваться вручную или средствами встроенного языка. При этом если измерение такого регистра назначено как «ведущее» и значением измерения является ссылка на объект базы данных, то будет считаться, что запись регистра имеет смысл, только пока существует этот объект. Например, если назначить ведущим измерение «Конкурент», то считается, что запись имеет смысл только как информация по данному конкуренту. Соответственно, при удалении конкурента записи по нему будут удалены автоматически.

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

В программных модулях для общих действий над регистром сведений (поиск, выбор и создание записей регистра) служит объект РегистрСведенийМенеджер.<Имя регистра сведений>. Для чтения, записи и удаления отдельных записей регистра сведений, не управляемого регистраторами, служит объект РегистрСведенийМенеджерЗаписи.<Имя регистра сведений>. Для считывания и занесения набора записей в базу данных по определенному условию отбора служит объект РегистрСведенийНаборЗаписей.<Имя регистра сведений>. Для динамического обхода записей регистра служит объект РегистрСведенийВыборка.<Имя регистра сведений>.

Источник: http://helpme1c.ru/registry-svedenij-v-yazyke-1s-8-v-primerax