Symbian OS Communications (779884), страница 24

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 24)

You need to decide what the user’s expectations are for thesecurity of the data they’re transmitting. In cases where the data is relatively benign, such as when playing a game of Snake, for example,then it is perfectly reasonable not to use authentication or encryptionas the data is not sensitive and the additional steps required to useauthentication and encryption would reduce usability. However, in thecase where you are transferring potentially sensitive information such asthe user’s entire phonebook, then it is sensible for the device makingthe outbound connection to request both authentication and encryption.This means that even if the application on the receiving device hasa lax view of security that we have still done our part to protect theuser’s data.There is an additional feature on Symbian OS that is exposed by allUI platforms – the concept of a ‘trusted’ device.

Devices can individually be set as trusted in the user interface – as a result of doing thisauthorization, even if requested by the service, is disabled for thesedevices – instead the connection is simply accepted. This is a very usefulfeature for giving an additional level of trust to a set of devices that areowned and controlled by a single user. All of this happens transparentlythough, so you don’t need to do anything special in your service – theautomatic acceptance of incoming connections happens behind thescenes.Let’s now take a look at TBTSecurityService – the interestingmethods on this class are:IMPORT_CIMPORT_CIMPORT_CIMPORT_CIMPORT_CIMPORT_CvoidvoidvoidvoidvoidTIntSetUid(TUid aUid);SetAuthentication(TBool aPreference);SetAuthorisation(TBool aPreference);SetEncryption(TBool aPreference);SetDenied(TBool aPreference);SetPasskeyMinLength(TUint aPasskeyMinLength);The class allows the user to select a combination of authorization,authentication and encryption that is needed for a remote device toconnect to the service.

The SetDenied() method is useful whena service wants to temporarily reject incoming connections, perhapsbecause it has reached some capacity limit, without having to close itssockets and other resources.BLUETOOTH IN SYMBIAN OS101The SetPasskeyMinLength() method allows the service todemand passkeys (or PINs as they’re often known) of at least a certain length to be used – the resulting token used in the authenticationprocess is stronger when longer pass keys are used.Principally for the use of the device’s Bluetooth control panel, TBTDeviceSecurity allows ‘global’ security settings for that device tobe configured: for example, to set the device as ‘trusted’ (i.e., needsauthenticating, but can bypass any authorization set by a service).As previously mentioned, all current versions of the Bluetooth specification require the remote device to be authenticated before encryptioncan be used.

This requires the devices go through the pairing procedure, typically on the first connection. The next version of the Bluetoothspecification after 2.0 introduces a new, simplified, pairing schemethat is both more usable from the end-user perspective, and allowsencryption to be applied without an obvious pairing procedure.The SetUid() method allows for the UI to display an indicationof which service is requesting the authorization. This UID should bea standard Symbian UID that is assigned to you, but does not have tobe the same as any other UID you are using – however, for ease ofadministration it might be easiest to use the UID of one of the executablesproviding the service.Note that current UI platforms choose not to make use of this information – instead presenting a generic dialog, as per Figure 4.9.

However,it is worth passing a sensible value into this method should theauthorization prompts change in the future.Port and security setting: example codeThe following code snippet is taken from the example code for thischapter (described in section 4.3). It shows that for this particular servicethere is only a request to use authorization.TBTServiceSecurity sec;sec.SetAuthorisation(ETrue);sec.SetUid(TUid::Uid(KUidBluetoothBusTransport));// iUpstreamAddress is a TL2CAPSockAddr that cannot be held on the stackdue to the asynchronous connection call lateriUpstreamAddress.SetSecurity(sec);// ask the Bluetooth stack to allocate an L2CAP portiUpstreamAddress.SetPort(KL2CAPPassiveAutoBind);Example 4.8connectionSetting the security requirements for an incoming102BLUETOOTHMore complex security settingIndividual services can themselves nominate individual devices to havedifferent security clearance for connection to that service, although thisis typically not recommended as it does not fit well into the way thatUI platforms manage settings for Bluetooth devices, which are groupedtogether to allow the user to control all settings for a Bluetooth devicefrom a single place.TBTServiceSecurityPerDevice makes this possible – it is simplya container for the Bluetooth address of the remote device for whichspecial security applies, together with the security settings.

Each attributecan be set through construction or setters:IMPORT_C TBTServiceSecurityPerDevice(const TBTDevAddr& aDevice, constTBTDeviceSecurity& aSecuritySettings);IMPORT_C void SetDeviceSecurity(const TBTDeviceSecurity&aSecuritySettings);IMPORT_C void SetAddress(const TBTDevAddr& aAddress);To set an override into the listening socket the application putsTBTServiceSecurityPerDevice into a package descriptor (a convenience typedef, TBTServiceSecurityPerDeviceBuf, helps here)and calls SetOpt(KBTSecurityDeviceOverride, KSolBtL2CAP,btSecurityPerDeviceBuf) on the socket to deliver the securitysettings to the protocol.CBluetoothSocketThe CBluetoothSocket class brings together into a convenient package the services of RSocket and RBTPhysicalLinkAdapter.

CBluetoothSocket supports both the L2CAP and RFCOMM protocols.The interface to CBluetoothSocket is intended to follow that of theRSocket and RBTPhysicalLinkAdapter. As you’d expect, beinga C-class the rules for creation, deletion and copying differ from theR-classes that would otherwise be used. In a similar way to RSocket,not all of the methods presented on CBluetoothSocket are meaningful for the Bluetooth protocols currently implemented in Symbian OS.For example, the connectionless read and write methods (SendTo andRecvFrom) will return KErrNotSupported; however, once SymbianOS supports connectionless L2CAP then these methods will be supportedon both CBluetoothSocket and RSocket.An advantage of CBluetoothSocket is that it is removes the needto write the usual set of active object wrappers around RSocket.

