Home SmartChannels Advanced scenarios: callbacks and authorization. - Enabling authorization.

Login Form



Advanced scenarios: callbacks and authorization.
Advanced scenarios: callbacks and authorization. - Enabling authorization. PDF Print E-mail
Article Index
Advanced scenarios: callbacks and authorization.
Callback interface definition.
Service interface definition.
Service implemetation.
Defining service configuration.
Client implementation.
Defining client configuration.
Enabling authorization.

Enabling authorization.

Pre-shared key authorization of Smartchannels library is delivered by 2 classes - AzcChannelSinkProvider and AzsChannelSinkProvider. All we need to do to turn it on in our example is to modify app.config files for the service and client.

Service app.config modification:

Here is updated piece of remoting configuration of service's app.config:

<system.runtime.remoting>
    <application>
      <service>
        <wellknown mode="SingleCall" type="MyService.MyService, MyService" objectUri="MyService.rem"/>
      </service>
      <channels>
        <channel port="5000" ref="tcp">
          <serverProviders>
            <provider type="SSB.Runtime.Remoting.AzsChannelSinkProvider, SmartChannels" serverKey="KtoRz6H5CAYXyjhIURyvQg=="/>
            <formatter ref="binary" typeFilterLevel="Full" />
          </serverProviders>
          <clientProviders>
            <formatter ref="binary"/>
            <provider type="SSB.Runtime.Remoting.TocChannelSinkProvider, SmartChannels" defaultPollingInterval="10" defaultTimeoutInterval="5">
            </provider>
          </clientProviders>
        </channel>
      </channels>
    </application>
</system.runtime.remoting>


Look at this piece of text:

          <serverProviders>
            <provider type="SSB.Runtime.Remoting.AzsChannelSinkProvider, SmartChannels" serverKey="KtoRz6H5CAYXyjhIURyvQg=="/>
            <formatter ref="binary" typeFilterLevel="Full" />
          </serverProviders>


We have replaced TosChannelSinkProvider to AzsChannelSinkProvider and added parameter called serverKey. The value for this parameter looks like something encoded. That's right. To prevent passwords of being kept in plane text, SmartChannels library forces users to encode them using SmartChannelsPasswordEncoder.exe utility which is part of SmartChannels library distribution. To create password for the server, run this utility, enter password you like to encode, select "Server" as password type and click "Encode" button. Then copy the ontent of "Encoded password" textbox and paste it as a value of serverKey property of AzsChannelSinkProvider in app.config. Here is a screenshot of SmartChannelsPasswordEncoder.exe utility:

12

 

Client app.config modification.

Here is updated piece of remoting configuration of service's app.config:

<system.runtime.remoting>
    <application>
      <channels>
        <channel port="5001" ref="tcp">
          <serverProviders>
            <provider type="SSB.Runtime.Remoting.TosChannelSinkProvider, SmartChannels" />
            <formatter ref="binary" />
          </serverProviders>
          <clientProviders>
            <formatter ref="binary"/>
            <provider type="SSB.Runtime.Remoting.AzcChannelSinkProvider, SmartChannels" defaultPollingInterval="10" defaultTimeoutInterval="5" defaultServerKey="8ibrVcs+SHKk4XH/OLWuhQ==">
            </provider>
          </clientProviders>
        </channel>
      </channels>
    </application>
</system.runtime.remoting>

Look at this piece of text:

          <clientProviders>
             <formatter ref="binary"/>
             <provider type="SSB.Runtime.Remoting.AzcChannelSinkProvider, SmartChannels" defaultPollingInterval="10" defaultTimeoutInterval="5" defaultServerKey="8ibrVcs+SHKk4XH/OLWuhQ==">
             </provider>
           </clientProviders>

We have replaced TocChannelSinkProvider to AzcChannelSinkProvider and added parameter called defaultServerKey. And again, SmartChannels library forces users to encode passwords using SmartChannelsPasswordEncoder.exe utility which is part of SmartChannels library distribution. To encode server's password to be used by clients for authorization, run this utility, enter server's password you like to encode, select "Client" as password type and click "Encode" button. Then copy the content of "Encoded password" textbox and paste it as a value of defaultServerKey property of AzcChannelSinkProvider in app.config. As you may notice, the encoded strings for the same server's password are different and this is good (you can not copy/paste the encoded server's password from the server's app.config and use it on client's side). Here is a screenshot of SmartChannelsPasswordEncoder.exe utility:

13

 

If you made the changes of the service's and client's app.config, then you should be able to compile and run the example to test the functionality.

Well, what if your client has to connect to the different servers with different passwords? Good question. And here is the answer: use destination data entries. Here is an example:

<clientProviders>
  <formatter ref="binary"/>
  <provider type="SSB.Runtime.Remoting.AzcChannelSinkProvider, SmartChannels"  defaultPollingInterval="10" defaultTimeoutInterval="5" defaultServerKey="smF87+vjbrC9hw51Ud4lsA==" >
    <destination url="tcp://SERVER1.COM:5000/MyService.rem" pollingInterval="5" timeoutInterval="2" serverKey="HUanOCyMuZKguUL703ztMg==" />
    <destination url="tcp://SERVER2.COM:5050/AnotherService.rem" pollingInterval="40" timeoutInterval="20" serverKey="fXnZf0JozwhY/YK0gv84EA==" numRetries="3" />
  </provider>
</clientProviders>



That's it in brief. If you have any questions, please do not hesitate to contact us: This e-mail address is being protected from spambots. You need JavaScript enabled to view it


 

Copyright © 2010 SmartSoftwareBits.com. All Rights Reserved.