Extracting the Serial Buffer for the Policy Evaluator Plug-In

This section explains the user prompting function in the Symbian Messaging subsystem and how to extract the serial buffer from the various Message Type Modules (MTM) of messaging components to the User Prompt Service (UPS) Policy Evaluator plug-in.

The Symbian Messaging subsystem is modified to automatically request the user's permission for sending messages. The user's permission for outbound messages depends on the capability of the client application that sends the email or SMS message. The phone users are prompted to decide if any activity that can be billed (for example, sending an email message or an SMS message) must be allowed or not. The phone user is prompted with a dialog box to allow or deny the operation, and to choose if that decision should apply to one operation, or always for a particular client application.

If the client application uses the SendAs server to send email or SMS messages, then the user is prompted at the SendAs server stage only and not at the server MTM stage. This behaviour can be configured at ROM build time.

At ROM build time, the phone manufacturers can configure the following:

• The scope of the permission granted to send email or SMS messages; that is, for one operation only or always for a particular client application.

• Whether the user is prompted for processes that have the network services capability, or not.

• Whether the user is prompted for processes that do not have the network services capability, or not.

The request to send email or SMS messages from a UI application and SendAs2 servers is passed from a client MTM to the messaging server, on to the corresponding server MTM, and then to UPS.

UPS uses the Policy Evaluator plug-in, which allows a security decision to be specific to an individual UI application. The Policy Evaluator plug-in prompts the phone user (using the Dialog creator plug-in) for permission to send a message, if the client application does not have the correct capability set.

UPS

User Prompt Service

UPS allows licensees to specify whether requests made by applications to access services, such as, a request to make a telephone call, are processed silently, or whether the user is required to confirm the request. For more information on UPS, see User Prompt Service overview.

SendAs server

The following are some of the important SendAs server features:

• Send a message after the capability policing of the client application has been completed.

  For more information on capability policing, see the Platform security guide in the Symbian Developer Library.

• Allow client applications to launch an editor for a specified message type.

• Allow client applications to query the message type.

For more information on SendAs server, see Send-As Messaging.

Policy Evaluator

Policy Evaluator is an ECOM plug-in, which is responsible for generating fingerprints used to locate previous decision records related to the request. A default Policy Evaluator is provided by Symbian OS, but licensees can also write a Policy Evaluator. For more information on Policy Evaluator, see How to write a UPS policy evaluator.

Dialog creator

Dialog creator is an ECOM plug-in, which generates and displays dialog prompts. Licensees define the Dialog creator plug-in. For more information on Dialog creator, see How to write a UPS dialog creator.

The licensee must implement the Policy Evaluator and Dialog creator plug-ins to get the full functionality of the UPS service.

The Policy Evaluator plug-in can use the destination parameter to check if a particular request made by a client application is permissible for a particular destination.

The Messaging servers that interact with the UPS service can pass the destination parameter (phone number, server address, and so on.) as a TDesC descriptor. If there is more than one parameter, the Messaging server serialises the list of addresses to a TDesC descriptor.

To enable the licensee to use this data, the Policy Evaluator plug-in must convert TDesC to an address list.

The following code snippet shows how to convert the TDesC8 descriptor to the address list. When the CPromptRequest::Destination() method is called, it returns a const TDesC reference, which contains the externalized destination values.

In order to internalize this TDesC, the plug-in needs to implement the Internalise() functionality using the following method:

void InternaliseDestinationParameterL ()
        {   
         const TDesC& d = iRequest->Destination(); // iRequest is a pointer of type CPromptRequest
         TPtrC8 p(reinterpret_cast<const TUint8*>(d.Ptr()), d.Length() * 2);
         RDesReadStream readStream(p);
         InternalizeL(readStream);
        }
InternalizeL (RReadStream& aStream)
        {
         TInt count = aStream.ReadInt32L ();
         RArray<TPtrC> destinationArray;
         TBuf<1000 > destination ; // 1000 since this is the maximum length if the header info of a mail
         for(TInt I=0;i< count;++I)
               {
                aStream >> destination;
                destinationArray.Append(destination);
               }
        }

The licensee can now use the extracted serial buffer for displaying dialog prompts.