October 2012

LinkedIn authentication integration

For LinkedIn Authentication I have utilized LinkedIn Rest API which use oAuth 1.0 to authorize users and begin making REST API calls using any programming language. Complete understanding tutorials are placed at https://developer.linkedin.com/documents/oauth-overview

Following are the steps to implement LinkedIn Authentication in ASP.Net

Step 1 Installations

Install Hammock Library from CodePlex.com, Hammock is a REST library for .Net that greatly simplifies consuming Restful services.
Configure NuGet (optional to ease referencing code plex libraries directly in Visual Studio project). You can also get the NuGet from http://nuget.codeplex.com/

Step 2 Create LinkedIn Application in LinkedIn developer platform

Go to https://www.linkedin.com/secure/developer
Sign in with your LinkedIn credentials.
Click on Add New Application and fill in the form.
Once your application is created note the API Key and Secret Key that we will use to implement LinkedIn authentication in our application.

Step 3 Create ASP.Net Application

Open Visual Studio and create a new Web Application project.
Add references to Hammock library either by manually referencing from folder or just referencing through NuGet in Visual Studio Directly as shown below.

void RequestTokenAndAuthorize()


var credentials = new Hammock.Authentication.OAuth.OAuthCredentials


CallbackUrl = “http://localhost/LinkedInAuthWebSite/Callback.aspx”,

ConsumerKey = “API Key”,

ConsumerSecret = “Secret Key”,

Type = Hammock.Authentication.OAuth.OAuthType.RequestToken


var client = new Hammock.RestClient


Authority = “https://api.linkedin.com/uas/oauth”, Credentials = credentials };

var request = new Hammock.RestRequest { Path = “requestToken” };

Hammock.RestResponse response = client.Request(request);

String[] strResponseAttributes = response.Content.Split(‘&’);

string token = strResponseAttributes[0].Substring(strResponseAttributes[0].LastIndexOf(‘=’) + 1);

string authToken = strResponseAttributes[1].Substring(strResponseAttributes[1].LastIndexOf(‘=’) + 1);

Session[“Token”] = token;

Session[“TokenSecret”] = authToken;

