Re: [SOLVED] Cannot display provider-specific login prompt
- From: "Scott M." <s-mar@xxxxxxxxxxxxx>
- Date: Wed, 30 Sep 2009 22:10:44 -0400
Hi John,
I'm happy that you were able to get the solution that you desired.
At the risk of beating a dead horse, and really for others who might stumble
across this thread, I wanted to just address one point that was central to
our discussion.
As a best practice, it is not a good idea to assume anything about the user
of your application, or at least to assume a level of knowledge that you can
not reasonably expect the user would have. Given this, when creating
database connected applications, it is not reasonable to expect your end
user to know anything about their data other than their own credentials and
what data they want. I know that in your particular case, you wanted a
scenario where the program wouldn't have to know about the database, because
the user was going to supply all the details, but unless you are building an
application for DBA's, this approach goes against all best practices for
good useability and design. You mentioned several times, when I pointed out
that a user should only enter these 3 pieces of info., that that was
incorrect, and I must finish out this thread by saying that it is correct
and to expect a user to supply/know any more than this is really what's
considered incorrect.
This is very much like two of the core tennants of Object-Oriented Design,
which are the concept of encapsulation and abstraction - - or to think of
your object as a "black box" of code. Only the creator need know how the
box does what it does, but the user of the box, need not (and should not)
know anything at all about the inner workings of the box. They only need
know how to interface with the box. To expect a database user to know (and
input) the details of connection string parameters, not only puts
unreasonable pressure on the end users, but also exposes your application to
a multitude of security concerns as well as potential corruption to the
underlying data store because, in your design (hooking the
ConnectionStringBuilder up to a PropertyGrid for the end user to populate),
you are breaking encapsulation of your application.
The first thing a hacker tries to do when wanting to get into a system, is
try to enter invalid data into input fields to see what error messages are
returned. These error messages (if unfiltered and passed directly to the
UI) in a database application, can contain path information as well as
information about the security model and database schema itself. Armed with
this information, the hacker can hone the attack directly against a specific
resource within the system. Allowing the ConnectionStringBuilder to bind
directly to a PropertyGrid, so that the end user can put whatever they want
in whatever parameters are listed is very hard to justify in a production
environment because you have no input validation layer in the applicaiton.
I do understand your stated requirements: that the program be completely
ignorant of the data source being connected to and that the program be
compatible with any and all other data sources that may come down the line.
And, in a perfect, monitored world, that may work. I don't know enough
about the environment you'll be implementing your application to be able to
predict exactly the success or failure you will have with your chosen
approach. But, as I said, expecting the users to supply all the pertinent
details of the connection, for the sake of the program being able to connect
to anything at any time, is generally considered a poor design choice.
I belive (well, actually I know) that you could accomplish much the same
results by having the basic shell of the potentially needed connection
strings standing by and simply ask the user for the desired data source,
their user name, and their password. Yes, the program will have to know
more details about the potential data sources and how to connect to them and
yes, I understand that this was not what you wanted, but the reality is that
this would generally be the better choice for improved security, control
over scalability, and the end user's experience.
I honestly believe that your design requirements (program doesn't know
anything about the data source, usesr supplies all pertinent connection
info., no custom UI need be developed) are unrealistic for any mainstream
application.
Please understand, I'm not trying to insult you in any way. I just want
anyone else reading this to understand what the best practices are in this
situation and why.
Good luck,
Scott M.
"John Brown" <JohnBrown@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:44A97E14-E15B-43C3-8E87-D7C78C53EE56@xxxxxxxxxxxxxxxx
First, for the benefit of others who may find this thread, let me state a
method of displaying a dialog box prompt that will let a user connect to
any
data source that has an ADO.NET provider. This program will work
unmodified
with SuperDB 2012, even though their website is not up yet, and I have no
information about the connection string that I will need.
' sProviderName can be selected from a list box. Of course, we would
' display the friendly names, but use the object names internally
Dim dbpf as DBProviderFactory = GetFactory(sProviderName)
'Get a ConectionStringBuilder that will build a connection string for
sProviderName
Dim csb as DbConnectionStringBuilder = dbpf.ConnectionStringBuilder()
' Use a PropertyGrid contol on your form to display the properties
' of the connection string, which will correspond to the keywords in
' the connection string; user id, password, etc.
PropertyGrid1.SelectedObject = csb
' When you run your form, it will show a property grid that
' corresponds to the conection string for your database.
' After you show the form, you can create a generic connection object
Dim cnn as DbConnection = dbpf.CreateDbConnection()
cnn.ConnectionString = csb.ConnectionString
cnn.Open
' At this point, you will be connected to a database about which you knew
' nothing beforehand. You could have started with an empty
' config file, but you can save the whole string or any part of it in the
'config file.
Now, I will address the points that you raised.
"Scott M." wrote:
<snip>
You are telling me that you'll need to connect to Access and
Oracle, so that means you need to have two different connection strings.
This is the sequence of events, which I evidently did not make clear.
- I needed to connect to Access and Oracle with one program.
- The initial suggestion was that I should write:
If Access
DoThis
Else
DoThat
End If
- I was not interested, because I never had to do that before.
- So I asked myself "Does this mean that I cannot write what the ODBC
documentation calls a Generic application, i.e., one that 'must work with
a
variety of different DBMSs and that the developer does not know beforehand
what these DBMSs will be.'"?
- The DbProviderFactory methods and generic Dbxxx classes were suggested,
but there was still a gap. In my opinion, such an application needs a way
to
present a login box that is appropriate for the database. Yes, the user
can
edit my config file, but if they wanted to edit config files, they would
use
Linux.
- The PropertyGrid control was the final piece of the puzzle. It allows me
to present a GUI that will help the user to build a connection string.
First, I reject the scenario you have started out with. All you need
from
the end user is their id, password, and database.
What you need depends entirely on what the developers of the database say
you need. You sent me to ConnectionStrings.com, so you know this.
SuperDB's
connection string is not there, by the way.
You would not present
them with a list of OleDb Providers because they wouldn't understand what
that list represents.
I am assuming that ADO.NET providers have friendly names like "Data
Provider
for SuperDB" for display purposes, and a name like Data.SuperDB.Client
for
use in programs. Also, we never defined "user". If you use my program,
then
you are a user, even if you are an MVP. I also don't care who is using the
program.
<snip>
Problem: Your environment uses Windows Authentication.
This is less a programming issue and more of a configuration issue. But,
if
you need windows authentication, you can certainly set up the connection
string to use it.
At this point, I don't know which authentication methods are supported by
SuperDB, and I no longer care, because I now have a way to present the
options to them. They can set up their environment however they like. I
don't
need to know. Don't ask, don't tell.
Problem: Even if you leave the fields blank, you still cannot connect,
because I need to specify the keyword to turn on Windows
authentication.
Problem: the program doesn't know that.
This is where I am bit confused. Are you saying that the user gets to
tell
your program if Windows Authentication is being used? This is not
something
that end users know and understand and hardly something that you'd ask
them
to tell you. You should know how your users need to connect and code for
that.
Excel allows you to populate a spreadsheet with data from a database. You
can select a DSN, or you can create one on the fly. If you select the SQL
Server driver, it will present you with a login box with user name,
password,
etc., as well as a "Use trusted connection" checkbox, which you can tick
or
not. The Excel developers don't know whether your data is in SQL Server or
text files. They don't care whether you use WIndows or SQL Server
authentication. They also expect that Excel will be able to import data
from
SuperDB when it is released, and they don't tell anybody that they need to
edit a file to connect to MS Access, SQL Server, or SuperDB.
Solution, the SqlConnectionStringBuilder class. This is not the problem
you
think it is.
The solution is the generic ConnectionStringBuilder, along with a
PropertyGrid to allow the user to set the properties. It's useless without
the PropertyGrid. Or more accurately, I woud have to find out how the
PropertyGrid does what it does, but I have no reason to do that unless I
was
trying to display a really elegant login box with tabs and what not.
Your OP was that you need to code against Access or Oracle, now you are
saying it could be anything?
Explained above. I *need* to support Access and Oracle, but I *want* to
support anything.
The DBProvider Factory will only help you code one pattern that can
work
for
the two different databases, it's not going to help you figure out
your
connection strings.
With the help of the PropertyGrid control, DbProviderFactory can certainly
help me figure out my connection string.
You seemed to be
ok with the ODBC login dialog popping up to promt the user to fill in
the
details, why are you having trouble with having them do the exact same
thing, but with a dialog that you create?
Since SuperDB has not been released yet, I cannot possibly create my own
dialog. I don't know what will be required. You keep insisting that all
you
need is a user id, password and database, but it simply is not true. I am
going ask SuperSoft to add a surprise required parameter for connection.
We'll see how far you get with a dialog box with fields just for user
name,
password and database.
What I am having trouble understanding is that it seems that you want the
user to tell the program (or you think that I'm saying that a user should
tell the program) explicit details about how to connect to the desired
data
source.
This is exactly what I want. Users of Excel, Access, Crystal Reports and a
host of other applications do this every day. The real mystery is why you
think that it is so strange.
But none of this matters anymore. The problem has been solved. I can do
using ADO.NET what I used to do using ODBC.
Regards,
John Brown.
.
- Follow-Ups:
- Re: [SOLVED] Cannot display provider-specific login prompt
- From: John Brown
- Re: [SOLVED] Cannot display provider-specific login prompt
- References:
- Re: [SOLVED] Cannot display provider-specific login prompt
- From: John Brown
- Re: [SOLVED] Cannot display provider-specific login prompt
- Prev by Date: Re: [SOLVED] Cannot display provider-specific login prompt
- Next by Date: Re: [SOLVED] Cannot display provider-specific login prompt
- Previous by thread: Re: [SOLVED] Cannot display provider-specific login prompt
- Next by thread: Re: [SOLVED] Cannot display provider-specific login prompt
- Index(es):
Relevant Pages
|
