Workflow

Labels
AJAX(112) App Studio(9) 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(178) 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(3) 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
Workflow
Thursday, December 27, 2012PrintSubscribe
Web Transactions with Log Table

One method to implement separation of “draft” and “committed” data is to add a log table to the database. This table will store a list of references to data that has not been committed. For example, new orders created in a database will be referenced in the dedicated DraftOrderLog table. The application will ensure that draft orders are only visible on the order entry page. When a user submits an order, the reference to it will be removed from the log table.

Adding Log Table

Start SQL Server Management Studio. In the Object Explorer, right-click on Databases / Northwind node, and press New Query.

Creating a new query for Northwind database.

Paste in the following query:

create table DraftOrderLog
(
    OrderID int not null primary key,
    Created datetime default getdate()
)
go

The query will create the “DraftOrderLog” table with two columns. Column “OrderID” will record the ID of the draft order, and column “Created” will reflect the date when the order was logged.

On the toolbar, press Execute to run the query.

Controlling Display of Draft Orders

Start the web app generator. Select the project name and click Settings. Press Business Logic Layer and enable shared business rules. Click Finish and regenerate the project.

Enabling shared business rules for the project.

Start the Project Designer. In the Project Explorer, switch to the Controllers tab. Right-click on Orders controller, and press Edit Handler in Visual Studio.

Editing the shared business rule handler in Visual Studio.

The shared business rule file will open in Visual Studio. Replace the existing code with the following:

C#:

using System;
using System.Data;
using System.Collections.Generic;
using System.Linq;
using MyCompany.Data;

namespace MyCompany.Rules
{
    public partial class SharedBusinessRules : MyCompany.Data.BusinessRules
    {
        
        public SharedBusinessRules()
        {
        }

        protected override void EnumerateDynamicAccessControlRules(string controllerName)
        {
            if (Context.Request.UrlReferrer != null)
            {
                if (Context.Request.UrlReferrer.ToString().ToLower().Contains("orderform.aspx"))
                    RegisterAccessControlRule("OrderID", 
                        "select OrderID from DraftOrderLog", 
                        AccessPermission.Allow);
                else
                    RegisterAccessControlRule("OrderID", 
                        "select OrderID from DraftOrderLog", 
                        AccessPermission.Deny);
            }
        }
    }
}

Visual Basic:

Imports MyCompany.Data
Imports System
Imports System.Collections.Generic
Imports System.Data
Imports System.Linq

Namespace MyCompany.Rules

    Partial Public Class SharedBusinessRules
        Inherits MyCompany.Data.BusinessRules

        Public Sub New()
            MyBase.New()
        End Sub

        Protected Overrides Sub EnumerateDynamicAccessControlRules(controllerName As String)
            If Context.Request.UrlReferrer <> Nothing Then
                If Context.Request.UrlReferrer.ToString().ToLower().Contains("orderform.aspx") Then
                    RegisterAccessControlRule("OrderID",
                                              "select OrderID from DraftOrderLog",
                                              AccessPermission.Allow)
                Else
                    RegisterAccessControlRule("OrderID",
                                              "select OrderID from DraftOrderLog",
                                              AccessPermission.Deny)
                End If
            End If
        End Sub
    End Class
End Namespace

The implementation will conditionally register a dynamic access control rule that will be applied to a view of any data controller with an OrderID data field. If the user is interacting with the ~/Pages/OrderForm.aspx application page, then only data with OrderID that matches a record in the DraftOrderLog table will be included in the returned data set. All other pages will show data that is not linked to a logged order.

Save the file.

Adding Business Rule to Update Log Table

Switch back to the Project Designer. Right-click on Orders / Business Rules node, and press New Business Rule.

Creating a new business rule for Orders controller.

Assign the following values:

Property Value
Type SQL
Command Name Insert
Phase After
Script
insert into DraftOrderLog (OrderID)
values (@OrderID)

The business rule will insert a reference to the new order in the DraftOrderLog table. Press OK to save the business rule.

Adding “Submit Order” Action

Right-click on Orders / Actions / ag2 (Form) node, and press New Action.

Creating a new action in action group 'ag2'.

Give this action the following properties:

Property Value
Command Name Custom
Command Argument SubmitOrder
Header Text Submit Order

Press OK to save. Drop a101 – Custom, SubmitOrder | Submit Order node to the left side of a100 – Report | Order Report to place it first on the form.

Dropping action 'a101' on the left side of 'a100'.     Action 'a101' has been placed first in the heirarchy.

Right-click on Orders / Business Rules node, and press New Business Rule.

Creating a new business rule for Orders controller.

Assign these values:

Property Value
Type SQL
Command Name Custom
Command Argument SubmitOrder
Phase Execute
Script
delete from DraftOrderLog
where OrderID = @OrderID

set @Result_NavigateUrl = 'OrderForm.aspx'

This business rule will remove the reference to a submitted order from the DraftOrderLog table when the Submit Order action is activated. The browser will be instructed to navigate to ~/Pages/OrderForm.aspx page.

Press OK to save the business rule.

Viewing the Results

