@volkov_pn, напомни, плиз, а real_escape, случайно, не против инъекций нужны?

Для продажи привелегий сервера cs 1.6

SHA() в sql - это хеш, я так понял?

кинь оба скрипта, ща подправлю, попробуешь запустить

тебе аватарку обязательно пилить?

там просто отдельный гемор, так просто не получится

я только заметил, что у тебя файл-инпут для авы

проще всего будет убрать поле "аватарка" из бд и из регистрации нафиг

потому что еще натрахаешься

пссст

че с авой-то

Жуть... В каждом файле писать подключение к бд. Каждый файл является точкой входа. Помесь разметки и sql запросов...

Жуть... В каждом файле писать подключение к бд. Каждый файл является точкой входа. Помесь разметки и sql запросов...

курсач, че ты хочешь

курсач, че ты хочешь

Думаешь это меняет суть дела? А потом считают, что так нормально делать и продолжают так проектировать и писать

Думаешь это меняет суть дела? А потом считают, что так нормально делать и продолжают так проектировать и писать

кто считает?) качается же народ, уходит от говнокода, а кто не уходит - тот при себе имеет отличный индикатор крутоты скилла

все я тут

и сразу варнинг о способности к прокачке

тебе аватарку обязательно пилить?

там просто отдельный гемор, так просто не получится

я только заметил, что у тебя файл-инпут для авы

проще всего будет убрать поле "аватарка" из бд и из регистрации нафиг

потому что еще натрахаешься

аватарку

тебе аватарку обязательно пилить?

по сути нет

по сути нет

гуд

гуд

Это что то меняет?

да, причем вкрутую

пришлось бы тебе вздрючивать еще одну ночь на ничтожный файл-инпут и аватарку

Жуть... В каждом файле писать подключение к бд. Каждый файл является точкой входа. Помесь разметки и sql запросов...

напомни, пожлст, можно ли в INSERT опускать столбцы?

Skip В одном файле есть экранирование переменных. В другом нет. Если версия php 5.5 и выше, то лучше использовать password_hash вместо sha

синтаксис через VALUES

Skip В одном файле есть экранирование переменных. В другом нет. Если версия php 5.5 и выше, то лучше использовать password_hash вместо sha

лал, ты еще расскажи про соление паролей и доп. поле в БД, вот радости будет)

напомни, пожлст, можно ли в INSERT опускать столбцы?

Можно, если значения передаешь в порядке, котором они следуют

Можно, если значения передаешь в порядке, котором они следуют

о, спс

лал, ты еще расскажи про соление паролей и доп. поле в БД, вот радости будет)

Расскажу, если требуется. К тому же доп поле в бд не требуется для соли

Расскажу, если требуется. К тому же доп поле в бд не требуется для соли

генерим же уник соль для каждого юзера, не?

генерим же уник соль для каждого юзера, не?

Для этого есть password_hash сейчас. Она генерирует и хеширует вместе с солью. Все в одну строку выходит

блин, кароч, попробуй, но вот жопой чую, упустил кита под носом

Для этого есть password_hash сейчас. Она генерирует и хеширует вместе с солью. Все в одну строку выходит

хм. функция генерит уник-соль для данного юзера и одновременно задействует ее в алгоритме хеширования, в котором эта же функция может не раз примениться?

или тут вообще все не так, как, например, раньше с md5 было?

блин, кароч, попробуй, но вот жопой чую, упустил кита под носом

Cannot add or update a child row: a foreign key constraint fails (marriageagencie.user, CONSTRAINT fk_user_staff1 FOREIGN KEY (staff_id) REFERENCES staff (id) ON DELETE NO ACTION ON UPDATE NO ACTION)

о, ну хоть что-то

Cannot add or update a child row: a foreign key constraint fails (marriageagencie.user, CONSTRAINT fk_user_staff1 FOREIGN KEY (staff_id) REFERENCES staff (id) ON DELETE NO ACTION ON UPDATE NO ACTION)

