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

[underpl1g]

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

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

 

[ImPasha]

Да, коннект я предоставил не сильно легкий для новичка, но это всяко лучше чем делать 2 запроса хуй пойми для чего селект вообще всрался там.
Зачем выгребать id и потом удалять если можно просто удалить ? Ответь на вопрос

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

Большинство PHP программистов рекомендуют PDO, он проще и понятнее.

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

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

 

[Livarka]

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

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

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

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

 

[ImPasha]

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

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

 

[SCHWEITZER]

Можно было чуть логически подумать и сделать самому за это время

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]

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

можн и с индексами, думаю ему пока и так хватит