1. Alpha Anywhere Forms
2. Alpha Anywhere Use Grid For New Record Only
3. Alpha Anywhere Release Notes

• Alpha Anywhere Updates The current Alpha Anywhere (Alpha Five Version 12) build is 72795546 (released on 01 DEC 2020 12:18 PM). Please note that Alpha Anywhere patches are only available to users with a current subscription. You can verify your subscription status from within Alpha Anywhere by going to Help, About, or by clicking this link.
• Licensing Alpha Anywhere Application Server for IIS. Once the Alpha Anywhere Application Server for IIS is installed you will need to set the license key. Open IIS Manager, select the server node and open the License Information feature. Enter your license key into the “License key” prompt and then click the apply link.
• Alpha Anywhere allows SaaS entrepreneurs and small businesses to bring new SaaS solutions to market faster. It lowers risk because there are no cost commitments until after you secure your first commercial deployment. Alpha Anywhere offers tiered hosting plans that scale easily, affordably, and reliably. App Templates for Industries.

Alpha Anywhere serves any IT or line of business developer tasked with building sophisticated, B2B or B2E web or mobile business apps. Alpha Anywhere is a comprehensive mobile app development platform that enables businesses to create business applications that are tailored to the mobile environment, their existing workflows, and other requirements.

• ProviderConfiguration

There are four extension points that Alpha Anywhere Application Server for IIS uses to handle authentication, authorization, session, and profile data. These are defined in ASP.NET as the following providers:

• MembershipProvider (Authentication)
• RoleProvider (Authorization)
• SessionStateProvider (Session)
• ProfileProvider (Profile)

These providers are configured in a web project profile settings that are used during publication. They use databases and/or other resources to fulfill their purpose. The web project settings create genie has a page for selecting the type of provider configuration your app uses.
There are three types:

• Active Directory
• Specific IIS Providers
• web.config (for testing only)

Users and groups may be defined by your application and may need to be published to a test, staging, or production database for use by the MembershipProvider and RoleProvider. This setting is also handled in this configuration and explained below.

The Active Directory option will only be available if you have configured the web application's security settings to use Active Directory. For details on configuring your application to use Active Directory for users and group see the Alpha Anywhere Application Server Active Directory Authentication and Authorization document.

The MembershipProvider and RoleProvider configuration is done through the Active Directory Configuration dialog in the Publishing An Application section in the document linked above. The session state and profile providers configuration are described in the Specific IIS Providers section below.

Provider Definition

Provider definitions can have different types of sources based on the selected provider. All providers have at least 4 types of sources:

• SqlServer
• MySQL
• Oracle
• Custom

The SqlServer, MySQL, and Oracle providers are version specific. The versions that are selectable are based on the installed assemblies for the provider. SqlServer's version is fixed at 2.0.0.0 and is already installed as part of ASP.NET. MySQL requires a version of the MySQL Connector/NET to be installed. If none is installed Alpha Anywhere Developer Edition can install version 6.7.4. Oracle requires a version of the Oracle Data Access Components to be installed. The packages for MySQL and Oracle also need to be installed on the IIS server. Alpha Anywhere Application Server for IIS includes a utility for installing MySql Connector/NET 6.7.4: A5InstallMySqlConnector.exe. This utility is located in the installation folder which defaults to C:Program Files (x86)A5V12 Application Server for IIS.

Require Client Certificates

A client certificate (also known as PKI authentication) is a way a user can be authenticated instead of using a login page with username and password prompts. This advanced feature is available for all 'Specific IIS Providers' types.

A client certificate is issued by a certificate authority just like a server certificate. Whereas a server certificate validates the identity of a server, a client certificate validates the identity of a client e.g. user. When Require Client Certificates is enabled, the server will request that the client sends a client certificate with its request. The server will validate the client certificate as being issued by the stated certificate authority, is within the issued start and end date, and is not revoked. Once the certificate is valid the user is authenticated. The email address for that user is extracted from the certificate and that email address is used to authorize the user's access to pages. The email address can be located either in the subject field or in the subject alternative name field.

