проверка пароля при входе

← →
Kein © (2003-10-15 16:41) [0]

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

← →
Skier © (2003-10-15 16:47) [1]

> . как это делается

в dpr-файле

← →
undert © (2003-10-15 17:15) [2]

Удалено модератором

← →
Kein © (2003-10-16 16:21) [3]

to Skier:

А пример можно? Просто если менять порядок создания форм, в зависимости от условия, то форма ввода пароля станет главной, что нежелательно.

← →
Reindeer Moss Eater © (2003-10-16 16:25) [4]

... и соответственно пускать пользователя или не пускать.

Что под этим подразумевается?

← →
pasha_golub © (2003-10-16 16:27) [5]

Советую, пароль в явном виде не хранаить, а хранить например его md5-сумму, потом при вводе пароля сравнивать эту сумму с суммой, хранящейся в файле например

← →
KSergey © (2003-10-16 16:32) [6]

Зачем форму пароля делать главной???
И еще. Я про dpr не согласен. Писал уже и не раз почему.
Автору: в OnCreate главной формы созлаете модально форму пароля, если не угадал пользователь - Application.Terminate - и всех делов.

← →
mOOx_ © (2003-10-16 16:33) [7]

Application.Initialize;
Application.CreateForm(TDM, DM);
if(ParamStr(1)="/s")then
begin
Application.CreateForm(TFServer, FServer);
Application.CreateForm(TFServerSet, FServerSet);
end;
if(ParamStr(1)="/c")then
begin
Application.CreateForm(TFClientSet, FClientSet);
end;
Application.Run;
На место ПарамСтр можно вставить булеву процедуру, которая открывает окно логина или что там надо. Надеюсь понятно.
PS. Народ, делфи это, конечно, рулез, но не стоит забывать про паскаль :)

← →
mOOx_ © (2003-10-16 16:37) [8]

Только в дпр!!!!!!!!!! У меня есть проект большой, в нем я так и сделал (через онКреате главной формы). Често говоря, за....ся потом все это дело неределывать, когда требуется что-то из формы, которая еще не создана.
КОнечно, в моем примере, это не показано, но если пошевелить мозгами, то можно привести пример.

← →
KSergey © (2003-10-16 16:38) [9]

Все же в его случае я бы не советовал делать "На место ПарамСтр можно вставить булеву процедуру, которая открывает окно логина"

← →
mOOx_ © (2003-10-16 16:40) [10]

Причины?

← →
mOOx_ © (2003-10-16 16:42) [11]

Да, кстати, интересно, а логин для чего?
Если это коннект к БД, то одно, а если надо, то другое :)

← →
KSergey © (2003-10-16 16:42) [12]

Не надо это делать в DPR.
Т.е. конечно бывают случаи, ваш пример - не плох, но знаете почему? В коде, выполняемом вне какого-либо метода объекта Application, исключение... ну врятли возможно. Очень сомнительно. Т.е. я даже и не знаю где бы оно могло произойти ;)
Но при создании форм и проч. исключение словить - занефиг делать. Не говоря уде о БД.
А в этом случае исключение необработанным уходит системе, и тогда уже начинаются оочень нездоровые глюки.

← →
Reindeer Moss Eater © (2003-10-16 16:43) [13]

Только в дпр!!!!!!!!!! У меня есть проект большой, в нем я так и сделал (через онКреате главной формы). Често говоря, за....ся потом все это дело неределывать, когда требуется что-то из формы, которая еще не создана.

В OnCreate уже ВСЕ создано что может быть создано.
Другое дело, что Application.Terminate прямо в OnCreate - не совсем хорошо. Но для этого же есть PostMessage главной форме.

← →
mOOx_ © (2003-10-16 17:04) [14]

А я и не про эту форму говорю. Например так:
Application.Initialize;
Application.CreateForm(TDM, DM);
Application.CreateForm(TFServer, FServer);
Application.CreateForm(TFServerSet, FServerSet);
Application.Run;
У меня, допустим, висит на онКреате в FServer опрос настроек сервера, которые указываются в FServerSet. А в FServerSet при нажатии на кнопку принять устанавливались свойства в FServer. Я это обошел, но все же...ВОТь :)

← →
Reindeer Moss Eater © (2003-10-16 17:09) [15]

Ну и как это фатально влияет на предпочтительное программирование логона именно в dpr?

← →
KSergey © (2003-10-16 17:30) [16]

> [14] mOOx_ © (16.10.03 17:04)
> У меня, допустим, висит на онКреате в FServer опрос настроек
> сервера, которые указываются в FServerSet. А в FServerSet
> при нажатии на кнопку принять устанавливались свойства в
> FServer. Я это обошел, но все же...ВОТь :)

Ну если есь такая завязка на последовательность создания форм, то лично я бы тогда пожалуй FServerSet создал бы в FServer.OnCreate, а не в AutoCreate.
Чтобы уже наверняка.

← →
mOOx_ © (2003-10-16 17:30) [17]

Фатально, никак. Ну может переборщин немного с "...Только в дпр!!!!!!!!!!...". Чтож, бывает. А вообще, на сабж, кажется, ответ дан. Вариантов много и каждый может дить. Так что... Пользуйтесь.

Точно!!!! Об этом я как-то не подумал :)

Думаю, что в программу (хотя бы для рекламы и продвижения) можно пускать всех желающих. А вот пользование контролами (полномочия) - по паролю

Ну в этом случае в меню делают пункт "Login"

Даже есди без пароля нельзя работать, все равно лучше, оставляются открытыми в меню тольео пункты - "Выход" и "О программе"

Во, действительно дельный совет :). Правда вот автор не хочет раскрывать первопричины своего желания.

> то форма ввода пароля станет главной, что нежелательно.

fm:=fmParolInput.Create(Application);
fm.ShowModal;
s:=fm.ParolEdit;
fm.Free;

и fm главной не будет....

Есть еще вариант переопределить конструктор главной формы, в нем модально показывать форму ввода пороля....

to WithOut Any ...

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

проверка пароля при входе Найти похожие ветки