The Alpha Anywhere web security system now supports login using credentials for a social network such as Google or Facebook. This gives the user multiple ways to log into an Alpha Anywhere application.
A user can now log in to an Alpha Anywhere application using either:
NOTE: The ability to log in to an application using social network credentials will only be available if the Allow Alternative Login property is checked when configuring the Web Security Settings.
Alpha Anywhere currently supports the following social networks that provide user authentication.
NOTE: The login using social network credentials feature
(i.e. the 'alternative' login feature) can only be used in conjunction with the the built- in Alpha Anywhere web security system.
You cannot use this feature if you are not using the Alpha Anywhere web
security system. That's because the 'alternative' login is simply an alternative
means for logging into an account in the Alpha Anywhere security system.
As a convenience, the security system exposes a feature that can automatically
create a new account in the security system if a user logs in with social
network credentials and no matching account is found in the security system.
WARNING: If you enable the 'Alternative Login' feature then you should set the table type for your web security tables to 'SQL'. Do not use .dbf tables for your security tables.
When using the 'alternative login' feature, the Alpha web security system is still used and the user must have an account in the Alpha Anywhere web security system. Once they are authenticated and logged in, the security system will use the permissions and information defined in the Alpha web security account.
There are options to create a new account for an authenticated user if they don’t already have an account in the security framework, and to add the alternative login to an existing web security account.
The alternative authentication methods are currently only available in Action Scripting in the UX component.
When a user elects to use an alternative login, they will be redirected to a page managed by the provider. If the login is successful, the system will look for an existing account in the Alpha Anywhere web security system that is associated with that login. If one is found, they will be logged in automatically with the permissions defined for the account.
If they don’t have an associated account in the Alpha Anywhere web security system, a new account can be created automatically. The new account associated with an alternative authentication will use the user identification supplied by the provider (normally an e-mail address) and attempt to create a userid based on that identifier that meets the validation rules in the web security system.
A new user added by the alternative login process will initially not have a password in the Alpha Anywhere web security system, although one can be added at a later date. The new account will use the permissions allowed by the default security group if one was defined in the security settings.
After the login is successful or cancelled, the original page that contained the UX will do a full page reload. The user may be redirected to another page if a URL is defined in the After Login Event in the security settings.
Video 1 - Setting up the Providers
Video 2 - Creating Named Providers
Video 3 - Configuring Web Security
Video 4 - Adding Alternative Login to a UX Component
Video 4 - Testing Alternative Login
A developer project must be set up in each social network that will be used for user authentication. The developer must have an account with that network to be able to set up a project. The project provides special project credentials used by Alpha Anywhere to connect to the social network. These normally include some special keys such as a client id, also sometimes referred to as an application or app id, and a secret key. Most providers also require setting one or more URIs to use as an allowed redirect URI after login. Each Alpha Anywhere application will normally have a different redirect URI.
The developer may elect to use the same provider project for both the development system and a deployed application, or they may create a separate project for every published location. Alpha Anywhere provides a method to change the provider credentials at publish time.
The project name should be descriptive and "friendly" as it will be shown to the user on their sign on screen. It can be the name used to describe the Alpha Anywhere application.
There are notable differences between providers. For example, most providers allow multiple redirect URI addresses in a project. Twitter currently only allows one, so each published location will need a unique Twitter project. Some providers will not allow a URI that cannot be tested by their system and may reject a URI containing "Localhost", or a server name on a local network. it may be necessary to use an IP address in a redirect URL such as 127.0.0.1 in place of "localhost" when testing the system locally.
Here are some links to the provider project sites. They all include documentation on the projects as well as how to create logins, etc. Alpha Anywhere has done all of the hard work, so you only need to set up a project. To access these project sites, you will be required to log into the desired social network.
https://console.developers.google.com/project
Go to the credentials menu option to get the desired keys. You will need the client Id and Client secret to configure the resource in Alpha Anywhere. Either initially leave the redirect URIs section blank or put in a placeholder URI such as http://MyApp/index.a5w to be able to save the settings.
https://developers.facebook.com/apps/
Use 'Create a new app' to build a new application, or edit any application shown. Go to the settings menu option. The basic tab will show the App ID and secret, which will both be needed in Alpha Anywhere. The redirect URI and other options can be configured on the Advanced tab. The Valid OAuth redirect URIs can initially be left blank, and one or more URIs added later. You must set Client OAuth Login to true. It is suggested that you also set App Secret Proof for Server API calls to true. This setting is supported in Alpha Anywhere.
By default, a Facebook application is initially in development mode and only users listed as administrators, developers, or testers can use the authentication. The application must be made public to allow any user with a valid Facebook account to log in. Follow these steps to make the application public.
Use 'Create a new app' to build a new application, or edit any application shown. Go to the settings menu option. Note that Twitter only allows one Callback URL (redirect URL). Some URL may be rejected , such as "localhost". In that case, use 127.0.0.1 as the server address if testing on local host. Check the option to allow the application to be used to Sign in with Twitter. Go to the API keys tab and obtain the API key and secret. They will be needed in Alpha Anywhere.
https://www.linkedin.com/secure/developer
If you are asked to log into Linkedin from the address above, you may be directed to your profile home page. In that case, use the above link again to get to the developer network. Use add a new application to build a new application, or edit any application shown. Linkedin may show multiple authentication methods. Alpha Anywhere uses OAuth 2.0. Record the API key and Secret Key as they will be needed in Alpha Anywhere. The redirect URLs can be left blank. The default scopes should include r_emailaddress and r_basicprofile.
Live Connect
https://account.live.com/developers/applications
Use 'Create application' to build a new application, or edit any application shown. Click on the application name to open the information page. Click 'edit settings' to edit the settings. The Root domain is set in API Settings and must be a domain accessible from the internet. It cannot be 'locallhost' or an IP addrress of a local machine. You can enter multiple redirect URLs. You will need the client Id and Client secret from the App Settings to configure the resource in Alpha Anywhere.
See the next step on how to get the redirect URLs that are appropriate for a particular web project. The provider project accounts above must be reopened and the correct redirect URL entered when it is available.
Once the desired projects are defined, and the appropriate keys and secret keys are recorded, Alpha Anywhere can be configured to connect to the projects. This is done in the Web Project Properties by setting up "Named Providers". All published instances of the project use the same named providers, although the actual connection keys used by a named provider can be changed at publish
time to point to a different project on the social network.
Click on the smart button on the right to open the genie to create Named Resources.
This will show a list of defined named resources, allow editing any resources, and adding new ones. It is permitted to have more than one Named Resource for a provider, but not currently recommended. Select Edit or New to open the window to add the credentials recorded in Step 1 from the provider. Select the provider for this resource and enter the appropriate key values.
The genie has a link to open another window that shows possible redirect URL values for the local host system. You can select one and copy it to the clipboard. This redirect URL MUST be placed in the appropriate section in each developer project following the links and instructions in the Step 1.
NOTE: The redirect URL may be case sensitive for some providers. For example, http://MyApp may be interpreted differently than http://myapp. Be sure to incliude all possible spellings for the URI addresses when they are entered in the developer project for the provider.
Security Settings Options - There are a number of options that can be set in the Security Settings.
The security settings also have an option to set a default security group. This group will be added to a new account added by alternative authentication.
Actions Available in Action JavaScript - The UX component has a number of actions available in Action Scripting to support alternative logins. These actions can be added to a button, a hyperlink, or an image. These actions can only be added if Alternative Authentication is allowed.
Other Characteristics - The alternative login uses some of the existing actions and properties of the UX component.
Adding a Login - The alternative login can be added to any UX component. The integrated login functionality does NOT need to be selected to add the login. The properties in the UX Login section have an option to select 'Has integrated alternative login functionality' if 'Allow Alternative Login' is set in the security settings for the project. The properties to add a placeholder for errors and the option to customize login failure messages will be shown if either 'Has integrated login functionality' or 'Has integrated alternative login functionality' is checked. If a placeholder control is not defined, any errors will show in a pop-up window.
Add a button, hyperlink or image to the UX for the alternative login. Images for Google can be found at:
https://developers.google.com/+/branding-guidelines
Other providers can supply button images from their developer sites.
Select the JavaScript click or onClick events for the control, and use Add New Action to select the action 'Login with Alternative Login Provider'. Select the named provider desired and save the Action.
Other login controls can be added to the UX but are optional and only required if login with a userid and password will be supported.
A new user added by alternative authentication will initially use the default security group defined in the security properties.
The alternative login process will reload the original page that contained the UX component after The code in the security system 'After Login Event' will run after a successful login using an alternative provider.
Adding Alternative login to an Existing User - The user may have logged in using a userid and password (i.e. the credentials for their account in the Alpha Anywhere security system) and desire to associate a social network login (e.g. a Google login) with their account. A UX component can be used to add an Alternative Authentication to any user currently logged into the system. This component should be on a page or panel only accessible after a user is logged into the system.
Add a button, hyperlink or image to the UX for the action. Select the JavaScript click or onClick events for the control, and use Add New Action to select the action 'Add Alternative Login to Current User'. Select the named provider desired and save the Action.
Editing Users After They Have Been Added - The alternative login uses the existing web security system and tables. Therefore any method used to edit users in the web security system can be used to edit users who have alterative logins. If a user has an alternative login, a password is not required when the record is edited, although one could be added is the user will be allowed to login with a regular login form.
The alternative logins for the current logged in user can be shown in a list control or similar control. A list of alternative logins for the current user can be found using the xbasic function a5ws_GetAltLoginListForCurrentUser(). This function will return a list of alternative logins in the format 'Provider - User identifier in provider'. Typically, the user identifier in the provider is an e-mail address.
An Action JavaScript action will allow removing an Alternative Login. Add a button, hyperlink or image to the UX for the action. Select the JavaScript click or onClick events for the control, and use Add New Action to select the action 'Delete Alternative Login to Current User'. Select the control that has the list of records. An alternative authentication can only be deleted if there is more than one listed, or the user has a password defined for their login.
A published project can use the same provider project as the development system except in the case where the provider only allows a single redirect URL. The publish profile genie allows using a different provider project with different keys. The named resource name does not change. The option is not available in the Local Webroot profile as it will use the credentials defined in the development project. All other publish profiles include an option to edit "Named Resource Providers".
This option opens a genie that is similar to the genie used in Web Project Properties. However, a project can not be added or deleted. The redirect URL shows possible redirect URLs based on the defined Base URL in the publish profile. The edit option allows changing the key and secret key to point to a different provider project