Using SQL Tables in Web Security

Description

SQL tables can be used with the web security tables through the use of active link tables. The web security code supports active link tables but does not actually use the active link table. Instead, it just creates appropriate SQL statements based on the table definitions and accesses the SQL tables directly. Therefore the speed running against SQL tables is approximately the same as against DBF tables and may actually be faster if there are a large number of users.

Alpha Anywhere will automatically generate the web security tables and create the Active Link tables necessary to store web security data in a SQL database.

Preparation

The security system requires four data tables. These must have a structure that is compatible with the web security. The SQL table names do not have to match the DBF table names, although they should be similar to allow easy identification. The SQL tables can have the exact same field names and structure or can have additional fields and different names. The DBF construction restricted field names to 10 characters. The SQL tables have no such restrictions, so more descriptive names could be used.

The field types must be compatible with the DBF types and meet the minimum lengths required. Unicode types may be used for the character fields, particularly for fields such as "SecQues" and SecAns" which may need Unicode support. All character fields can be variable length.

For example, the users table in DBF has a field named "guid" which is character and has a length of 36. A corresponding field in a SQL table (for example SQL Server) could be named "UserSecurityID" and be varchar(40). The DBF tables use logical fields which are not supported in all platforms. The corresponding SQL data type might be "bit" for SQL Server, or "tinyint( )" for MySQL where 0 = false and 1 = true.

DBF Data Types 

The DBF data types used are below with approximate equivalents:

Data Type
Description
C = Character

Typically replaced with varchar() or nvarchar(). Nvarchar() may be used if the users may use a language for a security answers that need supported by unicode.

L = Logical

Typically replaced with bit or tinyint

T = Time

Usually the same as datetime

SQL Tables to Create

User Table 

In the web security, the table is named "websecurity_users". A suggested name for the SQL table would be "Users". The table can be a member of any appropriate schema. This is the minimum construction required for the users security table.

Field NameDBF Data TypeLength
guidC36
UseridC100
PasswordC60
RememberMeL1
RedirPageC60
PassEntT17
PassExpT17
EmailC100
SecQuesC100
SecAnsC60
updwebT17
updlocalT17
ulinkC40

The "guid" or equivalent can be set as the primary key. Indexes may be created for "userid" and "ulink" if testing indicates a speed issue with large numbers of records. The expected automated process will add an index on "userid" as that is a common value used to find a user record.

Using 'ulink' as an external user identifier is no longer recommended. Prefer to use the 'userid' to link (foreign key reference) user data in other tables to the user table. 'ulink' corresponds to the "Enable external user identifier field" in the Security settings.
  • Non-Nullable Fields 

    Guid

    Userid

  • Defaults 

    (suggested, not required as the security system will add value)

    Guid =(replace(newid()),'-','')) - newid() is a SQL server function to create a standard guid (UUID) value. The field in the security table is misnamed as it contains a modified guid value with the hyphens removed.

Security Groups Table 

In the web security, the table is named "websecurity_groups".A suggested name for the SQL table would be "Groups". The table can be a member of any appropriate schema. This is the minimum construction required for the groups security table.

Field NameDBF Data TypeLength
Group_guidC36
Group_nameC60
updwebT17
updlocalT17

The "Group_guid" or equivalent can be set as the primary key. No other indexes should be needed.

  • Non-Nullable Fields 

    Group_guid

    Group_name

  • Defaults 

    (suggested, not required as the security system will add value)

    Group_guid =(replace(newid()),'-','')) - newid() is a SQL server function to create a standard guid (UUID) value. The field in the security table contains a modified guid value with the hyphens removed.

Security Members Table 

In the web security, the table is named "websecurity_members". A suggested name for the SQL table would be "Members". The table can be a member of any appropriate schema. This is the minimum construction required for the groups security table.

Field NameDBF Data TypeLength
Group_guidC36
User_guidC36
updwebT17
updlocalT17

"user_guid" is the field most often used for a search for records in this table. However, it is not unique and therefore not appropriate for a primary key. Another field could be added as an identity field for the primary key or a complex primary key could be created from user_guid + group_guid, which should be a unique value for each record. The expected automated process will add an index on "user_guid" as that is a common value used to find a user record.

Security Expired Table 

This table contains expired passwords and may or may not be used. It should be created anyway or an error will occur. In the web security, the table is named "websecurity_expired". A suggested name for the SQL table would be "Expired". The table can be a member of any appropriate schema. This is the minimum construction required for the expired security table.

Field NameDBF Data TypeLength
User_guidC36
PasswordC60
lastusedT17

This table has the same issues for creating a primary key and the complex expression user_guid + password should be unique. The expected automated process will add an index on "user_guid" as that is a common value used to find a user record.

No fields should allow nulls.

Foreign Keys 

No foreign key type constraints exist in the dbf format. However, an SQL format allows adding useful constraints. For example a foreign key can be added between members and users with the user "guid" as the parent.

Active Link Tables