On the toolbar, press Browse. Navigate to the Order Form, and create a new order. Notice that only the new draft order is listed.

Only draft orders are displayed on the Order Form page.

Navigate to the Orders page. All orders except the draft order are displayed.

Draft orders are not displayed on the Orders page.

The draft order will not be visible in any data controller based on a database view that relates to orders. For example, the page Reports | Order Subtotals does not display the new order.

Draft orders not displayed on Order Subtotals report.

Switch back to the Order Form page, and select the draft order. Activate the Submit Order button.

Activating the 'Submit Order' button.

The application will refresh the page and display an empty list of orders.

Order Form list contains no draft orders.

The submitted order will now appear on Orders page.

Submitted order is displayed in the list of orders on the Orders page.

It will also appear on pages linked to data controllers related to orders.

Submitted order is now displayed in Order Subtotals data controller based on database view.

Wednesday, December 26, 2012PrintSubscribe
Web Transactions with “Status” Field

A dedicated “Status” field in a database table is a simple and easy to implement method of separating “draft” and “committed” data. For example, orders stored in a database will be explicitly marked with a status of “Committed” if no changes are allowed to them. Orders still being composed will be marked with a status of “Draft”. The application must ignore draft data and have it visible only on the order entry page.

Adding the “Status” Column

Start SQL Server Management Studio. In the Object Explorer, right-click on Databases / Northwind and press New Query.

Creating a new query for Northwind database.

Paste in the following script to add the table column and mark all existing orders as “Committed”.

alter table Orders
add Status nvarchar(50) default 'Draft'
go

update Orders
set Status = 'Committed'
go

On the toolbar, press Execute to run the query.

Controlling Display of Draft Orders

Start the web application generator. Select the project name and click Settings. Press Business Logic Layer and enable shared business rules. Click Finish and regenerate the project.

Enabling shared business rules.

Start the Project Designer. In the Project Explorer, switch to the Controllers tab. Right-click on Orders controller node, and press Edit Handler in Visual Studio.

Using the context menu action to edit the handler in Visual Studio.

The shared business rule file will open in Visual Studio. Replace the file with the following code:

C#:

using System;
using System.Data;
using System.Collections.Generic;
using System.Linq;
using MyCompany.Data;

namespace MyCompany.Rules
{
    public partial class SharedBusinessRules : MyCompany.Data.BusinessRules
    {
        
        public SharedBusinessRules()
        {
        }

        protected override void EnumerateDynamicAccessControlRules(string controllerName)
        {
            if (Context.Request.UrlReferrer != null)
            {
                if (Context.Request.UrlReferrer.ToString().ToLower().Contains("orderform.aspx"))
                    RegisterAccessControlRule("OrderID", 
                        "select OrderID from Orders where Status = 'Draft'", 
                        AccessPermission.Allow);
                else
                    RegisterAccessControlRule("OrderID", 
                        "select OrderID from Orders where Status = 'Committed'", 
                        AccessPermission.Allow);
            }
        }
    }
}

Visual Basic:

Imports MyCompany.Data
Imports System
Imports System.Collections.Generic
Imports System.Data
Imports System.Linq

Namespace MyCompany.Rules

    Partial Public Class SharedBusinessRules
        Inherits MyCompany.Data.BusinessRules

        Public Sub New()
            MyBase.New()
        End Sub

        Protected Overrides Sub EnumerateDynamicAccessControlRules(controllerName As String)
            If Context.Request.UrlReferrer <> Nothing Then
                If Context.Request.UrlReferrer.ToString().ToLower().Contains("orderform.aspx") Then
                    RegisterAccessControlRule("OrderID",
                                            "select OrderID from Orders where Status = 'Draft'",
                                            AccessPermission.Allow)
                Else
                    RegisterAccessControlRule("OrderID",
                                            "select OrderID from Orders where Status = 'Committed'",
                                            AccessPermission.Allow)
                End If
            End If
        End Sub
    End Class
End Namespace

The implementation will conditionally register a dynamic access control rule that will apply to a view of any data controller with an OrderID data field. If the user is interacting with an application page ~/Pages/OrderForm.aspx, then only data that matches orders with a status of “Draft” is allowed. Otherwise, only data that matches orders with a status of “Committed” is included in the returned data set.

Adding “Submit Order” Action

In the Project Explorer, right-click on Orders / Actions / ag2 (Form) node, and press New Action.

Context menu option 'New Action' for action group 'ag2'.

Assign the following values:

Property Value
Command Name Custom
Command Argument SubmitOrder
Header Text Submit Order

Press OK to save the action. Drop Orders / Actions / ag2 (Form) / a101 – Custom, SubmitOrder | Submit Order node on the left side of a100 – Report | Order Report to place it first.

Dropping action 'a101' on the left side of 'a100'.     Action 'a101' has been placed first in the form.

Adding Business Rule

Right-click on Orders / Business Rules node, and press New Business Rule.

Creating a new business rule for Orders controller.

Assign these values:

Property Value
Type SQL
Command Name Custom
Command Argument SubmitOrder
Phase Execute
Script
update Orders
set Status = 'Committed'
where OrderID = @OrderID

