PHP Срок действия php + mysql каk?

underpl1g

Участник
Автор темы
84
8
Как можно сделать срок действия ключа по дате/часам/минутам? То есть, я ввожу ключ(уже есть форма) и выбираю срок его действия, к примеру ключ будет работать о 05.04.2021, как это реализовать? Чтобы юзер потом не смог по нему авторизоваться...

Кто сможет - пишите в телеграмм/пм форума. Дам на чаек)
 

Pakulichev

Software Developer & System Administrator
Друг
1,789
2,130
Да, коннект я предоставил не сильно легкий для новичка, но это всяко лучше чем делать 2 запроса хуй пойми для чего селект вообще всрался там.
Зачем выгребать id и потом удалять если можно просто удалить ? Ответь на вопрос
Я же тебе сказал, что это не лучшее решение - я уже отредактировал свой код. Просто когда я делал привязку себе, я логировал все удаленные записи, для этого мне нужно было получать список тех записей, которые будут удалены - это практично, когда есть необходимость дальнейшего взаимодействия с клиентом. Здесь же SELECT действительно не нужен.
Большинство PHP программистов рекомендуют PDO, он проще и понятнее.
Ни разу такого не слышал, хоть и пишу на PHP с 2016 года. Все знакомые мне разработчики не рекомендуют использовать PDO в небольших проектах, ведь всё можно реализовать куда проще через MySQLi, в котором, кстати, есть вариант применения FP вместо OOP, что часто нравится начинающим разработчикам. Большие проекты - да, там PDO может быть полезен, но лично мне привычнее использовать MySQLi и работать по тем стандартам, к которым я уже привык. Тем более, на производительности это никак не отражается, а в некоторых случаях даже повышает её.

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

Livarka

Известный
155
65
Я же тебе сказал, что это не лучшее решение - я уже отредактировал свой код. Просто когда я делал привязку себе, я логировал все удаленные записи, для этого мне нужно было получать список тех записей, которые будут удалены - это практично, когда есть необходимость дальнейшего взаимодействия с клиентом. Здесь же SELECT действительно не нужен.

Ни разу такого не слышал, хоть и пишу на PHP с 2016 года. Все знакомые мне разработчики не рекомендуют использовать PDO в небольших проектах, ведь всё можно реализовать куда проще через MySQLi, в котором, кстати, есть вариант применения FP вместо OOP, что часто нравится начинающим разработчикам. Большие проекты - да, там PDO может быть полезен, но лично мне привычнее использовать MySQLi и работать по тем стандартам, к которым я уже привык. Тем более, на производительности это никак не отражается, а в некоторых случаях даже повышает её.

К тому же, сильного доверия к PDO у меня нет: один мой знакомый разработчик однажды напоролся на ситуацию, когда в определенный момент PHP скрипт, работающий на основе PDO, не смог подключиться к базе данных по какой-то причине, в следствие чего выдал ошибку, в которой раскрыл аутентификационные данные от базы данных. MySQLi таким точно не занимается, в этом уж я уверен. Кто знает какое ещё чудо PDO подкинет мне завтра.
Один мой знакомый доил корову и это оказался бык, не знаю какое чудо подкинет природа завтра.
Если ты не знал, то драйвер собирает тело запроса и запрос выполняет БАЗА ДАННЫХ, а не пхп скрипт. Но если у тебя пхп скрипт выполняет запрос - соболезную.
По твоему решению этой проблемы не заметно, что занимаешься пхп с 2016 года.
Процедурный стиль это начерта не плюс mysqi а скорее его болячка. Кто будет использовать процедурный стиль в большом проекте как ты сказал ?
в пдо все переменный автоматически экранируются, именуемые параметры для работы с большими запросами и куча других фич.
 
Последнее редактирование:

Pakulichev

Software Developer & System Administrator
Друг
1,789
2,130
1) Хорошо, будем игнорировать тот факт, что расширение может в любой неподходящий момент показать пользователю всю необходимую для авторизации в твоей базе информацию. Думаю, хорошее начало дня у кого-то будет, если такое случится. Да, можно выключить отображение ошибок в браузере, но с каких пор это решает проблему, которая выражена в этой уязвимости?
2) Отлично, докопался до формулировки – поздравляю, ты гений. В следующий раз поведаешь мне, что запросы обрабатывает веб-сервер, а не скрипт?
3) Про решение я тебе уже третий раз пишу, не вижу смысла повторяться ещё раз.
4) У каждого свои предпочтения, это во-первых, проект маленький, а не большой, это во-вторых - я не говорил, что это большой проект.

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

SCHWEITZER

Известный
104
71
Можно было чуть логически подумать и сделать самому за это время
создание таблицы:
CREATE TABLE `mpei`.`keys` ( `id` INT NOT NULL , `pName` VARCHAR(32) NOT NULL , `pKey` VARCHAR(32) NOT NULL , `pDateEnd` TIMESTAMP NOT NULL ) ENGINE = InnoDB;
[/CODE]
А чего без индексов? На id надо бы повесить первичный ключ, на pDateEnd обычный, так мускул будет воркать быстрее, но будет занимать немного больше места
 
  • Нравится
Реакции: Livarka

Livarka

Известный
155
65
А чего без индексов? На id надо бы повесить первичный ключ, на pDateEnd обычный, так мускул будет воркать быстрее, но будет занимать немного больше места
можн и с индексами, думаю ему пока и так хватит