After the SQL tables are constructed, active link tables can be defined. These must be named exactly the same as the dbf security tables and must be mapped to use the same field names as the dbf structure. The Alpha Five "Create Active-Link Tables" genie will create the tables in the database folder and not overwrite the existing security tables, which are in a web project folder.

The first step is to create a named connection to the SQL database that contains the new security tables. This may already exist.

Creating the User Table 

This is an example of the process to create a new active link user table. The same process can be used to build the other 3 tables. The example will use an actual table built in SQL Server as the source.

  • Step 1 - Open the genie 

    Open the Create Active-Link Table(s) genie.

  • Step 2 - Make the Connection 

    Enter the name of the connection to the new security tables.

  • Step 3 - Select table and Fields 

    Select the name of the table created to contain security information for users. In this example, the table is in the "Security" schema and named "Users". Select the fields that correspond to the required security fields. They may have different and more descriptive names. They will be changed in field definition overrides. There may be additional fields in the SQL table, but do not include them in this selection. After selecting the fields by checking them, select the button at the bottom "Override Field Definitions".

  • Step 4 - Override Field Definitions 

    The fields in the SQL table may have different types and names that required by the web security system. The override allows setting the properties of the active link table to match the structure of the original dbf tables.

    Select the field to edit, and double-click or press the button "Edit field definition". This opens a small genie to set new values.

  • In this case, the SQL table has a field named "UserSecID" which corresponds to the "guid" field in the dbf table. Therefore, the name must have an override to rename it as "guid".

  • In some cases, the data type may need changes as well. For example, a tinyint field may have been used in a MySQL table to correspond to the logical field "rememberme". The override for "rememberme" may need the Data type changed here to "logical".

    You should not have to change the width. If the width in the SQL table is longer than in the original dbf definition, that will not cause any issues.

    The goal is to have the override structure match the defined structure for the original dbf table as shown below. The data types must match the types used in the dbf, and the override name or default name must match the name in the dbf definition.

  • Step 5 - Set Optional Parameters 

    Strictly speaking, this is not necessary, but it is a good idea and the security code has a fallback option to actually use the active link table if a direct connection fails. Set the query location to "server-side".

  • Step 6 – Save the table 

    The saved table name must match the expected name for the original dbf structure. In the case of the users table, this must be "websecurity_users.dbf".

Other Tables 

Repeat the process above for the other 3 security tables, "websecurity_groups", "websecurity_members", and "websecurity_expired".

After construction, these files should exist in the database folder.

websecurity_expired.dbf 
websecurity_expired.dbP 
websecurity_expired.DDD 
websecurity_expired.DDM 
Websecurity_Expired.Ddx 
websecurity_groups.dbf 
websecurity_groups.dbP 
websecurity_groups.DDD 
websecurity_groups.DDM 
Websecurity_Groups.Ddx 
websecurity_members.dbf 
websecurity_members.dbP 
websecurity_members.DDD 
websecurity_members.DDM 
Websecurity_Members.Ddx 
websecurity_users.dbf 
websecurity_users.dbP
websecurity_users.DDD 
websecurity_users.DDM 
Websecurity_Users.Ddx

Migrating from DBF to SQL

If any existing security tables exist in the project folder, the data in those dbf tables can be moved to the new SQL tables by appending the data from each dbf table to the new active link table of the same name. It may be appropriate for an existing application to import the latest data to the desktop from a web server that contains the published web application. This will insure that the data added to the SQL database tables matches the data being used by the application.

The dbf table will be in the folder under the database folder named "\<database name>.WebProjects\<project name>.WebProject".

Go to the operations tab and select a new operation. In the left column, select "Append records". In the right column, select the web security table in the database folder as the target (master). The full path of any selection is shown below the windows, so you can see which table is selected. Use the append genie to find the "transaction table" or source. You can only see the full path of the table selected by actually selecting it, so you may get either the active link or original dbf on the first selection. The desired table is the original dbf, which is in the web projects folder.

Select append options that are appropriate. For example, both tables should have the same field names if the active link table was constructed properly. Since this append is typically only done once, you should select options to append all records, and probably should not save the append.

Repeat the append process to fill all of the active link versions of the tables. Although the appends are directed to the active link tables, the data will actually be saved in the source SQL database tables.

After all data has been appended, you can delete all of the "websecurity_" files from the web project folder. It is a good idea to create a backup before deletion. Then move all of the "websecurity_" files in the database folder (these are the active link versions) to the web project folder.

You can open the "users and groups" desktop form to verify the data is correct. The data being viewed is the data being retrieved from the SQL database. If the data is correct, you can publish the web security data tables to the deployed web server. The web server will then access the same data on the SQL database using the same connection. There is no data actually stored in the dbf for an active link table. All of the data is pulled from the SQL database as required.

If the active link tables use the same connection as a deployed web application, the local view from the desktop "Users and Groups" actually views the same data as the web server. Therefore any change made locally will immediately show on the web side. The reverse is true as well. If data is changed by the web application, the local view will see the change on the desktop genie as soon as it is opened.

All existing web security functions should work correctly with the active link table method.

See Also