У тебя внешний ключ имеется, который ты не заполняешь

тэээк

Cannot add or update a child row: a foreign key constraint fails (marriageagencie.user, CONSTRAINT fk_user_staff1 FOREIGN KEY (staff_id) REFERENCES staff (id) ON DELETE NO ACTION ON UPDATE NO ACTION)

а что у тебя в staff_id должно лежать?

лал

хм. функция генерит уник-соль для данного юзера и одновременно задействует ее в алгоритме хеширования, в котором эта же функция может не раз примениться?

Да. Для хеширования password_hash(). Для проверки password_verify()

хитрожопо

а че не в одной тбл?

или это - нуавдруг - для оптимизации?)

кароч

если у тебя кроме этого скрипта регистрации больше регистраций нет, то все сложнее

если не изменишь структуру (не объединишь в одну таблицу users и staff), тебе сначала придется регать пользователя в staff со стандартной проверкой логина-пароля, а потом уже создавать отдельную строку для него же в другой таблице

@SkipTyler с какой целью staff и user разделил?

Да. Для хеширования password_hash(). Для проверки password_verify()

прикольно

@SkipTyler с какой целью staff и user разделил?

бд не я создавал. Препод выдал

судя по тому, что у тебя есть скрипт логин-пароль1-пароль2, ты, я так понял, уже имеешь скрипт добавления юзера в таблицу staff

бд не я создавал. Препод выдал

оп-па

судя по тому, что у тебя есть скрипт логин-пароль1-пароль2, ты, я так понял, уже имеешь скрипт добавления юзера в таблицу staff

да

бд не я создавал. Препод выдал

Тогда как сказали выше. Для добавления пользователя придется два запроса делать. И лучше с транзакцией

бд не я создавал. Препод выдал

а можно веселухи ради тз препода увидеть?

>И лучше с транзакцией вот, кстати, с этим вообще не ко мне

мне девушка на словах передала

лал

ERROR: S client not available

а можно веселухи ради тз препода увидеть?

Тоже интересно

цирк с конями

нужно узнать можно ли объеденить ли таблицы

Тоже интересно

кстати говоря: а ведь может же быть такое, что таблицы разделяют подобным образом для оптимизации? когда обращаешься в громадную телегу, наверн, больше жрет, не? а то я в правильной структуре БД не силен

>И лучше с транзакцией вот, кстати, с этим вообще не ко мне

Это на случай если один из запросов выполняется с ошибкой

Это на случай если один из запросов выполняется с ошибкой

та я понял)

просто на слово "транзакции" у меня сразу идут какие-то "сокеты" или что там

я тупо даже не знаю, как это вообще делается, так как наигрался с бекендом до всего этого

так новая инфа я могу убрать связь между этими талицами, привязку user k staff

было бы, кстати, прикольно, если бы мы щас коллективно напилили бы суперскрипт с хешами и прочим, а препод слил бы курсач, так как по объему знаний очевидно, что это чужое

так новая инфа я могу убрать связь между этими талицами, привязку user k staff

но оставить таблицы разделенными?))

Это похо?

так новая инфа я могу убрать связь между этими талицами, привязку user k staff

Объединяй таблицы в одну

Это похо?

ну, да, весьма)

понял

Это похо?

Нарушает целостность данных.

спроси, можно ли слить таблицы

блин, это же все с нуля прийдется делать.

чтоб наверняка

не

совершенно не факт

если слив разрешен "свыше", можно просто тупо полей добавить и проверку на логины-пароли

хотя...

я тут глянул на сами таблицы

очень похоже на то, что задачка не столько на скриптотанцы, сколько на связи таблиц

вполне возможно, что слив - это как раз в точности против условий

тьфу, *слияние

вполне возможно, что слив - это как раз в точности против условий

не факт

Некоторые сливали в 1

не факт

давай сюда девушку свою))

ну она рядом

)