ASTA User's Guide
Topics
Connecting Clients & Servers
Managing the Login process & Customizing the Login Process
Topic Discussions
Connecting Clients & Servers
|
Key |
Client |
Server |
| Properties | Active,
Address, Host, Port UserName, Password ApplicationName |
Port UserName, Password |
| Methods |
- |
- |
| Events | OnConnect, OnDisconnect | OnConnect, OnDisconnect, OnAccept |
ASTA is based on the TCP/IP protocol. In order to use it successfully, you don't need to know a lot about TCP/IP but it helps to know some basic principles. AstaServers and AstaClients "speak" to one another using sockets. A socket is the combination of an IP Address and a Port. The following socket, 204.125.124.10:3245, has an IP address of 204.125.124.10 and a port of 3245.
An AstaServer starts a socket that can handle multiple connections. When
you look in the object inspector for an AstaServerSocket, you will notice
that there is not an Address property but there is 
a port property. The
AstaServerSocket's will automatically assume the system's IP address for
its address -- if you start it on a system with an IP address of 204.125.124.10
then it's IP address will be 207.125.124.10. The AstaServerSocket will
use the port that you assign to it, in our example, Port 9000. If your
server's IP address is 204.125.124.10, and you assign Port 9000, then
your server will be listening for connections on the following socket:
204.125.124.10:9000. [To determine the IP Address of a Windows NT system,
type IPCONFIG at the DOS Command Prompt. For Windows 95 I believe the
command is WinIPConfig].
When you create your clients, you must specify the Address and the Port of the server. In this case, you would set that AstaClientSocket to 204.125.124.10 for the address and 9000 for the Port.
If you wish to see design time data when writing your application, you must specify the correct address and port and the server must be running!
The AstaClientSocket's Host property can be used for DNS names. If you are using DNS and your server has a name you can enter "YourServerName.Com" in the Host property. If that field is used, it will override the value in the Address property. You must specify the port whether you use the Host property or the Address property.
For detailed information on the OnConnect, OnDisconnect and OnAccept events, please see Borland's help file entries for the TClientSocket and TServerSocket. There is a bit of counter-intuitive behavior at the server that can be confusing for the novice; the OnAccept event, not the OnConnect event, is the first point where the server actually has meaningful access to the client connection.
Special Notes for the server:
The ServerType should remain stNonBlocking. The Active property should
be set to True (after you set the Port).
Special Notes for the client:
For most users, the Active should remain false, it's status is managed
behind the scenes. If you set the ConnectAction property to caNone, however,
then you manage the active status of the socket at runtime.
|
Key |
Client |
Server |
| Properties | ApplicationName, AutoLoginDlg, Password, UserName | UserCheckList |
| Methods | AttemptClientLogin |
- |
| Events | OnLoginAttempt | OnClientLogin |
ASTA provides facilities to help you manage the client login process. The Client's AutoLoginDlg property is the key to the login process. The AutoLoginDlg can be set to one of three selections:
- ltLoginDlg
- Displays a UserName and Password dialog. The user input is placed in the UserName and Password properties and transmitted for verification at the server. The Server's OnClientLogin event handler must be coded.
- ltLoginNoDlg
- Passes the values set in the UserName and Password properties, must be verified at the server. The Server's OnClientLogin event handler must be coded.
- ltNoChallenge
- UserName and Password properties are transmitted, automatically verified at server, no additional coding is required at the server.
No matter which option is selected, the AstaClientSocket's UserName, Password and ApplicationName are transmitted to the Server (if ltLoginDlg is selected, the UserName and Password properties are set to the input values entered by the user, then transmitted). If ltLoginDlg or ltLoginNoDlg have been selected, then you must code the AstaServerSocket's OnClientLogin event.
procedure TForm1.AstaServerSocket1ClientLogin(Sender: TObject; UserName,
Password, AppName: String; var Verified: Boolean);
var
AllowUserIn : Boolean;
begin
//Do your stuff here -- typically lookup values in a database
if AllowUserIn then Verified := True else Verified := False;
end;
If verified is set to True, then the client will be connected to the server. Whether verified is set to True or False, that result will be transmitted back to the client. Whether or not you code the AstaClientSocket's OnLoginAttempt event handler will dictate what happens next. If you do not code the event handler and then the client will either continue normally if the result was true, or terminate immediately if it is false. If you would like to take other action -- possibly allow the user three login attempts before terminating the application, or perhaps showing a menu only after the user has been verified, then you can code the OnLoginAttempt event.
procedure TForm1.AstaClientSocket1LoginAttempt(Sender: TObject; ClientVerified: Boolean); begin //Track login attempts, kill app if they goof three times Inc(FLoginCounter); if (FLoginCounter >=3) and not(ClientVerified) then begin Application.Terminate; end else if ClientVerified then // good login action goes here MainMenu1.Items[0].Visible := True else // bad login action goes here -- reprompt login dialog* AstaClientSocket1.AttemptClientLogin; end;
* the AutoLoginDlg's property is set to ltLoginDlg
If you wish to track the users that have been logged into the server, assign a TCheckListBox to the AstaServerSocket's UserCheckList property.
|
Key |
Client |
Server |
| Properties | ConnectAction, caCustomConnect |
- |
| Methods |
- |
- |
| Events | OnCustomConnect |
- |
Many developers want to create a custom login screen for their users. A custom login provides you with the opportunity to present a promotional splash screen or even an advertising opportunity.
If you select the caCustomConnect option of the AstaClientSocket's ConnectAction property, then you can customize a login screen. If you select this option, you can display your login screen from within the OnCustomConnect event handler. In that event handler, you have access to the AstaClientSocket and all of its properties. You must set the Address and Port property or the Host and Port property. Those properties become your responsibility when implementing a custom login.
procedure TForm1.AstaClientSocket1CustomConnect(Sender: TObject);
begin
// CALL YOUR CUSTOM LOGIN SCREEN HERE
// SET USERNAME, PASSWORD, AND OTHER PROPERTIES
// YOU MUST SET THE ADDRESS (OR HOST) AND PORT
AstaClientSocket1.Address := '206.210.19.131';
AstaClientSocket1.Port := 8080;
end;
|
Key |
Client |
Server |
| Properties | Encryption | Encryption |
| Methods |
- |
- |
| Events | OnEncrypt, OnDecrypt | OnEncrypt, OnDecrypt |
ASTA provides great flexibility for encryption. In addition to giving you complete control over any encryption scheme that you may wish to implement, ASTA ships with built-in encryption that you can activate without writing a single line of code -- instant encryption!
To enable the built-in encryption simply set the
AstaClientSocket and the AstaServerSocket's Encrypt property to "etAstaEncrypt"
and recompile (you must recompile the server and the client, otherwise
they will be out-of-synch). The etAstaEncrypt algorithm is quite simple
but it will discourage casual lurkers (keep in mind that most security
breaches are the result of social engineering, not highly skilled hacking).
For those developers that need to implement high-level security, we have
provided OnEncrypt and OnDecrypt event handlers. Those event handlers
allow the developer to plug in third-party or self-authored encryptions
schemes. You have complete control over the encryption that you wish to
use. To implement your own encryption routines, you must insert your encryption
and decryption routines in the server and the client's OnEncrypt
and OnDecrypt event handlers.
ASTA passes the message into the event handlers as a String type. If your encryption library is string based you code would look like the following calls.
procedure TForm1.AstaServerSocket1Encrypt(Sender: TObject; var S: String); begin S := YourEncryptionRoutineHere(S); end;
procedure TForm1.AstaServerSocket1Decrypt(Sender: TObject; var S: String); begin S := YourDecryptionRoutineHere(S); end;
If, however, you have a streams based encryption library, you would need to take some extra steps. ASTA provides a couple of functions to help you manage String and Stream conversions. To use these functions, you must add AstaUtil to the unit's Uses clause.
function NewStringToStream(S: AnsiString):
TMemoryStream;
function StreamToString(MS: TMemoryStream): AnsiString;
The following code shows how you would use these calls to encrypt the message.
procedure TForm1.AstaServerSocket1Encrypt(Sender: TObject; var S: String); var MyStream : TMemoryStream; begin MyStream := TMemoryStream.Create; MyStream := NewStringToStream(S) YourEncryptionRoutineHere(MyStream); S := StreamToString(MyStream); MyStream.Free; end;
|
Key |
Client |
Server |
| Properties | Compression | Compression |
| Methods |
- |
- |
| Events | OnCompress, OnDecompress | OnCompress, OnDecompress |
ASTA provides great flexibility for compression. In addition to giving you complete control over any compression library that you may wish to implement, ASTA ships with built-in compression that you can activate without writing a single line of code -- instant compression!
To enable the built-in compression simply set the AstaClientSocket and the AstaServerSocket's Compress property to "acAstaCompress" and recompile (you must recompile the server and the client, otherwise they will be out-of-synch).
If you wish to implement your third-party compression routines, or perhaps your own compression routines, you must use the OnCompress and OnDecompress event handlers. Your routines must be implemented on the Client and the Server. For further details, see the Encryption explanation, the OnCompress and OnDecompress event handlers are mirror the functionality of the OnEncrypt and OnDecrypt routines.
|
Key |
Client |
Server |
| Properties | AstaClientSocket.ApplicationName AstaClientSocket.ApplicationVersion |
- |
| Methods |
- |
AstaServerSocket.RegisterClientAutoUpdate |
| Events |
- |
AstaServerSocket.OnAstaClientUpdate |
ASTA provides you with the ability to automatically update AstaClients. Starting with ASTA v 1.91, if you have distributed 50 copies of an AstaClient as version 1.0, you can automatically update them by registering a later AstaClient version, say 1.1 or 2.0, at the server. When a user of version 1.0 logins into the server, he or she will be automatically updated to the latest version of your software. The following narrative describes how you can add AutoUpdate features to your ASTA projects.
When you create an AstaClient program, simply fill in the AstaClientSocket.ApplicationName and ApplicationVersion properties. For our example, lets call the our AstaClient program "MyClient" and assign "1.0" to the ApplicationVersion property and "MyClient" to the ApplicationName property.
Now you can distribute the application, confident that you can update it with ease.
When you have a new version of your software, you simply supply a later version number. If your first release went out as version 1.0, make your update 1.1 or 2.0.
After you compile the program, take the resulting executable file and copy it to the server. If your executable is MyClient.exe, you might want to call it MyClient11.exe so that you can differentiate it from future releases.
At the server, you simply need to call one method to register your new file. In the example below, I have added a TMenu to my AstaServer and I use a "Register Update Client" menu option to call RegisterClientAutoUpdate.
procedure TForm1.RegisterUpdateClient1Click(Sender:
TObject);
begin
AstaServerSocket1.RegisterClientAutoUpdate;
end;
At run time, you can simply register your new executable in the dialog box picture below.
When
In this dialog, which allows you to register your new executable
at the server, you must supply the ApplicatonName and the ApplicationVersion
property values that you have assigned to the AstaClientSocket object
in your project.
In this example, we supply:
MyClient and 1.1
The "Pick the path to the new client executable" button allows
you to specify the phyiscal file that you would like to distribute. In
this example, I renamed my file from MyClient.exe to MyClient11.exe so
that I can tell that it represents my 1.1 version. It is in the D:\Output
directory at the server.
Click OK to close the dialog.
That's all that you need to do. If a user logs into the server using a
version prior to 1.1, they will automatically get updated
to verion 1.1. At the client side, the original program will get named
xxxxxxx.exe.old and the new program will be named xxxxxx.exe. That will
preserve any shortcuts or conventions that have been setup at the client
side. In our example, the client will have two files after the update,
MyClient.exe.old and MyClient.exe. The former will represent the 1.0 release
and the latter will reprsent the new release. The "history"
trail is only one file deep. So if you release 2.0, then the 1.1 release
would become MyClient.exe.old and the 2.0 release would become MyClient.exe.
When the client logs in, a dialog box with a progress bar pops up. It informs them about the need for an update and then the progress bar tracks the status of the update.
If you wish to write a log or record the updates to a database, the AstaServerSocket provides an OnAstaClientUpdate event handler that allows you to record the UserName, ApplicationName and version numbers involved in the Update process:
procedure TForm1.AstaServerSocket1AstaClientUpdate(Sender:
TObject; UserName, AppName, OldVer, NewVer: String);
It should be noted a one megabyte file takes about five minutes to update
on a 28.8Kbps modem connection. It will only take about 5 or 10 seconds
on a LAN. Internally, we use a product called "Shrinker" to
compress our executables by about 40% - 50% and thereby speed up the update
process.
Download a Delphi version of an AutoUpdate Tutorial.
Special Notes
Be certain that you do not confuse your files. If you wish to update the 1.0 version with the 2.0 version, then be certain that the 2.0 version is the executable that you register at the server. If you accidentally register the 1.0 version, you will cause an infinite update loop!
TAstaServerDirectory |
TAstaClientDirectory |
TAstaOpenRemoteFile |
TAstaSaveRemoteFile |
|
Key |
Client |
Server |
| Properties | AstaClientDirectory.AstaClientSocket1 AstaOpenRemoteFile1.AstaClientDirectory1 AstaSaveRemoteFile1.AstaClientDirectory1 |
AstaServerSocket.DirectoryPublisher |
| Methods | AstaOpenRemoteFile1.Execute(AstaClientSocket1) AstaSaveRemoteFile1.Execute(AstaClientSocket1,MyStream) |
AstaServerSocket.PublishServerDirectories |
| Events |
- |
- |
The ASTA Remote Directory features allow you to "publish" a server directory. When a server publishes a directory, AstaClients can open files from and save files to that remote server directory. This is a convenient feature, but it has limitations and should be used with care. You should not publish a directory with thousands of files and dozens of subdirectories for performance reasons, and for security reasons you should not publish a root directory or other sensitive information. We recommend that you create a stand-alone directory dedicated to the sole task of publishing and accepting files.
Like many ASTA features, this one is a tandem implementation, you must coordinate actions on the Server and the Client sides or the feature will not operate properly.
To set up a server, you must drop a TAstaServerDirectory
object onto the server application. Then you . 
must assign the object to the AstaServerSocket.DirectoryPublisher property. Once that property is assigned, you can call the AstaServerSocket.PubishServerDirectories method -- in the sample project I added a menu that allows the user to configure the server at run time.
 |
