|
Сообщение от AciDWarrioR
|
|
Насчет безопасности, в принципе пока инфа не столько уж закрытая. Все эти снимки спутников доступны бесплатны, так что боятся какой то утечки мне пока не надо
|
Об этой безопасности пусть голова болит у ФБР и ФСБ.
Ваша задача думать о безопасности своего веб приложения, баз данных в том числе. PostgreSQL не исключение из этих правил, а PDO, это абстракция и для работы с PostgreSQL нужно подключить соответствующий PDO драйвер.
|
Сообщение от AciDWarrioR
|
|
Ч/з Ajax, что я делал, был одностраничный сайт с картами пожаров, то там все было понятно. Но здесь я все же решил перейти к другой страницы потому что нужно ещё реализовать просмотров QuickLookов для пользователей.
|
А это к чему тогда?
<script>
var tab = document.getElementsByClassName("table1");
var newRow = document.createElement("tr");
newRow.classList.add("row");
....
К тому же у вас не JS занимается построением таблицы, а фактически РНР, формируя в цикле клиентский код добавляющий в таблицу одну строку. И так методично по всем строкам результата запроса. Такого безобразия быть не должно.
Коли на клиента возложен вывод таблицы, так отдавайте ему ее данные все, из которых крохотный JS сценарий ее построит. А если это не подходит, значит while($row=pg_fetch_
assoc($result)) и вывод строк html кода....
И если JS, то все таки json, о отдавать клиенту выгоднее в вашем случае не ассоциативный массив, а индексный, то есть только значения полей, главное соблюсти в запросе к базе условие - запрос должен возвращать поля в той последовательности, в которой они идут в html-таблице (ее колонки). На PDO возврат клиенту данных, это будет всего одна строка кода:
echo json_encode($sth->execute()->fetchAll(PDO::FETCH_NUM)); //вывести все строки запроса в json формате
Клиент в этом случае после декодирования json получит данные в виде массива массивов. С учетом того, что таблица имеет строку заголовков, которая постоянна, а изменять нужно только следующие за ней строки, можно поместить строку заголовков и строки данных в разные TBODY, второй из них очищать и помещая в него новые данные, что-то типа такого:
<!DOCTYPE HTML>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<style>
</style>
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js"></script>
<script>
$(function() {
//к примеру это пусть ответ сервера с данными запроса после декодирования json
var obj = [[1,2,3,4],[5,6,7,8],[9,10,11,12]];
//это обновление таблицы новыми этими данными
var tb = $('#list tbody:last').empty(), a;
for(;a = obj.pop();) tb.prepend('<tr><td>'+a.join('</td><td>')+'</td></tr>');
});
</script>
</head>
<body>
<table id="list">
<tbody>
<tr><td>head</td><td>head</td><td>head</td><td>head</td></tr>
</tbody>
<tbody></tbody>
</table>
</body>
</html>
|
Сообщение от AciDWarrioR
|
|
а городить большие проверки if, что отправил пользователь я не стал
|
У вас как раз их больше чем нужно. $post = array_diff(array_map('trim', $_POST), ['']) - удаляет крайние пробелы во всех значениях полученных данных и удаляет после этой операции из массива элементы с пустыми значениями. А условие проверяет пуст ли массив $post после данных операций. Вот здесь нужно либо отказывать в поиске, либо выводить что-то по умолчанию, тем более что есть условия, типа:
if($_POST[dateAt]=='') $_POST[dateAt]='1950-01-01'; //фигурные скобки здесь лишние
В данном случае также можно обойтись без методичных if()..., лучше воспользоваться пересечением массивов, первый из которых это значения по умолчанию, а второй массив $post, пример:
$def = ['dateAt'=>'1950-01-01', 'dateTo'=>'2100-12-31', 'timeAt'=>'00:00', 'timeTo'=>'23:59']; //значения по умолчанию
$post = ['dateAt'=>'1980-03-01', 'dateTo'=>'2100-12-31']; //пришедшие значения
$post = array_replace($def, $post); //отсутствующие поля в запросе клиента будут заменены значениями по умолчанию, этот массив и нужно использовать в запросе
Правда у вас даты какие-то запредельные, а ведь данные желательно проверять на сервере, например
для чисел это не проблема, правда и для дат можно использовать фильтр FILTER_VALIDATE_REGEXP. Но корректность даты можно проверить и проще - strtotime вернет метку времени из строкового значения даты, если дата будет введена корректно, даже в случае ввода ее в русскоязычной локали дд.мм.гггг. Правда при этом дата должна быть в диапазоне от начала эпохи Unix до макс. возможной для разрядности РНР (32/64 бит). И может подумать с календарем для полей даты, чтобы не мудрить отдельно с временем и датой затем соединяя их на сервере?
И не именовать поля формы также как соответствующие им поля в базе. Не стоит светить структуру базы, и совсем не стоит вываливать клиенту ее ошибки pg_last_error(). Пользователю они ничего полезного не несут, он не поймет это, да это ему и не нужно, а тем кто намеренно вас будет атаковать, это богатая пища для размышлений. Именуйте поля формы как name, а в базе это же имя используйте с префиксом, и не по принципу 1234, это надежный пароль. Уже не помню какая именно, но одна из известных CMS была взломана как раз в частности потому, что к префиксам отнеслись как "абы было что-то".
|
Сообщение от AciDWarrioR
|
|
В данный момент, одному спутнику соответствует один прибор и чтобы пользователь заранее не ввел противоречущие друг друг позиции реализовано запреты.
|
Может тогда лучше использовать связанные списки? К тому же как определить disabled/enabled, если пользователь может ввести любой спутник?
С расширением PostGIS работать не приходилось, поэтому по данному вопросу ничего сказать не могу, но вот для
"просмотров QuickLookов для пользователей. То есть, ему нравятся какая-то запись, он ткнул, открылась карта с наложенным на неё слоем jpg картинки снимка" Ajax не может быть проблемой, я так думаю.