Developing an application to use client certificates is the same as developing an application to use a login page with username and password prompts. The only special consideration that needs to be made is that user names must be an email address since an email address will be extracted from the client certificate to identify the user in the application.

An application can add a new user and assign that user to groups using Context.Security() methods in an 'Administrator' level access pages as is typically done in Alpha Anywhere applications.

Using Require Client Certificates

Alpha Anywhere Forms

The publish profile defines whether or not a client certificate is required or not. However, a user and group assignments for that user must exist in the security tables before that user can be authenticated and authorized in the application. This is the same whether the user is authenticated with a username and password or with a client certificate. So the membership and role providers must first be defined as would be done when using usernames and passwords.

The option to require client certificates is located on the 'Advanced Settings...' dialog of the Membership tab of the Security Store configuration page of the new publishing profile Genie.

The option is also available in the publish profile property sheet in the membership provider group:

Checking this option will configure the IIS site to require client certificates and will also disable anonymous authentication. When anonymous authentication is disabled no page for file can be accessed without a client client certificate.

After the application has been published with this setting, the browser will prompt the user for a client certificate to be sent to the server when a page is requested.

Role, Session State, and Profile

The Role, Session State, and Profile providers can all use the same provider definition as the Membership provider. They have the additional option of:

• SameAsMembershipProvider

The Session State provider has 3 additional options specific to it:

• LocalStateServer
• StateServer
• Redis

The Profile provider has one additional option specific to it:

• None

The default source for Role, Session State, and Profile providers is SameAsMembershipProvider.

The following sections define the configuration settings for each source type.

SqlServer

The SqlServer type uses the Microsoft SqlServer providers. These providers require a connection string to a database, and, except for the session state provider, a security application name. Additionally, you may want to publish users and groups through the membership and role providers. If you need to do this and the provider connection string does not have create/update access you can define a connection string to be used at publish time that has create/update access in the Create/Publish Connection String prompt. When the web profile is saved an attempt will be made to validate the database is set up for use by the provider. If the database cannot be found or parts of the schema are missing you will be prompted to create and/or initialized the database.

MySQL

The MySQL type is like the Sql Server type, but instead of validating the chosen database when the web profile is saved the MySQL type has an option for 'Automatically generate and update schema' that can be selected. When this option is selected the MySQL provider will automatically generate or update the database schema when any of the providers are used. This built-in type uses MySQL .NET Connector 6.7.4.0. There is a utility named A5InstallMySQLConnector.exe that is packaged with Alpha Anywhere Developer Edition and Alpha Anywhere Application Server for IIS. Use it to install the MySQL .NET Connector 6.7.4.0 assemblies on an IIS server and register the assemblies in the GAC. This utility will also be used by Alpha Anywhere Developer Edition if needed when publishing users and roles of a web application.

Oracle

The Oracle type does not generate the required schema. This must be done manually using the utilities installed with the Oracle Data Access Components 12c Release 3 (Release 12.1.0.2.1 for ODAC 12c Release 3). The version of the assemblies that get installed are 2.121.2.0.

Custom

A custom provider configuration has 1 required setting: The provider class name. This is the assembly qualified name of the class that implements the required provider interface. The assembly the class is in must be in the Global Assembly Cache on the server. It should also be installed on your development machine so that it can be used to populate its storage if needed as in the case of the membership or role providers. It is installed on your development machine you will also be able to choose it from the Select Provider Class dialog. The provider class usually has one or more parameters that can be set to configure how the provider should work. For instance, a membership provider may limit the number of failed password attempts. This value default to a number, but can be configured through a parameter. The 'Edit provider parameters' button brings up a dialog for adding this parameters. Once a provider class is selected the parameters dialog will be pre-filled with the provider's public properties. Parameters can be removed, added, and changed as needed. If a provider class is not selected before using the 'Edit provider parameters' dialog the list of parameters will be empty. The name of the provider class is displayed under the parameters list. See the Custom Provider Configuration document for an example of using Oracle as a customer provider.