Response.Redirect(“https://www.linkedin.com/uas/oauth/authorize?oauth_token=” + token);


CallBack URL will be called when the authorization is successfully done by LinkedIn.

Now Create a CallBack page where the callback takes place when the authorization is done after successful login. In my case I have created a Callback.aspx.
In the Callback page place following code in the Page_Load method.

void Page_Load(object sender, EventArgs e)


String verifier = Request.QueryString[“oauth_verifier”].ToString();

Session[“Verifier”] = verifier;

var credentials = new Hammock.Authentication.OAuth.OAuthCredentials


ConsumerKey = “API Key”,

ConsumerSecret = “Secret Key”,

Token = Session[“Token”].ToString(),

TokenSecret = Session[“TokenSecret”].ToString(),

Verifier = verifier,

Type = Hammock.Authentication.OAuth.OAuthType.AccessToken,

ParameterHandling = Hammock.Authentication.OAuth.OAuthParameterHandling.HttpAuthorizationHeader,

SignatureMethod = Hammock.Authentication.OAuth.OAuthSignatureMethod.HmacSha1,

Version = “1.0″


var client = new
RestClient { Authority = “https://api.linkedin.com/uas/oauth”, Credentials = credentials, Method = WebMethod.Post };

var request = new
RestRequest { Path = “accessToken” };

RestResponse response = client.Request(request);

String[] strResponseAttributes = response.Content.Split(‘&’);

string token = strResponseAttributes[0].Substring(strResponseAttributes[0].LastIndexOf(‘=’) + 1);

string authToken = strResponseAttributes[1].Substring(strResponseAttributes[1].LastIndexOf(‘=’) + 1);

Session[“AccessToken”] = token;

Session[“AccessSecretToken”] = authToken;



GetUserProfile method is used to get the Logged in User First Name and Last name to display on Callback page.

void GetUserProfile()


var request = new


Path = “~”


var credentials = new Hammock.Authentication.OAuth.OAuthCredentials


Type = Hammock.Authentication.OAuth.OAuthType.AccessToken,

SignatureMethod = Hammock.Authentication.OAuth.OAuthSignatureMethod.HmacSha1,

ParameterHandling = Hammock.Authentication.OAuth.OAuthParameterHandling.HttpAuthorizationHeader,

ConsumerKey = “API Key”,

ConsumerSecret = “Secret Key”,

Token = Session[“AccessToken”].ToString(),

TokenSecret = Session[“AccessSecretToken”].ToString(),

Verifier = Session[“Verifier”].ToString()


var client = new


Authority = “http://api.linkedin.com/v1/people”, Credentials = credentials, Method = WebMethod.Get


var MyInfo = client.Request(request);

String content = MyInfo.Content.ToString();

var person = from c in

select c;

String fullName=String.Empty;

foreach (var element in person)


if((element.Name == “first-name”) || (element.Name==“last-name”))

fullName += element.Value.ToString();


lblName.Text = fullName;


Step 4 Run the Application

Download source code: here

How to send the build to already provisioned remote person’s iPhone

If you’ve been through the distribution process of an Ad Hoc application, you can appreciate the challenges of getting a build installed on someone’s device. From the differences of working with users on Windows versus Mac machines, to explaining how to import an Ad Hoc provisioning file and the associated build into iTunes, this process is anything but a walk in the park.
In this post I’ll take you through the steps of deploying Ad Hoc builds over-the-air, where users simply point the Safari web-browser (on their iPhone) to a link and tap to install the provisioning file and associated application.
Provisioning Profile
To begin, create a provisioning profile like you would for any other Ad Hoc build. In the image below you’ll notice I created a profile named AdHocOTAProfile and associated this with the app id AdHocOTA.

Once the profile is created, download onto your location machine and drag/drop the file onto the Xcode icon, this will install the provisioning file into the following folder: ~/Library/MobileDevice/Provisioning Profiles. The image below is a screenshot of the profile path on my machine – notice the provisioning file name is no longer the nice readable name that was written to your file system when you downloaded the file, this is to be expected.

From within Xcode, you can now associate this provisioning profile with your build. In the Target settings, select the Build tab, in the Code Signing section choose the new Provisioning Profile you created:

Xcode Build and Archive
Once you have a working project within Xcode (with the Code Signing identity set as mentioned above), make sure that you set the build type to Device.

From the Build menu in Xcode, choose Build and Archive (if this option is not highlighted, make sure you’ve selected Device in the build settings.

Once the build is complete, the Organizer window will appear – make sure the Archived Applications section is selected on the left panel.

In the figure above, I’ve updated the Name of the app to AdHoc OTA Test, this is optional, as well as any comments you would like to include.
Click on the Share button, and a new dialog will appear similar to that shown below:

From the Identity dropdown, select the Provisioning Profile created earlier:

Now choose Distribute for Enterprise – fill in the URL to the location where you plan to host the application. Note that you must include the fullpath to the application, including the name of the .ipa file that you plan to use:

At this point, don’t worry about the image files, I believe those are applicable only if you are doing an OTA deployment through an Enterprise developer account (internal app distribution for corporations). Update: Seems there may be a little more to how the images are used beyond Enterprise deployments, see the comments section for more information.
Once you select Ok, you will be prompted for a filename to save the build, verify that you use the same name as you specified in the URL:

At this point ipa and plist files will be created for you, the provisioning file will be embedded within the ipa.
With the build complete, we know need to create a very simple webpage that will allow users to find the application on a web-server.
The html below is as about as bare-bones as we can get, it’s nothing more than a link to the file, with a specific href for itms-services which Safari will recognize and initiate the download/install process when clicked.

<title>OTA Test App </title>
< a href=”//?action=download-manifest&url=http://3SixtySoftware.com/OTAtest/AdHocOTATest.plist” > Tap Here to Install the Application </a>

Important: – Replace the path shown above with the path to where you will upload the ipa and plist files that Xcode created.
Save the html file with the extension .html
Upload To Web-Server
We’re getting close – at this point we are ready to upload the ipa, plist and html files. The figure below shows the directory listing on the web-server where I uploaded the files:

Install the iPhone Application OTA
To download the application via OTA, start your web-browser and point it to the link where the html file lives. Once loaded you should see a screen similar to the figure below:

Tap on the link and a dialog will appear asking if you would like to install the Ad Hoc application:

If all works as expected, at this point you can send a link to the html file to anyone you included in the provisioning file and they can install the application OTA.

You download sample “Hello” project html, plist and ipa file: here

Reference link: Link 1, Link 2, Link 3

Cross-domain policy issue in Silverlight application

“An error occurred while trying to make a request to URI. This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services. You may need to contact the owner of the service to publish a cross-domain policy file and to ensure it allows SOAP-related HTTP headers to be sent. This error may also be caused by using internal types in the web service proxy without using the InternalsVisibleToAttribute attribute. Please see the inner exception for more details.”

1. Create an xml file using notepad and save as clientaccesspolicy.xml with the following content.

<?xml version=”1.0″ encoding=”utf-8″?>
      <allow-from http-request-headers=”SOAPAction”>
        <domain uri=”*”/>
        <resource path=”/” include-subpaths=”true”/>
2. Create an xml file using notepad and save as crossdomain.xml with the following content.
<?xml version=”1.0″?>
<!DOCTYPE cross-domain-policy SYSTEM “http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd”>
  <allow-http-request-headers-from domain=”*” headers=”SOAPAction,Content-Type”/>
3. Copy these 2 files into web site root folder for example, c:\inetpub\wwwroot. for your IIS (local system) or in root folder of website(c:\inetpub\wwwroot\controlsdemowcf)  on server (2008, 2003).

Easily Deploy Your LightSwitch Apps to Azure Websites in Minutes

As part of my demo preps for all the conferences I’ve spoken at recently I’ve been deploying my LightSwitch apps to Azure websites and I can honestly say that it is by far the easiest way to get a LightSwitch application up and running. Of course you can always manually set up your own server, database and network if you want a purely internal business app like I’ve showed in these deployment posts. However, it’s always hard to troubleshoot what goes wrong when a deployment goes bad because everyone’s environment is a little bit different. The great thing about Azure websites is the environment is hassle-free and already ready for you to deploy your LightSwitch applications.

In this post I’ll detail step-by-step how to deploy a LightSwitch application to Azure websites. But first, you may be wondering what the heck is an Azure website and what’s the difference between that and a cloud service? LightSwitch applications can be deployed to both through the Publishing Wizard, but why would you choose one over the other?

Azure Cloud Services provide reserved, infinitely scalable, n-tier options running on a Platform as a Service (Paas). Azure Websites are for quick and easy web application and service deployments. You can start for free and scale as you go. So if you do not need all the other services like caching, blob storage, CDN, etc. that the Azure cloud services provide and you only have a LightSwitch application to deploy, then an Azure website is the right choice.

If you’re interested in deploying to cloud services see Andrew & Brian’s post: Publishing LightSwitch Apps to Azure with Visual

For detail click here

How add two xaml to aspx page

You can have one Silverlight application project (one xap file).  Assume it contains two UserControls Page1.xaml and Page2.xaml, and you want Page1 to be shown in Silverlight Control1, and Page2 to be shown in Silverlight Control2 in the same aspx page.

You can use initParams in the Silverlight control tag to indicate which UserControl you want to use as the application start up page:

Code in App.xaml Application_Startup:

private void Application_Startup(object sender, StartupEventArgs e)



string page = e.InitParams[“Page”];

if(page == “Page1”)

this.RootVisual = new Page1();

if(page == “Page2”)

this.RootVisual = new Page2();



Send free SMS API


Required Params : uid, pwd, phone, msg.

uid : your userid for the required sms provider
pwd : your password for the required sms provider
provider : way2sms(default), fullonsms, smsindia, whozzat, smsinside, site2sms. if you do not specify any provider, way2sms will be used by default.
phone : phone number whom you want to send sms. seperate multiple phone numbers with a comma (,)
msg : your sms message, unlimited chars. will be sent as multiple msgs if crosses the message length for any provider

Optional Parameters
codes : 1. Send this if you require a user friendly msg from the server. for example, if codes=1 is not provided the server will return the result as an integer.
1 – SMS sent
-1 – Server Error
-2 – Invalid Username
-3 – Invalid message text
-4 – Login Failed
-5 – IP Blocked

JavaScript to redirect to https

function RedirNonHttps() {
    if (location.href.indexOf("https://") == -1) {
        location.href = location.href.replace("http://", "https://");

Then, simply call the RedirNonHttps function on page load :