WhilstCBluetoothSocket is not derived from CActive, it aggregates severalactive objects to perform operations on an internally held RSocket.Alternately, you might like to consider the wrapper classes shown inBLUETOOTH IN SYMBIAN OS103Chapter 3 – although these do not bring the benefit of providing theRBTPhysicalLinkAdapter methods in the same class.Callbacks from the class are made through an M-class interfacerather than through a TRequestStatus& belonging to the application – therefore the client of the CBluetoothSocket is expected toprovide a reference to a MBluetoothSocketNotifier which it implements internally.MBluetoothSocketNotifiervirtualvirtualvirtualvirtualvirtualvirtualvirtualvoidvoidvoidvoidvoidvoidvoidHandleConnectCompleteL(TInt aErr) = 0;HandleAcceptCompleteL(TInt aErr) = 0;HandleShutdownCompleteL(TInt aErr) = 0;HandleSendCompleteL(TInt aErr) = 0;HandleReceiveCompleteL(TInt aErr) = 0;HandleIoctlCompleteL(TInt aErr) = 0;HandleActivateBasebandEventNotifierCompleteL(TInt aErr,TBTBasebandEventNotification& aEventNotification) = 0;This class is implemented by a user of CBluetoothSocket – it is notused if the client accesses Bluetooth protocols via RSocket.

Note thatalthough the methods have a trailing L allowing for the client to leave,the event publisher within Symbian OS does not do anything other thansilently consume the leave reason.As with many objects publishing events through M-classes, the abilityto delete the event publisher (in this case CBluetoothSocket) withinthe context of an upcall into the M-class is not supported.This class allows the client to receive unsolicited indications fromthe protocol due to internal code in Symbian OS that is not accessiblethrough the underlying RSocketclass.4.2.8 Service DiscoverySDP ServerIn this section we’ll look at how Bluetooth services advertise themselvesto remote Bluetooth devices using the SDP server. Before reading thissection, make sure you have a good understanding of the concepts insection 4.1.6, as SDP is a complex topic, and the APIs can be confusingif you don’t understand what they’re doing!The SDP server in Symbian OS is itself a server in the Symbian OSsense; and is accessed via a number of client APIs.A session is formed between the application and the SDP server usingthe RSdp class.

Typically one service will have one session on the SDPserver, although this is not a hard limit but a recommendation to reducethe resources consumed by the service.104BLUETOOTHRSdp sdpSession;User::LeaveIfError(sdpSession.Connect());Example 4.9Connecting to the Symbian OS SDP serverOnce a session is created, RSdpDatabase needs to be opened – thisis the mechanism through which records can be added to, deleted fromor manipulated in the database.When registering in the SDDB, an application will typically register a single service record. The service record has two fundamentalattributes – the record handle, which is created automatically by the SDPserver, and the service class, which is passed into the API at creationtime.

Here are the methods to register a new service record:IMPORT_C void CreateServiceRecordL(const TUUID& aUUID,TSdpServRecordHandle& aHandle);IMPORT_C void CreateServiceRecordL(CSdpAttrValueDES& aUUIDList,TSdpServRecordHandle& aHandle);Note that you can either use a UUID or a DES (which in this casewould contain a hierarchical structure of UUIDs) to identify your service.It is recommended that you use a 128-bit UUID here – you can createone as discussed in section 4.1.6.The second version of CreateServiceRecord() taking an DESoffers a more advanced use of the service class field, but using it bringsa serious increase in complexity in terms of implementing your service.It allows you to create services that exhibit some degree of ‘servicepolymorphism’, where the same service can be offered in both simpleand (a number of increasingly) complex forms through the same servicerecord.

We’re not going to cover that here.Note that the service must delete the records it has added into theSDDB prior to closing its handles with the server.Now we can look at the methods on RSdpDatabase used to addattributes to the service record we’ve just created:IMPORT_C void UpdateAttributeL(TSdpServRecordHandle aHandle,TSdpAttributeID aAttrID, CSdpAttrValue& aAttrValue);IMPORT_C void UpdateAttributeL(TSdpServRecordHandle aHandle,TSdpAttributeID aAttrID, TUint aUintValue);IMPORT_C void UpdateAttributeL(TSdpServRecordHandle aHandle,TSdpAttributeID aAttrID, const TDesC16& aDesCValue);IMPORT_C void UpdateAttributeL(TSdpServRecordHandle aHandle,TSdpAttributeID aAttrID, const TDesC8& aDesCValue);IMPORT_C void DeleteAttributeL(TSdpServRecordHandle aHandle,TSdpAttributeID aAttrID);IMPORT_C void DeleteRecordL(TSdpServRecordHandle aHandle);BLUETOOTH IN SYMBIAN OS105In Symbian OS v9.2 the DeleteRecordL() method has been deprecated in favour of the newly published DeleteRecord() method.The latter is preferable as it removes the potential Leave in awkwardplaces in your application.Note that the SDP server performs no syntax checking of the structureof the attributes in a record; so when you are registering your SDPrecord you need to be aware of the syntax of each of the attributesbeing stored.

Характеристики

Список файлов книги