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

[underpl1g]

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

Кто сможет - пишите в телеграмм (https://www.blast.hk/redirect/aHR0cDovL3RnOi8vcmVzb2x2ZT9kb21haW49dXNlcmRlbGV0ZW R6)/пм форума. Дам на чаек)

[Hatrig]

Делаешь таблицу, например:

id | key | create_at | end_at

Дальше с формы отправляешь данные на функцию, которая заносит значения в базу данных, где ID - автоинкремент, key - твой ключ с формы, create_at - значение из php функции date() с типом timestamp, end_at - время из формы, которое ты указываешь вместе с ключем.

Там, где происходит авторизация, сверяешь текущее время и end_at из таблицы, если текущее больше - пишешь срок действия истек. Всё.

[underpl1g]

Делаешь таблицу, например:

id | key | create_at | end_at

Дальше с формы отправляешь данные на функцию, которая заносит значения в базу данных, где ID - автоинкремент, key - твой ключ с формы, create_at - значение из php функции date() с типом timestamp, end_at - время из формы, которое ты указываешь вместе с ключем.

Там, где происходит авторизация, сверяешь текущее время и end_at из таблицы, если текущее больше - пишешь срок действия истек. Всё.


Кодом бы))

[underpl1g]

Ап

[Livarka]

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

создание таблицы:






CREATE
TABLE
`
mpei
`
.
`
keys
`
(
`
id
`
INT
NOT
NULL
,
`
pName
`
VARCHAR
(
32
)
NOT
NULL
,
`
pKey
`
VARCHAR
(
32
)
NOT
NULL
,
`
pDateEnd
`
TIMESTAMP
NOT
NULL
)
ENGINE
=
InnoDB
;




pName ник или че хош вводи туда

pKey - сам ключ длинной 32 символа

pDateEnd время в Unix формате ( почитай че это)

DELETE WITH PDO:






function
connect
(
)
{
// коннект к твоей бд
$host
=
'127.0.0.1'
;
$db
=
'test'
;
$user
=
'root'
;
$pass
=
''
;
$port
=
"3306"
;
$charset
=
'utf8mb4'
;
$options
=
[
\
PDO
:
:
ATTR_ERRMODE
=
>
\
PDO
:
:
ERRMODE_EXCEPTION
,
\
PDO
:
:
ATTR_DEFAULT_FETCH_MODE
=
>
\
PDO
:
:
FETCH_ASSOC
,
\
PDO
:
:
ATTR_EMULATE_PREPARES
=
>
false
,
]
;
$dsn
=
"mysql:host=$host;dbname=$db;charset=$charset;port= $port"
;
try
{
return
new
\PDO
(
$dsn
,
$user
,
$pass
,
$options
)
;
}
catch
(
\
PDOException
$e
)
{
throw
new
\PDOException
(
$e
-
>
getMessage
(
)
,
(
int
)
$e
-
>
getCode
(
)
)
;
}
}
function
deleteOldKeys
(
)
{
$unixTimeNow
=
time
(
)
;
try
{
$con
=
$this
-
>
connect
(
)
;
$sql
=
"DELETE FROM keys WHERE pDateEnd
prepare
(
$sql
)
;
$stmt
-
>
execute
(
[
$unixTimeNow
]
)
;
}
catch
(
Exception
$e
)
{
echo
$e
-
>
getMessage
(
)
;
}
}
deleteOldKeys
(
)
;
// ставишь в крон проверку каждую минуту и все




хз мог ошибиться где то, писал прям тут. А еще id надо AUTO INCREMENT присвоить - дерзай

[Quasper]

