Creating a password login

[cameljs18]

When i start my windows app i want to have a password screen to come
up then when the user types the correct password then it closes the
password form and opens the mainform.

 

[Marc Gravell]

There is nothing special about a password form; I think you need to
find a book or whatever about the fundamentals of showing a form; the
only minor change is you might want to hide the user input (TextBox
has "PasswordChar").

Show the login form; if successful, show the next...? Small example
below, but note that in a non-trivial system you might choose to hold
"am I logged in? as who? with what acces?" by a "Principal", which
means you don't have to track it separately.

bool loggedIn;
using (MyLoginForm loginForm = new MyLoginForm())
{
loggedIn = loginForm.ShowDialog() == DialogResult.OK;
}
if (loggedIn)
{
using (MyMainForm mainForm = new MyMainForm())
{
// maybe "Application.Run(mainForm)" instead
mainForm.ShowDialog();
}
}

 

[Nicholas Paldino [.NET/C# MVP]]

The thing that is not so trivial about this is how you perform the
authentication. Quite frankly, it's not something that people should
re-implement if we are talking about applications on local machines. There
is a reason for single-sign on in Windows: there is ^already^ someone logged
in and authorized on the machine

If this is a web-based app then that is different, because the domain
you are working in is larger than the machine.

But generally, passwords for local applications are a bad idea, IMO.

 

[Ian Semmel]

Not really if you are using, say, a mysql database and the
application-level authorizations differ from windows.

The thing that is not so trivial about this is how you perform the
authentication. Quite frankly, it's not something that people should
re-implement if we are talking about applications on local machines.
There
is a reason for single-sign on in Windows: there is ^already^ someone
logged
in and authorized on the machine

If this is a web-based app then that is different, because the
domain
you are working in is larger than the machine.

But generally, passwords for local applications are a bad idea, IMO.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

There is nothing special about a password form; I think you need to
find a book or whatever about the fundamentals of showing a form; the
only minor change is you might want to hide the user input (TextBox
has "PasswordChar").

Show the login form; if successful, show the next...? Small example
below, but note that in a non-trivial system you might choose to hold
"am I logged in? as who? with what acces?" by a "Principal", which
means you don't have to track it separately.

bool loggedIn;
using (MyLoginForm loginForm = new MyLoginForm())
{
loggedIn = loginForm.ShowDialog() == DialogResult.OK;
}
if (loggedIn)
{
using (MyMainForm mainForm = new MyMainForm())
{
// maybe "Application.Run(mainForm)" instead
mainForm.ShowDialog();
}
}

 

[Ian Semmel]

I think it is a better user experience to have the main window come up
and then the login form.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

In this case all you need to do is create a Modal form, depending of the
return the app (and the main form in the back) close or is activated.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

It depends, if you have an isolated machine that is no connected to any
domain you might want to have auth built into the app itself. Also useful is
when a login is shared among several person and each of these person needs
different access to the app.

--
Ignacio Machin
http://www.laceupsolutions.com
Mobile & warehouse Solutions.

The thing that is not so trivial about this is how you perform the
authentication. Quite frankly, it's not something that people should
re-implement if we are talking about applications on local machines.
There is a reason for single-sign on in Windows: there is ^already^
someone logged in and authorized on the machine

If this is a web-based app then that is different, because the domain
you are working in is larger than the machine.

But generally, passwords for local applications are a bad idea, IMO.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

There is nothing special about a password form; I think you need to
find a book or whatever about the fundamentals of showing a form; the
only minor change is you might want to hide the user input (TextBox
has "PasswordChar").

Show the login form; if successful, show the next...? Small example
below, but note that in a non-trivial system you might choose to hold
"am I logged in? as who? with what acces?" by a "Principal", which
means you don't have to track it separately.

bool loggedIn;
using (MyLoginForm loginForm = new MyLoginForm())
{
loggedIn = loginForm.ShowDialog() == DialogResult.OK;
}
if (loggedIn)
{
using (MyMainForm mainForm = new MyMainForm())
{
// maybe "Application.Run(mainForm)" instead
mainForm.ShowDialog();
}
}

 

[Kbalz]

Hi,

It depends, if you have an isolated machine that is no connected to any
domain you might want to have auth built into the app itself. Also useful is
when a login is shared among several person and each of these person needs
different access to the app.

--
Ignacio Machinhttp://www.laceupsolutions.com
Mobile & warehouse Solutions.
message





- Show quoted text -

Yep, and in this case as well: We have computers on our shop floor,
they are all logged into the Domain as user name "SHOP" - but each
Employee that uses our application has a real name that we would like
to track via our application. This saves window's user login names,
CAL licenses I think its called?

 

[Nicholas Paldino [.NET/C# MVP]]

That's the thing though, in this scenario, you are actually battling the
OS. There is no reason to have every person logged in as SHOP. You
basically are throwing away the benefits of having different users on the
network (as well as the ability to put them into groups).

There is no reason to "save" user login names, because the domain should
be doing it for you in this situation already.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi,

It depends, if you have an isolated machine that is no connected to any
domain you might want to have auth built into the app itself. Also useful
is
when a login is shared among several person and each of these person needs
different access to the app.

--
Ignacio Machinhttp://www.laceupsolutions.com
Mobile & warehouse Solutions.
in
message





- Show quoted text -

Yep, and in this case as well: We have computers on our shop floor,
they are all logged into the Domain as user name "SHOP" - but each
Employee that uses our application has a real name that we would like
to track via our application. This saves window's user login names,
CAL licenses I think its called?