SameAsMembershipProvider

This source type for role, session State, and profile providers uses the same configuration that is defined for the membership provider. The same provider connection string, application name, and create/publish connection string will be used. This means all role, session state and profile data will be stored in the same database.

LocalStateServer

IIS is installed with an out of process state server named aspnet_state.exe. This is a Windows service. This service is set to manual start up by default. The Alpha Anywhere Application Server for IIS installation program sets this service to automatic start-up and ensures that it is running. The LocalStateServer setting will have IIS use this service for storing session state.

Redis

Redis is a free, distributable, in-memory database with a backing store and is the preferred session state provider when using IIS behind a load balancer. Session state under Redis is stored and accessed on a separate machine, allowing you to setup a web farm. Redis keeps data in-memory and only writes to disk as-needed.

Redis has built-in support for replication and can be run in a cluster. This ensures sessions are more reliable, allowing for failures such as server becoming unresponsive or loss of connectivity to a server with minimal service interruptions to the user.

When configuring Redis, the service should be setup to restrict port access and use an Access key. Using SSL is also recommended. See Appedix A: Configuring Redis for more details.

StateServer

This is similar to LocalStateServer. An aspnet_state.exe service is running on a remote machine and IIS will connect to that for storing session state. StateServer is also similar to Redis in that session state is stored/accessed on a separate machine which will allow you to set up a web farm. That is, allow you to have more than one web server process request for a single web site. Each web server will point to the same session state data. However, the aspnet_state.exe service only stores session state in memory so if the aspnet_state.exe service is shut down or crashes the session state data cannot be recovered. The amount of session state that it can handle is also restricted to the amount of memory on the system. Virtual memory means that running out of memory is unlikely, but performance will degrade as physical memory is exceeded.

None

The profile provider allows you to store persistent data for a logged in user. This is different from the Session State which is only persistent for the session lifetime. If your web application does not need user profile data or already manages user profile data in a different way, use None for the Profile provider source.

The web.config option is only appropriate for testing or proof-of-concepts where only a demonstration of users and groups is needed. The users and groups data is stored in the web application's web.config file which is only moderately secure, does not scale well, and is not easy to maintain. This option only has a pre-set configuration.

Security data (users and groups) for your application can be published to the security store that your membership and role providers use when your security store type is Specific IIS Providers. Alpha Anywhere has six different modes for publishing security data:

• Preserve - Publish only if no users and roles are found in the destination. Both the user store and the role store must be empty for anything to get published. For example, if there is 1 user and no roles nothing (neither user nor roles) will get published because that one user already exists.
• Ignore - Do not publish users or roles.
• Merge - Add new users and roles. Any users and roles that don't exist in the store will be added. Existing users and roles remain unchanged.
• Replace - Replace all users and roles. Any existing users and roles are removed user and role store and then the users and roles defined in the web project are added to the users and roles store.
• Merge Roles - Add new roles. Any new roles defined in the web project are added to the role store.
• Replace Roles - Replace all roles. All roles are delete from the role store and then the roles defined in the web project are added to the roles store. Note: If a role of the same name as a role that was deleted will be re-associated with any users that were members of the original role.

This option is set at the bottom of the genie dialog and it defaults Preserve.

The value you select is the default value used at publish time in the Publish Web Project dialog and the Publish Security Files dialog located in the Web Security dialog.

Once a profile is saved, the provider configuration can be modified in the Miscellaneous section of the property grid for that profile.

This example uses a remote SqlServer Express database for membership, role, and session state. This example does not use a profile provider. A new database for membership, roles, and session state will be created and initialized. The SqlServer Express server instance already has a login defined for 'AspNetDb_Test_User'. This login will be added as a user in the new database, it will be given access to the database, and will be used in the provider connection string. I will use my domain account, which has sysadmin access, and integrated authentication for the create/publish connection string.

