Наличие даты, как мне кажется, особо не влияет. Использование одной только даты опасно тем, что если у вас есть несколько инсталляций для разных клиентов, то один из них откроет код, посмотрит алгоритм, и спольет данные всех остальных.
У этого подхода одни минусы, и ни одного плюса. Если уж очень хочется, я бы:
- передавал вместе с запросом таймстамп (который включался бы в хеш)
- проверял что таймстамп лежит в заданном +-интервале (решается проблема недоступности в конце часа)
- подписывал секретным ключом (хэшем) все важные данные + таймстамп.
Что значит "хорошо ли это"? У машины есть колеса и она может ездить, хорошо ли это? Ели вам надо ехать, то да, если переплыть море то нет. Сформулируйте критерии, которым должна удовлетворять ваша система и постройте аутификацию на её базе.
Я так понимаю вам нужно:
-передать на сервер запрос
-сервер должен удостовериться, что данные пришли от того от кого надо
-если да, то вернуть данные
-данные надо скрыть от посторонних глаз
Т.е. решить две задачи:
- аутификацию клиента
- защитить от злоумышленника передаваемые данные
Теперь давайте рассматривать ваш метод с датой:
- есть некий секретный алгоритм, без знания которого нельзя получить данные, он и будет ключем аутификации. Для получения данных необходимо знание алгоритма (то что хэш берется от даты). Без знания этого алгоритма данные не получить.
- злоумышленник разгадав (или подсмотрев) алгоритм может невозбранно генерировать новые сообщения и получать данные.
- в случае если рассинхронизация даты составляет 1 минуту, то в конце каждого часа дата в виде год/мес/дата/час будет рассинхронизирована в течении одной минуты и ваше приложение не будет функционировать
Т.е. задача аутификации клиента худо бедно решена (не считая недоступности в конце каждого часа). Эту задачу я бы решил всетаки простым секретным ключом, которые знают клиент и сервер. Т.е. передавать хэш от (данные + ключ). Если ключ стал известен злоумышленнику, его можно просто сменить.
Теперь, что защиты данных. Тут рассмотрим два случая.
Первый - вы доверяете каналу между двумя серверами (т.е. злоумышленник не может читать этот канал и отправлять в него свои сообщения), допустим он зашифрован по SSL - тогда вам не надо делать вообще ничего, защита обеспечена каналом.
Второй - вы не доверяете каналу между двумя серверами (т.е. злоумышленник может читать и отправлять сообщения по этому каналу). Тогда:
- перехватив ваш запрос он может не расшифровывая его посылать его на сервер целый час и невозбранно получать данные. Если хэшируется только дата (т.е. в хэш не входят параметры запроса) то еще и менять параметры
- с другой стороны если он может читать канал связи ему вообще не надо перехватывать ваши запросы, а можно сразу перехватывать ответы
Получается, что в условиях незащищенного канала обеспечить безопасность данных нельзя никак и вам надо использовать шифрованный канал.
Это не помогло?
Параметр действует в рамках сессии (подключения).
2) убедитесь что включена FOREIGN_KEY_CHECKS.
Посмотреть: SELECT @@FOREIGN_KEY_CHECKS;
Включить: SET FOREIGN_KEY_CHECKS = 1;
Выключить: SET FOREIGN_KEY_CHECKS = 0;
Еще вот что:
both tables must be INNODB. The foreign key field must have an index on it. The foeign key field and the field being referenced must be of the same type (I only use integer) and, after hours of pain, they must be UNSIGNED.
"После часов боли, они должны быть UNSIGNED". Т.е. поменяйте INT на UNSIGNED INT
Если в кратце:
1) используйте InnoDb (это вы вроде выполнили)
2) убедитесь что включена FOREIGN_KEY_CHECKS.
Посмотреть: SELECT @@FOREIGN_KEY_CHECKS;
Включить: SET FOREIGN_KEY_CHECKS = 1;
Выключить: SET FOREIGN_KEY_CHECKS = 0;
Параметр действует в рамках сессии (подключения). Вроде можно где-то включить по умолчанию, но это надо доки смотреть.
CONSTRAINT `FK__countrys` FOREIGN KEY (`id_country`) REFERENCES `countrys` (`id`) не должен добавить запись в города, если нет соответствующей страны, равно как и удалить страну, если с ней связаны города.
Автор вроде делает все правильно, но почему-то не работает. Так что-то не могу угадать.
Ну да, тоже вариант, я так делал, не подумал просто. В гугле полно вариантов.
Вот по шагам:
1) останавливаете все ваши существующие веб серверы
2) поднимаете nginx на 80 порту
3) поднимаете ваши веб серверы НЕ на 80 порту (т.е. панель у вас на 8083, а то, что сейчас на 80 перенесите на 8080 например)
4) делаете апстрим для каждого виртуального хоста (т.е. для каждого виртуального хоста на "старом" сервере и на сервере панели)
5) делаете локейшен для каждого виртуального хоста
6) в настройках каждого локейшена заруливаете запрос в соответствующий апстрим
Если вам хочется ланчер, который не тормозит работу, то я бы посоветовал вам просто забить.
1) андроид вырезает из памяти приложения которые ничего не делают
2) ланчеры стараются не делать лишних действий. Т.е. в нове есть доступ к контактам, но она не будет постоянно их читать, если они ей не нужны. Это следует просто из того, что все производители приложений (особенно платных) стараются сделать так, чтобы оно было круче, и жрало поменьше. Тогда его больше народу купит.
3) если вы не хотите чтобы оно что-то отправляло (вы параноик) см прошлый коммент. Урезать конкретным приложениям доступ в интернет можно в очень многих кастомах. Может и приложение какое есть отдельное.
По теме:
урезание permissions приведет автоматически к неработоспособности виджетов. Виджеты это очень важная и нужная штука в андроиде. Поэтому я не думаю, что в природе существует ланчер "для параноиков", с единственным функционалом - запускать приложения.
Если вы параноик (у каждого свои тараканы), то вам лучше воспользоваться кастомной прошивкой, которая позволяет урезать различным приложениям доступ к различному функционалу. Такое точно есть в MiUI и помоему в циане.
Так вы решите проблему не только ланчера, а вообще всего.
Ну в 3) вам придется посадить человека который будет следить за соответствием стороннего каталога(ов) и каталога производителя. Я бы выбрал, на самом деле, вариант 2.
После фразы "..и даже вашему анусу" стало понятно, что градус неадекватности вопроса довольно высок. Если вы хотите получить ответ, то пишите вопрос с максимумом относящихся к делу деталей и минимумом эмоций. Если вы хотите излить душу и пожаловаться на жизнь - идите сюда killmeplz.ru
В php есть специальная функция для этого. parse_bad_videocard_memory_name($string);
А если серьезно вы какое решение хотите? Вам нужно либо
1) посадить человека который будет это все руками вбивать и править
2) посадить человека который будет просматривать магазин и руками писать правила нормализации
3) найти где-то источник данных о товарах с нормализованными данными и каким-то образом сопоставить позиции вашего поставщика с позициями в этом нормализованном каталоге
4) забить и выводить как есть
Рисовать это на чистом css - процесс ради процесса. Если вам ХОЧЕТСЯ это сделать - пожалуйста. Если нужно простое и быстрое решение - вставляйте картинку. И завитушки не потеряются.
Если вам надо склонировать массив простых значений (строка\число), то можно просто arr.slice()