ШАГ №1

Начнем. Предположим, что у нас есть контейнер Div с идентификатором content, в котором будут отображаться полученные данные с сервера. Для выполнения этого действия мы вызовем JavaScript функцию записи параметра ID.

Первое, что нам необходимо сделать, это убедится, что у нас подключена библиотека jQuery, а также создана функция для Ajax запроса.

<script language="javascript" src="/path_to_jquery/jquery.js" ></script> <script language="javascript"> function get_record_id(record_id) { } </script>

ШАГ №2

Далее мы будем использовать jQuery функцию загрузки, в которую мы поместим наш идентификатор content.

function get_record_id(record_id) { $(‘#content’).load() }

ШАГ №3

Функция загрузки принимает три аргумента: HTTP запрос, способ загрузки, а также функция обработки вызова. Выглядит это примерно так:

function get_record_id(record_id) { $(‘#content’).load(/controller/method,p,function(str){ }); }

Давайте немного поговорим об этой функции. CodeIgniter по имени контроллера создает URL адрес, а затем функцию внутри класса контроллера, который будет обрабатывать запрос. Если Ваш сервер не поддерживает mod-rewrite, вам необходимо будет с начала добавить index.php. Значение str внутри функции обратного вызова является результатом работы Ajax запроса. Он имеет очень большой смысл при использовании функции .load, еще этот запрос нам пригодится при использовании других функций jQuery и Ajax, $.post и $.get, которые говорят сами за себя.

ШАГ №4

var p = {}; //экземпляр масива p[record_id] = record_id //присваивает значение record_id переменной.

Вот и все что нам необходимо было сделать. Полная функция выглядит следующим образом:

function get_record_id(record_id) { var p = {}; p[record_id] = record_id $(‘#content’).load(/controller/method,p,function(str){ }); }

ШАГ №5

На стороне CodeIgniter у нас есть контроллер и метод загрузки, который выглядит примерно так:

class Controller { function Controller() { parent::CI; } function method() { } }

Важной частью является функция method(), поскольку она будет содержать часть.

ШАГ №6

Первое, что нам необходимо сделать в CodeIgniter, это получить значение объекта запроса. Это достаточно просто выполнить с помощью $_POST [record_id]. Также Вы можете загрузить копию базы данных, чтобы могли получать записи из нее. Таким образом, загрузите библиотеку базы данных, а затем загрузите конкретную модель. Затем мы хотим отправить идентификатор записи в базу данных, получить итоговые данные, и передать его обратно в функцию.

function method() { $record_id = $_POST[record_id]; //присваивает идентификатор записи $this->load->library(database); //загружает запись базы данных для подключения к базе данных $this->load->model(records); //внутри папки ystem/application/models создаются модели на основе процедуры. $results = $this->records->get_record($record_id); //получаем записи из базы данных }

ШАГ №7

В данный момент нам необходимо перейти к файлу records.php в папке model. Поскольку CodeIgniter использует структуру Модель-Просмотр-Структура, деятельность базы данных, процесс обработки сервера. CodeIgniter это должен делать самостоятельно без Вашей помощи.

Внутри файла records.php необходимо создать метод, который будет называться get_record. Для записи мы будем использовать первичный ключ ID, положим полученные данные в массив и отправим их обратно в контейнер.

function get_record($record_id) { $this->db->where(ID,$record_id); //ишем строку в которой совпадает ID $query = $this->db->get(record_table); //получаем данные, которые присваиваем переменной $query $row = $query->row(); //получаем первую строку в результате. В этом случае только одна строка никогда не будет возвращена. $results[record][$row->ID][name] = $row->name; //создаем мгновенный массив, содержащий возвращенные значения на основе ключа return $results; //отправляем отчет на контроллер }

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

ШАГ №8

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

function method() { $record_id = $_POST[record_id]; //присваивает идентификатор записи $this->load->library(database); //загружает запись базы данных для подключения к базе данных $this->load->model(records); //внутри папки ystem/application/models создаются модели на основе процедуры. $results = $this->records->get_record($record_id); //получаем записи из базы данных $this->load->view(AJAX_record,$results); }

ШАГ №9

Файл AJAX_record.php должен находиться в папке system/application/views. Имейте в виду, что когда Вы передаете массив для просмотра, он будет открыт в папке views. Таким образом, путь к файлу записи в настоявшее время $record, вместо $results[record]. Кроме того, внутри будет стандартная HTML разметка, что-то вроде этого:

< ?php foreach($record as $id=>$value) { ?> Имя, связанное с этим запись:: < ?php print $value[name]; ?> < ?php } ?>

Выходом будет PHP запрос, что загружается в контейнер DIV с идентификатором content. CodeIgniter и jQuery делает данную динамическую загрузку легко с помощью Ajax.

На этом все. Спасибо за внимание.

Даже если вы не попадали в такую ситуацию, будьте осторожны – от этого никто не застрахован. Последнее время хакеры проявляют заметную активность и все больше данных утекают в сеть. В этой статье нам бы хотелось рассказать о самых популярных методах работы хакеров и дать простые советы как не подарить конфиденциальные данные злоумышленникам.

Подхват паролей

Чаще всего пользователи становится жертвами хакеров недоучек. Очередной школьник возомнивший себя гуру компьютерных технологий, находит в сети вашу пару логин/пароль и пробует её использовать на всевозможных популярных веб-сервисах. Происходит это когда настоящие хакеры взламывают определённый сервис и вытягивают все пароли и логины из базы данных ресурса, а после выставляют на всеобщее обозрение, показывая тем самым уязвимость используемого сервиса. Причин почему хакеры так поступают много, но мы сегодня говорим не об этом.

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

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

Чтобы не попасть в такую ситуацию, специалисты рекомендуют отказаться от использования простых/одинаковых паролей для всех учётных записей. Заведите бумажный блокнот и храните пароли там. Тогда у вас значительно повысятся шансы сохранить свою конфиденциальные данные.

Wi-Fi шиффинг

Наверное, каждый из нас хоть раз, да использовала общественную Wi-Fi сеть на телефоне, планшете или ноутбуке. Чаще всего это удобно когда сидишь в кафе или закусочной. Кто-то решил скачать понравившуюся композицию, а кто-то ведёт переписку в социальных сетях.

Опасность тут кроется именно в открытости сети. Дело в том, что передаваемые вами данные по Wi-Fi, вещаются в незащищённом виде – это и приводит к краже. Беспроводной интернет основан на радиоволнах, которые передаются от приёмника к маршрутизатору и если их не шифровать, то существует возможность перехвата данных. Большинством приёмников эти волны игнорируются в силу ненадобности, но если рядом с вами хакер, то он может использовать Wi-Fi-сниффер, который без проблем соберёт незащищённые данные и сможет в будущем их использовать для своих целей. Такой способ атаки, позволяет хакеру узнать посещённые вами страницы, используемые пароли и другие личные данные которые, вы передавали по сети.

Чтобы не попадать в такую ситуацию, мы советуем вам пользоваться услугами VPN. Сегодня предлагается широкий выбор подобного рода услуг, которые позволяют шифровать обрабатываемые данные. Если же для вас это не выход, то просто избегайте незащищённые точек Wi-Fi.

Секретный вопрос

Практически все современные веб-сервисы используют «секретные вопросы» для того чтобы пользователь мог восстановить свой пароль в случае потери данных. На самом деле эта мера предосторожности зачастую становится слабым звеном. Если хакер уже имеет пароль к вашей электронной почте, то он сможет сбросить его в 90% случаев и никакой секретный вопрос не поможет.

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

Брутинг (перебор паролей)

Крупные веб-сервисы и развлекательные сайты стараются обезопасить своих пользователей и устанавливают ограничение на количество попыток ввода данных, заставляют пользователей вводить каптчу (слова/цифры с картинок). Но поступают так далеко не все владельцы ресурсов, а потому хакеры используют специальные программы способные подбирать пароли. Используемые ими скрипты подбирают пароли по самым разнообразным критериям, хотя чаще всего подбор идёт по обычному словарю. То есть, если вы решили выбрать паролем слово «cat» или «password», будьте уверены, что его угадают и довольно быстро.

Мы рекомендуем вам использовать в пароле не только буквенные комбинации, но и цифирные, а также менять регистр набора.

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

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

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

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

Говоря об особенностях апдейта в Яндекс и Google, в первую очередь, подразумевается работа с алгоритмами этих поисковиков. В связи с этим, чтобы не сдать позиции, нужно знать, когда происходит аптейт баз данных этих поисковых систем. Поисковик Яндекс отличается статистической выдачей, т.е. позиции ресурсов в российском гиганте поиска обновляются периодически, как правило, это происходит 1-2 раза в неделю. А вот характеристикой Google является динамика – его база обновляется по нескольку раз в день.

Апдейты бывают следующих видов:

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

- текстовый апдейт – апдейт страниц, содержащих текст. Он самый распространенный и частый среди прочих;

- ссылочный апдейт – подразумевает обновление ссылок, указывающих на данный ресурс;

- апдейт показателей ТИЦ и PR;

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

На самом деле апдейты играют двойственную роль, хотя она и очень важна для оптимизатора. Некоторые их виды позволяют понять процесс ранжирования и продвинуть ресурс на лидирующие позиции по определенным запросам. Но, с другой стороны, остальные виды апдейтов могут затруднить продвижение ресурса. Чаще всего, такими апдейтами становятся изменения поисковых алгоритмов, когда ресурс может опуститься сразу же на несколько позиций, что вынуждает оптимизатора снова анализировать ТОП и изменять сайт.

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

Для примера рассмотрим платформу 8.2, которая может функционировать в четырех различных режимах работы:
— холдинг (информационная база является распределенной);
— крупное предприятие (используется клиент-серверный вариант);
— небольшое предприятие (файловый вариант);
— используется для персональных нужд (файловый вариант).

Опустим пока что режим работы "холдинг", сосредоточившись на менее масштабных вариантах. Итак, почему же 1с sql часто выглядит предпочтительнее файлового режима. Обычно необходимость использования клиент-серверного варианта возникает в том случае увеличения числа сотрудников. Происходит условная "эволюция", когда отживший свое файловый режим работы постепенно уходит в прошлое, отмирая, заменяясь на нечто более совершенное. Самая простая причина отказа от его использования – увеличение "тормозов" в работе при большом растущем количестве пользователей. Подобное недопустимо и может серьезно мешать нормальному процессу функционирования предприятия. Как следствие, резонен переход на клиент-серверный вариант работы, когда вышеуказанная проблема отпадает сама собой. Конечно, придется потратиться на приобретение лицензий, особенно, если планируется использование какой-то платной СУБД. Хотя можно ограничиться и, к примеру, PostgreSQL, которая относится к так называемым OpenSourse продуктам и распространяется совершенно бесплатно.

Касаемо архитектуры клиент-серверного режима работы, то тут все просто. В ней выделяют три составляющие: сервер базы данных, кластер серверов и, собственно, клиентское приложение. При этом вовсе не обязательно, чтобы кластер серверов располагался где-то отдельно от базы данных. Данная архитектура позволяет с легкостью осуществлять администрирование и т.д. При необходимости можно даже задействовать веб-сервер, чтобы вывести удаленную работу на еще более высокий уровень, попутно "разгрузив" ПК пользователей.

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