If you already have a web project profile for publishing the App Server Demo web application to an IIS server, you can use the 'Duplicate Profile' button and then make changes to the new copy of the profile following these steps below. If you haven't created a web project profile for publishing the App Server Demo web application to an IIS server follow these instructions for creating a new profile.

Using a remote SqlServer Express instance when editing a duplicated profile

If you have already created a Web Project Profile by following the Getting Started Guide instructions, you can duplicate this profile and then change the provider configuration for the duplicate profile.

After you have duplicated the profile scroll down to the bottom of the property grid to get to the Security Store Type combobox. It will be set to 'web.config (for testing only)' since that was the only type available in earlier versions.

1. Change the Security Store Type to 'Specific IIS Providers'. This will reveal the rest of the configuration settings.

2. Click on the Membership Provider Connection String's '...' button to create a connection string. Enter your server name then enter 'AspNetDb_Test_User' in the user prompt and enter the password for that user. (Or use an existing SqlServer user.)

   This example creates a new database. Since this user does not have access to create a database you cannot create the database from this dialog. If you want to test the connection make sure that the database name is blank so that the Test Connection won't attempt to connect to a database that doesn't exist yet. Once you have tested the connection enter 'AspNetDb_Test' into the Database prompt and then click OK to save the connection string.

3. Back in the property grid, leave the Membership Provider Application Name value set to '/'.

4. Click the 'Use a Different Connection String for Membership Provider Create/Publish' to check it.

5. Click on the Membership Provider Create/Publish Connection String's '...' button to create a connection string. It will default to the provider connection string.

6. Click on the Use Windows Authentication check-box and then OK to save the connection string. If you are not using Windows authentication enter the credentials for a user with permission to create databases such as the 'sa' user.

   Click OK to save the connection string.

7. Back in the property grid, skip the Role Provider Type and Session State Provider Type prompts leaving them set to SameAsMembershipProvider. Change the Profile Provider Type to 'None'.

8. Click OK to save the changes to the profile. Since the database doesn't exist yet you will be prompted to create and initialize the database.

9. Now you can publish using this new profile. See the Publish Web Project dialog to do this.

Using a remote SqlServer Express instance when creating a new profile

This example will revise the steps in the Application Server Demo publish example in the Alpha Anywhere Application Server for IIS Getting Started Guide. That example uses the 'web.config (for testing only)' option. 'web.config' was the only option before this provider configuration UI was implemented. Follow all the steps in the Getting Started Guide until you get to the Security Store Configuration genie page. Once you have completed the security store configuration steps, continue with the Getting Started Guide finishing the steps for publishing Application Server Demo web application.

Security Store Configuration Genie Page

1. Click on the smart button to bring up the Create SQL Connection String dialog.

2. Enter your server name, 'AspNetDb_Test_User' in the user prompt and then the password for that user. (Or use an existing SqlServer user.)

3. This example creates a new database. Since this user does not have access to create a database you cannot create the database from this dialog. If you want to test the connection make sure that the database name is blank so that the Test Connection won't attempt to connect to a database that doesn't exist yet. Once you have tested the connection enter 'AspNetDb_Test' into the Database prompt.

4. Click OK to create the connection string.

5. Back on the Genie page, leave the default value of '/' in the Security application name prompt.

6. Click on the 'Advanced Settings...' button

7. Click on the 'Use a different connection string for publishing security data.' This will copy the provider connection string into the Create/Publish connection string prompt. Click on the smart button to bring up the Create SQL Connection String dialog.

8. Click on the Use Windows Authentication check-box and then OK to save the connection string. If you are not using Windows authentication enter the credentials for a user with permission to create databases such as the 'sa' user.

9. When the connection string is saved the database schema will be validated. Since the database doesn't exist yet you will be prompted to create and initialize it.

10. For the Role and Session State tabs keep the source set to 'SameAsMembershipProvider'. For the Profile tab, change the source to None.