The Server Directory Publisher dialog is
raised by the PublishServerDirectories method. This dialog allows
you to set several options; the directory, an alias name, and whether
or not you want the directory to be automatically published every
time the server starts up. In the example on the left, I have chose to publish the C:\eetemp directory. Since I don't want the users to know the actual name of the server directory, I used the alias TestFiles. Since this is a permanent feature of my application, I have selected the "Auto-Publish on Server Restart" checkbox. The information will be written to and automatically read from the registry automatically each time the server is started. |
| Now that the server side has been setup, you must attend to the client side. You need to add an AstaClientDirectory object to your form. The AstaClientDirectory.AstaClientSocket property should be assigned to the client's AstaClientSocket object. |  |
 |
Then add an AstaOpenRemoteFile and/or and AstaSaveRemoteFile object to your project. The AstaClientDirectory properties of these objects should be set to the AstaClientDirectory1 object that you just previously added to the form. These objects will retrieve files from and save files to the server directories that are "published" at the server. The execute methods of the AstaOpenRemoteFile and the AstaSaveRemoteFile objects call up a select file dialog with the server's "published" directories. |
Design-Time Security
|
Key |
Client |
Server |
| Properties | DTUserName DTPassword |
DTAccess DTUserName DTPassword |
| Methods |
- |
- |
| Events |
- |
- |
ASTA provides powerful design time features by
allowing a developer to access currently running AstaServers. This access
does not require a password, a convenience that allows you to have easy
access to your design time data without having to type in usernames and
passwords at every turn. But it also opens up a potential security hole.
Other ASTA developers, if they knew the IP Address and the Port of your
AstaServer, would be able to gain access to your database if they were
so inclined. One simple step that you can take to help avoid this problem
is to switch your AstaServers from the default Port of 9000 to a different
number above 1024.
To close the door completely, ASTA provides server-side and client-side
properties that allow you to control who accesses the servers at design
time. The AstaClientSocket and the AstaServerSocket both have DTUserName
and DTPassword properties. Those properties are controlled by the AstaServerSocket's
DTAccess property. DTAccess is defaulted to True. For maximum security,
you should set DTAccess to false and then assign matching UserName and
Passwords to the AstaClientSocket and AstaServerSocket DTUserName and
DTPassword properties. If you set DTAccess to False, you must provide
DTUserName and DTPassword values. Null values will not be accepted and
the client will be terminated.
