Features

Labels
AJAX(112) App Studio(8) Apple(1) Application Builder(245) Application Factory(207) ASP.NET(95) ASP.NET 3.5(45) ASP.NET Code Generator(72) ASP.NET Membership(28) Azure(18) Barcode(2) Barcodes(3) BLOB(18) Business Rules(1) Business Rules/Logic(140) BYOD(13) Caching(2) Calendar(5) Charts(29) Cloud(14) Cloud On Time(2) Cloud On Time for Windows 7(2) Code Generator(54) Collaboration(11) command line(1) Conflict Detection(1) Content Management System(12) COT Tools for Excel(26) CRUD(1) Custom Actions(1) Data Aquarium Framework(122) Data Sheet(9) Data Sources(22) Database Lookups(50) Deployment(22) Designer(177) Device(1) DotNetNuke(12) EASE(20) Email(6) Features(101) Firebird(1) Form Builder(14) Globalization and Localization(6) How To(1) Hypermedia(2) Inline Editing(1) Installation(5) JavaScript(20) Kiosk(1) Low Code(3) Mac(1) Many-To-Many(4) Maps(6) Master/Detail(36) Microservices(4) Mobile(63) Mode Builder(3) Model Builder(3) MySQL(10) Native Apps(5) News(18) OAuth(9) OAuth Scopes(1) OAuth2(13) Offline(20) Offline Apps(4) Offline Sync(5) Oracle(11) PKCE(2) Postgre SQL(1) PostgreSQL(2) PWA(2) QR codes(2) Rapid Application Development(5) Reading Pane(2) Release Notes(184) Reports(48) REST(29) RESTful(29) RESTful Workshop(15) RFID tags(1) SaaS(7) Security(81) SharePoint(12) SPA(6) SQL Anywhere(3) SQL Server(26) SSO(1) Stored Procedure(4) Teamwork(15) Tips and Tricks(87) Tools for Excel(2) Touch UI(93) Transactions(5) Tutorials(183) Universal Windows Platform(3) User Interface(338) Video Tutorial(37) Web 2.0(100) Web App Generator(101) Web Application Generator(607) Web Form Builder(40) Web.Config(9) Workflow(28)
Archive
Blog
Features
Monday, January 2, 2017PrintSubscribe
Authenticating Users with Windows Live

Every application requires a list of user accounts that have been granted (or denied) access to the data. In order to maintain membership consistency, every user needs to be associated with a password. Recommended practices for passwords dictate that every password must be unique, contain a long series of mixed alphanumeric characters, and that users should change their passwords regularly. It is likely that many users do not follow these recommended practices, and tend to reuse simple and easy to remember passwords across various systems. This can lead to a security issue if one of the systems becomes compromised – malicious users can then gain access to all systems that share the same password.

In an attempt to solve solutions to the problems mentioned above, authentication can be delegated to a “higher authority”. Application admins can register their app to accept responses from a federated authentication server. When a new user attempts to sign up to the application, they can choose to register an account using their federated account. They will be redirected to the authentication server’s login page, and grant permission for the app to gain access to their email. This information is then used to automatically create an account in the app and sign them in. Therefore, the user simply has to ensure that their account in the federated system is secure.

Applications created with Code On Time can use OAuth 2.0 to register their users. Simply define a resource under the Content Management System (CMS) that lists your client ID, client secret, and redirect URI. A local redirect URI can be defined for testing purposes.

Registering Your App

The first step to enable Windows Live authentication is to register your app.

Navigate to https://apps.dev.microsoft.com. In the top-right corner, press “Add an App”. Enter a name for your app and press “Create Application”.

Adding an application to Windows Live.

Under the “Application Secrets” section, press “Generate New Password”.

Generating a new password for the application.

Make sure to copy the new secret.

Next, press “Add Platform” under the “Platforms” section. Select “Web”.

Adding a platform for the app.

Enter your application URI, with the path “/appservices/saas/windowslive”. Optionally add a local URI for testing purposes.

Adding redirect URI for the app.

Scroll to the bottom of the page, and press “Save”.

Enabling Windows Live Login in the App

The connection needs to be registered in your application. Navigate to the Site Content page of your app, and create a new record with the following settings:

Property Value
File Name windowslive
Path sys/saas
Text

Client Id:
1234567890

Client Secret:
12345mysecret67890

Redirect Uri:  
https://demo.codeontime.com/appservices/saas/windowslive

Local Redirect Uri:
http://localhost:31733/appservices/saas/windowslive

Make sure to change the Text to the correct values for your app.

Logging In with Windows Live

Log out of your app, and press Login to open the login form. The “LOGIN WITH WINDOWS LIVE” action will now be displayed.

The login form now displays a button to "LOGIN WITH WINDOWS LIVE".

Press “LOGIN WITH WINDOWS LIVE”, and you will be redirected to the Windows Live login screen. Once logged in, a permission request will be displayed.

Windows Live displays a permission request - the app is requesting access to the profile's email.

Press “Yes”, and your browser will be redirected back to the app. The app will attempt to sign in with the account matching the returned email. If no account is found, then an account will be created with the email as the username, and a random GUID assigned to the password and password answer.