11. Since the role provider and session state provider use the 'SameAsMembershipProvider' source, the database schema for the role and session state provider won't be validated until the profile is saved. You will get the following 2 prompts:

12. Now you can continue with the rest of the instructions in the Getting Started Guide for publishing the App Server Demo web application to an IIS server.

Appendix A: Configuring Redis

In order to use Redis as a session state provider, you must setup Redis on your server. If you don't have Redis installed as a service, or running on another machine, the easiest way to get started is to open a command window, change directory to the A5v12 executable folder and run redis-server.exe.

In a production environment, Redis should be configured to restrict port access to trusted clients. Redis should also be configured to use SSL if Reids is outside the firewall. For information on how to configure Redis securely, visit the following resources:

• Redis configuration - Includes a link to a self documented example redis.config file that can be used to configure Redis
• Redis Security - Check out the sections on 'Network security', 'Authentication feature', and 'Data encryption support'.

Welcome to Alpha Anywhere, the Rapid Application Development platform for building and deploying mobile, web, and desktop business applications. This Getting Started section is aimed at people who are new to Alpha Anywhere. It provides a high-level overview of the Alpha Anywhere platform and its key features. It also features several Getting Started Tutorials that provide detailed step-by-step instructions for building your first mobile or web application.

What is Alpha Anywhere?

Alpha Anywhere is a platform for developers of varying skill sets to create and deploy business applications for mobile devices and desktop/web. The platform has two parts, a developer for building applications and a server for deploying them. Applications can either be run in a web browser or they can be installed as an application on a mobile device. For more details and a video, see the Alpha Anywhere Technical Overview page.

What are the Key Features?

Alpha Anywhere has a deep feature set for all aspects of application development, including data integration, offline support, cross-platform support, reporting, touch screen and rich data support, security, and much more.

Data Integration

Alpha Anywhere applications can perform CRUD (create, read, update, delete) operations from virtually any data source, including SQL-type databases, NoSQL databases, and web services. For details, see the Data Integration page.

Offline Support With Synchronization

Alpha Anywhere includes technology that allows applications to work in an offline/disconnected mode. When a connection is restored, the data that is entered is synched to a server. Applications can also store downloaded data for offline use that can be edited while offline. In cases of conflict, where a record is changed by two or more users, Alpha provides a system to intelligently manage conflicts. For details, see the Offline Data Capture and Synchronization page.

Cross Platform / Cross Device Support

Because Alpha Anywhere builds HTML5/JavaScript applications, they can be run on practically any device that has a web browser, including desktop and laptop Mac/PCs, smart phones, and tablets. On mobile devices, Alpha Anywhere applications can be installed as native applications and can access the the devices' hardware. For more details see the Technical Overview page.

Reporting

Alpha Anywhere includes a banded report-writer that can create sophisticated reports from a variety of data sources. The reports can be generated as PDF, HTML, Excel files and in other formats. Reports can be displayed on screen, in an application, or they can be automatically emailed. Alpha Anywhere can also run reports built using Microsoft's SQL Server Reporting Services. For more information, click here.

Rich User Experience

Alpha Anywhere supports very rich user interfaces for both desktop/mobile and web applications. Applications can include maps, charts, gauges, and special controls. There are also ink controls for drawing on a touch screen, image annotation for making notes on pictures, a signature capture control, and support for all audio and video.

Alpha Anywhere Use Grid For New Record Only

Security

Alpha Anywhere includes a role-based security framework, encryption functions, SSL support, and can use the security features built into IIS and the .NET framework. For details, see the Security Section on the main Alpha Anywhere website.

Learning to Use Alpha Anywhere

When you are ready to dive in and starting using Alpha Anywhere, start with our Getting Started Tutorials. The Getting Started Tutorials will guide you through the process of building a mobile or web application that is ready to be deployed. Choose the type of application - mobile or web - and Get Started.

Related Links:

Alpha Anywhere Release Notes