Running a Windows Form Application from Different Security Zones
There are two ways to test your Windows Form application under different security zones with different permission sets. One way is by launching the app from the PowerBuilder IDE by clicking the running man after you choose a trust level other than full trust and deploy the project successfully. Here's an example: create a new Windows Form application with the wizard and add a window w_test and a button cb_1, then write the code below for a cb_1.clicked event:

integer li_filenum,li_filewrite
String ls_filename = "test_fileio.txt"

li_filenum = FileOpen(ls_filename,LineMode!, Write!, LockWrite!, Append!,EncodingUTF8!)
if li_filenum >0 then
li_filewrite = FileWrite(li_FileNum, "Test FileWrite " + string(datetime(today(), now())))
fileclose(li_FileNum)
end if

To make the test easier, I selected the "custom" trust level and then selected only SecurityPermission and UIPermission in the permission list. I deployed and clicked the running man to launch the application, then when I clicked the button, a runtime exception popped up because I didn't select FileIOPermission.

After selecting FileIOPermission, redeploy and run the application and the code block will work perfectly.

Another way to test the application is by launching the application from the file explorer:

• Directly type the full path of the application and launch the application from My Computer Zone. For example: C:\>F:\temp\pbtest_winformoutput\pbtest.exe. The application will run in my computer zone and by default run with full trust permissions.
• Launch the app from a network path using LocalIntranet Zone: For example: C:\>\\maggielv\F$\temp\pbtest_winformoutput\pbtest.exe.
• Launch the app from a network path using Internet Zone. For example: C:\>\\127.0.0.1\F$\temp\pbtest_winformoutput\pbtest.exe.

When running the application from the Internet Zone, the app might not be launched. That's because by default the Internet permission set applied in the Internet Zone gives only restricted UIPermission, while the PowerBuilder .NET Windows Form application requires "Unrestricted" UIPermission. Please refer to Figure 2 on how to create a new permission set for the Internet Zone and change the UIPermission to "Unrestricted". You can view the default permissions contained by this zone from the .NET Framework 2.0 configuration tool (see Figure 1). Here you get to know that the same block of code behaves differently if it originates from different zones. In the sample above, you can create a new permission set with the File IO permission granted and apply it to the Local Intranet Zone (see Figure 2 and the related description), then the code will work.

Applying CAS in a PowerBuilder .NET SmartClient Application
As you know from the description above, in the real world, when you run a Windows Form application, the security policy in .the NET Framework 2.0 configuration will be used. Sometimes you may ask the system administrator to change the policies considering your intended operations or you, as application developers, will have to modify your code to meet the system's security policy. Without these actions, your application will pop up runtime security exceptions now and then. With these considerations in mind, a SmartClient application might be the best candidate for applying CAS. The security permission configured in the SmartClient project painter (see Figure 3) will be written into the application's manifest file after publishing.

When an end user tries to install the application from the install link like http://mysite/my_smartclient/publish.htm and trusts the publisher, the application will be installed on the client side as a trusted application. When the application is launched from the client side, since it's regarded as a trusted application, all the permissions granted will be valid at runtime with the same behavior as you run a non-SmartClient Windows Form application. You can get more information from the references on how to trust a publisher and how to generate a root certificate and personal certificate.

Figure 4 shows the step in signing the manifest file of a SmartClient application with a testing certificate file generated with Windows 2003 Server.

Using a SmartClient with CAS has the least impact and change requirements on the current system's security policy setting since every SmartClient application is accessible only to a certain user and will run in its own sandbox with its own permission sets.

Handling the Runtime Security Exceptions
You see in Figure 5 that a runtime security exception will pop up when certain code does not meet the current security policy. Once an exception occurs, the code behind the error line will be ignored. The exception shown in Figure 4 is thrown by the .NET Framework if there is no other error-handling code in your application. If you like, you can choose the following ways to handle the exception:

1. Use try...catch...end try to trap the exception.
To do this, first import the .NET Framework 2.0 assembly System.dll, then write the code in Listing 1 to catch the security exception (see Figure 6).

2. Use the application's systemerror event.
You can also use the application object's SystemError event (see Figure 7). Any runtime error will trigger this event and all code behind the error line will be ignored.

3. Leave it to the .NET Framework to handle the exception.
If you don't handle the possible runtime exceptions related to CAS, a runtime exception message (see Figure 4) raised from the .NET Framework 2.0 will display.

Regarding these three ways, using try...catch block to trap the system exception at the location where it occurs is the preferred method because it lets you recover from the exception more gracefully.

Applying CAS in a PowerBuilder .NET WebForm Application and Web Service
By default, a PowerBuilder .NET WebForm application and Web Service run with a full trust security level, while PowerBuilder 11.5 provides the support of running a .NET WebForm applications and Web Services at a customized trust level. You can set the permission according to the features and code of your application. When you choose a custom level, web_customtrust.config will be generated with all the selected permissions included and referred in the application's web.config. At runtime, the permission setting in web_customtrust.config will take effect and control the behavior of your code. Here's the code block from web.config:

<system.web>
<securityPolicy>
<trustLevel name="Custom" policyFile="web_customtrust.config" />
</securityPolicy>
<trust level="Custom" originUrl="" />
</system.web>

Notice that some operations in WebForm need special permissions because of the special implementation. For example, WebForm print- and registry-related operations also need FileIOPermission because these features in PowerBuilder WebForm are implemented with File I/O. What's more, because PowerBuilder .NET WebForm and WebService adopt a virtual file system, FileIOPermission is always required for most such Web applications.

CAS for NVO .NET Assembly
For NVO .NET assembly there's no separate security settings. When the assembly is called at runtime, it will inherit all the security policies from its caller. The caller here can be a WebForm app, Windows Form app, or a Web Service.

Conclusion
Like all other security strategies, CAS is a double-edged sword. It provides you with more flexible control of your resources at runtime. Compared with designing and applying a full trust application without considering the CAS restrictions, it requires that developers and system administrators cooperate and do a little more work in coding and security policy configuration. PowerBuilder 11.5 lets your application use CAS policy. Once you choose to use CAS, a thorough testing of your whole application is needed to avoid unexpected runtime bombs from security exceptions. So whether to use CAS or not and how to use it rests with your application's intention, your end user's expectations, and the security policy of your system environment.

References

• ".NET Framework Developer's Guide: Code Access Security."
• "How to Add a Trusted Publisher to a Client Computer for ClickOnce Applications."
• ".NET Framework tool: Code Access Security Policy Tool (caspol.exe)."
• "Code Access Permissions from .NET Framework."
• "Requesting a Digital Certificate.