Monday, January 2, 2017PrintSubscribe
Authenticating Users With Facebook

Every application requires a list of user accounts that have been granted (or denied) access to the data. In order to maintain membership consistency, every user needs to be associated with a password. Recommended practices for passwords dictate that every password must be unique, contain a long series of mixed alphanumeric characters, and that users should change their passwords regularly. It is likely that many users do not follow these recommended practices, and tend to reuse simple and easy to remember passwords across various systems. This can lead to a security issue if one of the systems becomes compromised – malicious users can then gain access to all systems that share the same password.

In an attempt to solve solutions to the problems mentioned above, authentication can be delegated to a “higher authority”. Application admins can register their app to accept responses from a federated authentication server. When a new user attempts to sign up to the application, they can choose to register an account using their federated account. They will be redirected to the authentication server’s login page, and grant permission for the app to gain access to their email. This information is then used to automatically create an account in the app and sign them in. Therefore, the user simply has to ensure that their account in the federated system is secure.

Applications created with Code On Time can use OAuth 2.0 to register their users. Simply define a resource under the Content Management System (CMS) that lists your client ID, client secret, and redirect URI. A local redirect URI can be defined for testing purposes.

Registering Your App With Facebook

The first step to configuring Facebook Login is to register your app with Facebook. Navigate to https://developers.facebook.com. In the top-right corner, hover over “My Apps” and press “Add a New App”.

Creating a new app in the Facebook Developers website.

Specify a Display Name, Contact Email, and Category, and press “Create App ID”.

On the “Add Product” screen, press “Get Started” next to “Facebook Login”.

Getting started with Facebook Login.

Under “Valid OAuth redirect URIs”, add a URI for your app URL, with the path “/appservices/saas/facebook”. It is recommended to add a test redirect URI when running the app locally on your PC.

Configuring OAuth for the application.

Next, press “Dashboard” section on the navbar on the left side of the screen. Take note of the App ID and App Secret values.

Finding the App ID and App Secrets.

Enabling Facebook Authentication in your App

Navigate to your website, and navigate to your Site Content page. Create a new record with the following properties:

Property Value
File Name facebook
Path sys/saas
Text

Client Id:
1234567890

Client Secret:
12345mysecret67890

Redirect Uri:  
https://demo.codeontime.com/appservices/saas/facebook

Local Redirect Uri:
http://localhost:30195/appservices/saas/facebook

Make sure to replace the values in the “Text” property with the correct values for your app. Save the new record, and log out of the app.

Logging In With Facebook

On the login screen, the “LOGIN WITH FACEBOOK” action will now be displayed at the top of the form.

Logging in with Facebook from the Login screen

Press the “LOGIN WITH FACEBOOK” button, and the app will redirect to authenticate with Facebook. Once signed in, it will display a permissions popup.

Facebook is requesting the user to grant access to the application.

Press “Continue as XXX” button to grant access to your profile and email address for that app. It will redirect back to your app and attempt to log in as a user with that email. If the user does not exist, it will be created. The password and password answer will be randomly generated.

Note that in order to allow Facebook users other than the app creator to authenticate with the app, the app must be marked as “Public” under the App Review section of the developer site.

Thursday, October 6, 2016PrintSubscribe
Dealing with Duplicates in Lookups

Fields configured with Lookup, Auto Complete, and Drop Down List item styles allow the user to type in a value and display a list of results. The text displayed in the results is configured via the Data Text Field property. Users can quickly enter a search term and find the field value they are looking for using lookups.

However, it is possible that the text displayed in the results can be non-unique. For example, there may be multiple customers with the same name, but from different locations. How can the user determine which value to select?

If multiple fields are borrowed from the lookup controller, the user interface will display these borrowed values in order to help the user determine the correct option. The example below shows duplicate customers displayed in a lookup of type “DropDownList”.

Duplicate customers will show the city and country of the customer in the drop down list.

Let’s borrow the City and Country fields from the Customers table into Orders form in the sample Northwind project.

Start the app generator, click on the project name, and press “Model”. Select “Orders” model from the list.

Editing the Orders data model.

Check the box next to “City” and “Country” columns in the Customers table.

Including City and Country fields in the Orders model.

Press “Save” to save the model. Then, press “Finish”, and confirm the popup to refresh the project. Then, press “Generate” to regenerate the app.

Navigate to the Orders page, and create a new record. Notice that the two new fields are displayed as read-only in the form. Enter a duplicate customer name, and the City and Country will be displayed next to the duplicate values.

Duplicate customers will show the city and country of the customer in the lookup results.

Selecting one of the customers will populate the Company Name in the lookup input, and copy the City and Country in the following borrowed fields.

Selecting a customer in New Orders form will copy the City and Country values.

This feature is automatically enabled when duplicate values are detected. The fields defined in the Copy property of the lookup field will be used. If duplicates are a common occurrence on a particular lookup, it is recommended to use a different display value, or create a calculated field in the lookup controller that can be specified as the Data Text Field. The full lookup grid can also be viewed by activating the arrow icon next to the field.