set @Result_NavigateUrl = 'OrderForm.aspx'

The business rule will set Status column of the selected order to “Committed” and refresh the page loaded in the web browser. Press OK to save.

Testing the Results

On the toolbar, press Browse. Navigate to the Order Form page. Create a new order and return to the grid. Note that only a single draft order is listed.

A single draft order is displayed in the Order Form list.

Navigate to the Orders page. Note that the all of the orders are displayed except for the draft order.

Orders page only displays committed orders.

The draft order will also not be visible in any data controllers based on database views if they relate to orders. For example, page Reports | Order Subtotals will not display the new order. The dynamic access control rule explained above filters the order out.

Other views and reports will not display draft reports.

Go back to the Order Form page, and select the draft order. Click on the “Submit Order” button.

Clicking on the 'Submit Order' button in the Order Form.

The browser will refresh the page and display an empty list of orders.

The Order Form grid does not display any records.

The order will now be displayed on Orders page.

The committed order is now displayed on Orders page.

It will also be displayed on Order Subtotals page that can be found under the Reports option in the application navigation menu.

Committed order displayed on Order Subtotals page.

Wednesday, November 7, 2012PrintSubscribe
Introducing Custom Membership and Role Providers

Internet web applications require an integrated user management. Anonymous users are denied access to protected site pages. Registered users may see a subset of protected pages that depends on user roles.

About ASP.NET Membership

Microsoft ASP.NET Membership is a powerful pre-packaged option for user and role management available to developers. With little effort a set of required tables and stored procedures can be installed in an application or a standalone database. ASP.NET membership providers are a native part of the security framework of Microsoft.NET. Many database vendors include custom implementations of ASP.NET membership providers with their software.

It takes only a few clicks to integrate ASP.NET Membership in a web app using Project Wizard.

A requirement to maintain “alien” tables and stored procedure in the application database causes some developers to embark on  a path to develop custom membership and role providers for a project. This is not a trivial effort - cutting corners is not recommended.

A table with a list of users is frequently a centerpiece  in many databases and creates another incentive to build a custom membership provider.

Sample Custom Membership Configuration

Code On Time web application generator can produce integrated membership and role providers straight from the application database tables.

Consider the Northwind sample web application. The database table Employees is a perfect example of a source of user identities.

Table 'Employees' from 'Northwind' sample may be used as a source of user identities in an web app

An application can treat the Last Name as a “User Name” and Extension as a “Password”.

Here is the list of employees.

The list of employees stored in the 'Northwind' sample database table 'Employees'

Start creating a new Northwind project.

As you go through the steps of the project wizard, pause on the page Authentication and Membership. Select option “Enable custom membership and role providers.”

Enter the following in the configuration box.

table Users=Employees
column [int|uiid] UserID = EmployeeID
column [text] UserName = LastName
column [text] Password = Extension

role Administrators = Fuller
role Users = *

option Create Standard User Accounts = false
option Password Format = Clear

The configuration of membership and role providers maps the columns of the physical table Employees to logical table Users. Application generator will use the the logical table mapping when creating the source code of the providers.

The configuration also defines two roles – Administrators  and Users. A minimal custom membership implementation does not require a physical table to hold a list of user roles.  This simple declaration states that the user with the last name of Fuller is the “administrator”. It also declares that all employees are “users”.

The automatically generated implementation of providers will try to register two standard user accounts “admin” and “user”. Option “Create Standard User Accounts” is set to “false” to prevent that.

The provider implementation will also try to “hash” the passwords for added security. The employee phone extensions are stored in a “clear” format. Therefore the “Password Format” option disables “hashing”.

Complete the application configuration and activate Project Designer. Using Project Explorer, select page Users and enter Administrators in Roles property, click OK button to save the page configuration. This will ensure that only an administrator can access the page.

Generate the app and login as Davolio with password 5467 when prompted.

Sign in process in a web app with custom membership and role providers

Page Employees will not be visible in the site menu.

Non-administrative users do not have access to 'Employees' page

Log out and sign in as Fuller / 3457 to manage employees on Employees page.

image

Users, Roles, and User Roles

The example above will have to be extended when dynamic roles are required.

Consider these database tables.

A basic set tables of an implementaton of custom membership and role providers

The following configuration of custom membership and role providers will be sufficient to equip a web application with dynamic users and roles.

table Users=Users
column [int|uiid] UserID = UserID
column [text] UserName = UserName
column [text] Password = Password

table Roles=Roles
column [int|uiid] RoleID = RoleID
column [text] RoleName = RoleName

table UserRoles=UserRoles
column [int|uiid] UserID = UserID
column [int|uiid] RoleID = RoleID

Select the project name on the start page of the app generator, choose Authentication and Membership, proceed to modify the configuration of custom membership and role providers. Generate the application and sign in with one of the standard user accounts – admin/admin123% or user/user123%.

Application home page is presented to a standard account 'user' after successful login

Tables Users, Roles, and UserRoles provide a foundation for the integrated security system of the web application.

Tables in the foundation of the security system of a web app with custom membership and role providers created with Code On Time application generator