Самый легкий способ как по мне, поставить cron на выполнение скрипта каждые сутки который будет открывать базу, брать поле с сроком действия и вычитать единицу Вот (https://www.blast.hk/redirect/aHR0cHM6Ly9jcm9uLWpvYi5vcmc) бесплатный крон сервис

[Livarka]

Самый легкий способ как по мне, поставить cron на выполнение скрипта каждые сутки который будет открывать базу, брать поле с сроком действия и вычитать единицу Вот (https://www.blast.hk/redirect/aHR0cHM6Ly9jcm9uLWpvYi5vcmc) бесплатный крон сервис


ну я ему и кинул для крона метод

[Quasper]

ну я ему и кинул для крона метод


Ну твой способ будет с регулярным обновлением данных, что сказывается на трафике хоста, хотя он более оптимален но не так лёгок в понимании всего принципа. А я имел ввиду одну крон задачу в сутки которая просто вычитала бы единицу

[ImPasha]

Убиваем MySQL без регистрации и СМС с помощью кода, опубликованного выше. Всё, что вам понадобится - пара тройка запросов к скрипту и вот ваша база данных уже забита абсолютно бессмысленными операциями - добро пожаловать в мир сетевых пробок. Да и вообще, PDO для двух запросов, серьезно?

[ImPasha]

PHP:





[CODE]
if
(
!
file_exists
(
'last_executed'
)
)
file_put_contents
(
'last_executed'
,
'0'
)
;
$executed_time
=
intval
(
file_get_contents
(
'last_executed'
)
)
;
if
(
time
(
)
-
$executed_time

connect_error
)
exit
(
http_response_code
(
500
)
)
;
$db_handle
-
>
query
(
'DELETE FROM keys WHERE pDateEnd



Время интервала можно отредактировать во второй строке. Это не даст слишком часто обращаться к базе данных из этого скрипта.

[Livarka]

Убиваем MySQL без регистрации и СМС с помощью кода, опубликованного выше. Всё, что вам понадобится - пара тройка запросов к скрипту и вот ваша база данных уже забита абсолютно бессмысленными операциями - добро пожаловать в мир сетевых пробок. Да и вообще, PDO для двух запросов, серьезно?


зачем юзать mysqli когда есть PDO?

[ImPasha]

зачем юзать mysqli когда есть PDO?


Поддержка MySQLi начала осуществляться раньше, соответственно большее количество версий PHP поддерживает это расширение. Более того, MySQLi работает быстрее, чем PDO - как минимум по той причине, что он не такой массивный, как PDO. Подготовленные стейтменты в этом случае не играют большой роли, потому что скрипт не получает каких-либо данных из вне, а соответственно SQL-инъекции добиться невозможно. Так зачем подключать огромный PDO, если можно воспользоваться MySQLi, ускорив работу скрипта и сократив количество кода, да и к тому же упростив его для новичков в программировании?

[Livarka]

Поддержка MySQLi начала осуществляться раньше, соответственно большее количество версий PHP поддерживает это расширение. Более того, MySQLi работает быстрее, чем PDO - как минимум по той причине, что он не такой массивный, как PDO. Подготовленные стейтменты в этом случае не играют большой роли, потому что скрипт не получает каких-либо данных из вне, а соответственно SQL-инъекции добиться невозможно. Так зачем подключать огромный PDO, если можно воспользоваться MySQLi, ускорив работу скрипта и сократив количество кода, да и к тому же упростив его для новичков в программировании?


Я считаю, что если он пытается разрабатывать какую-то систему лучше использовать ПДО ибо ты не выстрелишь себе в ногу.

Ок юзает он mysqli и дойдет до того, что надо массив в запрос засунуть

bind_param не принимает массивы при выполнении запроса,

Именные плейсхолдеры и прочий синтаксический сахар для новичка самое то,

Вставка объектов напрямую в базу данных более удобно чем разбивать данные на переменные.

Твои слова про "убийство базы данных" ничем не доказаны.

Максимум плюс твоего кода это подключение в 1 строку к базе данных.

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

Да и прочитав твой код я не думаю, что он разберется что есть что.

Интересно, где ты в запросе DELETE увидел какую-то проблему с производительностью? Он Enterprise проект писать собрался с таким вопросом?

После выполнения скрипта у PDO запрос автоматически закрывается.

Зачем твой высер с циклом DELETE если это можно делать в 1 строку?

https://forum.antichat.xyz/attachments/27714705/

Сначала вытащить ID у которых дата окончания а потом в цикле по удалять строки где есть этот ID ты в своем уме чел? Ты ему полную ***ню посоветовал.

С таким подходом тебе только вордпресс ковырять

Не умеешь делать - не советуй

[ImPasha]

Я считаю, что если он пытается разрабатывать какую-то систему лучше использовать ПДО ибо ты не выстрелишь себе в ногу.
Ок юзает он mysqli и дойдет до того, что надо массив в запрос засунуть
bind_param не принимает массивы при выполнении запроса,
Именные плейсхолдеры и прочий синтаксический сахар для новичка самое то,
Вставка объектов напрямую в базу данных более удобно чем разбивать данные на переменные.
Твои слова про "убийство базы данных" ничем не доказаны.
Максимум плюс твоего кода это подключение в 1 строку к базе данных.
Мой же метод достаточно просто написать и забыть о коннекте раз и навсегда
Да и прочитав твой код я не думаю, что он разберется что есть что.
Интересно, где ты в запросе DELETE увидел какую-то проблему с производительностью? Он Enterprise проект писать собрался с таким вопросом?
После выполнения скрипта у PDO запрос автоматически закрывается.
Зачем твой высер с циклом DELETE если это можно делать в 1 строку?

Сначала вытащить ID у которых дата окончания а потом в цикле по удалять строки где есть этот ID ты в своем уме чел? Ты ему полную ***ню посоветовал.
С таким подходом тебе только вордпресс ковырять
Не умеешь делать - не советуй


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

Если редактировать мой код под твой SQL-запрос, то он станет ещё в два раза короче. Всё стало только лучше.

[Livarka]

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

Если редактировать мой код под твой SQL-запрос, то он станет ещё в два раза короче. Всё стало только лучше.


Наверное плейсхолдеры чтобы человек понимал как правильно делать в будущем?

Как драйвер для работы влияет на саму работу SQL запроса?

ты на языке передаешь подготовленные данные для выполнения и уже сама база данных выполняет работу.

Если mysqli быстрее на 0,00001 сек то есть ли смысл использовать его? Большинство PHP программистов рекомендуют PDO, он проще и понятнее.

Да, коннект я предоставил не сильно легкий для новичка, но это всяко лучше чем делать 2 запроса *** пойми для чего селект вообще всрался там.

Зачем выгребать id и потом удалять если можно просто удалить ? Ответь на вопрос

[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 обычный, так мускул будет воркать быстрее, но будет занимать немного больше места


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