Database Reference
In-Depth Information
twoFactorLength . If we have sufficient numeric characters, we return the StringBuffer as a String , else
we return an empty string.
There is a perception among programmers, especially those (like me) who have worked extensively
with perl, that checking the format of a string is best accomplished by using regular expressions. Regular
expressions are a succinct way to express patterns of characters, including optional formatting. For
example, this regular expression represents a SSN pattern: " ^\\d{3}[- ]?\\d{2}[- ]?\\d{4}$ ". I believe
pattern matching has limits that need to be recognized and respected. In checkFormat2Factor() , for
instance, we are going to throw away extraneous data (words or spaces) that a user might have seen on
their cell phone or pager screen and entered. Pattern matching does not work well for free-form user
input like this. The second issue I have with complex regular expressions is that to read them often
requires a decoder ring and a sheet of scrap paper. (The same can too often be said of perl code in
general.)
Save Connection Strings from the Client Perspective
We are going to explore saving connection strings and associating them with an application from both
the client side and the server side. In some cases, developers may choose to use all our security except
the application authorization, so they will benefit from having an independent method for using
connections strings on the client that have not been stored on Oracle database. These can even be
combined with a set of connection strings that are maintained by our application authorization.
However, if a developer elects to not store his connection strings under appver 's supervision, he will
need to find another way to secure the password. Also, he will lose two-factor authentication, which we
have delegated to the application authorization process.
Method to Put Connection Strings in the List for an Application
On the client, we have a method, putAppConnString() that we can use to add connection strings to
connsHash . It takes 5 arguments (see Listing 10-23): the instance name, user name, password, host name,
and port (as a String ). By taking these components separately, it leaves the assembly of a connection
string to us. We can assure that the connection string format is acceptable. We do take a moment to trim
off any whitespace from the head and tail of each argument, calling the String.trim() method.
As an optional parameter, by way of an overloaded method, we accept a boolean value, which can
direct us to test the connection string before saving it in connsHash .
We assume the connection string, as we've formatted it, is okay to be added to connsHash ; however,
if we've been directed to test the connection string, we may change that evaluation. If we are testing the
connection string, we simply instantiate a new Connection based on the connection string and use it to
query the database. If that fails, we have determined that the connection string is not good.
Listing 10-23. Put Connection Strings in List, putAppConnString()
public static void putAppConnString ( String instance, String user,
String password, String host, String port )
{
putAppConnString( instance, user, password, host, port, false );
}
public static void putAppConnString ( String instance, String user,
String password, String host, String port, boolean testFirst )
{
instance = instance.trim();
user = user.trim();
 
Search WWH ::




Custom Search