Develop Reference

c# web api as jira webhook url

I have been tasked to implement a JIRA SMS notification(using Twilio) similar to its in-built email notification. I know this can be easily done using Zapier and Twilio.
But i am told to look for a workaround with out using Zapier.
The only option i think of now is to create a WebApi project that calls Twilio to send the SMS, host the WebApi project on a server and pass this URL as a WEBHOOK in JIRA.
For this i have created a C# class library which calls Twilio.
class
and after that i have added a new WebApi project for this solution and added the above class project reference.
and i have added a new controller:
controller
i am just calling the send method from the constructor with out any parameters which i think will do the job just from hardcoded number to a given number(in the controller.
but what i need is to pass in messageBody and recipientPhoneNumber from the JIRA webhook to this controller. Not sure how to do this.
As i am very new to WebApi's could some one please help me with the code. much appreciated.

Twilio Dev Evangelist here...
Mind dropping me a note at corey#twilio.com? I agree with the previous responses - this site may not be the best forum to support what you're looking for here, but I would be more than happy to directly help you out here.

but what i need is to pass in messageBody and recipientPhoneNumber from the JIRA >webhook to this controller. Not sure how to do this.
The way webhooks work is a little bit different than your assumption above. You cannot pass anything to JIRA webhook. JIRA POSTs data to the webhook (your API URL). Once you receive the data in your API controller action, you can construct a message body and recipient phone number (from e.g. user object passed in by JIRA; if that object doesn't have any phone number attribute, you might have to use a custom field).
As i am very new to WebApi's could some one please help me with the code. much appreciated.
No problem. I guess you have done the Twilio part alright already. Please visit MS docs to know more about Web API. You have to add a controller method so that it can be called by JIRA. So your final URL becomes this. You can then put this URL in JIRA as webhook. Replace hostname mycompany.com by your server hostname and change other url segments based on your situation.

How to call Microsoft Graph Beta API from C#

I tried to get the content of the user's profile picture and I found out that I had to call the Beta version because the current version gives the following error message:
"code": "GetUserPhoto",
"message": "The operation is not supported."
So, I tried to switch to Beta, and here is the code that I wrote in C# to do it, but it doesn't work:
Microsoft.Graph 1.6.2
List<QueryOption> options = new List<QueryOption>
{
new QueryOption("$api-version", "beta")
};
var pictureStream = await graphClient.Me.Photo.Content.Request(options).GetAsync();
I got the same error message.
I tried the same request in the Graph Explorer. The 1.0 doesn't work, but Beta works.

The api-version query parameter is used by the Azure AD Graph API. This is a different API than Microsoft Graph. There is a lot of functional overlap (Azure AD Graph is slowly being migrated over to Microsoft Graph) but they use entirely different entities and calling conventions.
In order to call the /beta endpoint using the Microsoft Graph .NET Client Library, you need to change the BaseUrl of the client:
graphClient.BaseUrl = "https://graph.microsoft.com/beta";
var pictureStream = await graphClient.Me.Photo.Content.Request().GetAsync();
Some important notes about the /beta endpoint:
It isn't supported and isn't suitable for production. So don't do that. Or at least don't tell anyone and don't call Support if it stops working. ;-)
The .NET Client uses objects constructed off the production metadata. This means that any entities, actions or properties that were added in /beta don't exist in the models shipped with the SDK.
The .NET Client will ignore any values returned by Microsoft Graph that it doesn't expect to see. So if an endpoint returns a property that wasn't included in the production metadata (see #2), it will simply be ignored.
So long as you're only using a /beta to gain functionality but still expecting /v1.0 results, it should work okay. Photos for example only look at Exchange in v1.0 but look in both Exchange and Active Directory but still return the same result. In theory this means you should be able to swap /beta for /v1.0 without a problem.

I think you are still calling V1 endpoint. In fact, the Beta endpoint is not currently supported in the Microsoft Graph .NET Client Library. More info here.

There is an official beta client for Graph API now:
https://github.com/microsoftgraph/msgraph-beta-sdk-dotnet

How do I update the base URL for Twilio SHA-2 update

How do I update the Base URL that Twilio uses for the SHA-2 update? I don't see any place to do this. We use the Twilio Rest using .Net CSharp code.
Please advise.

Megan from Twilio here.
You can check your setup against this endpoint: api.twilio.com:8443. If a test command to that endpoint succeeds, then you should not be required to make any changes.
If your command fails, I would recommend following the instructions here. An example in C# (be sure to update your Account SID, Auth Token, the From Phone Number and the To Number):
var client = new TwilioRestClient(
"[YOUR_ACCOUNT_SID]",
"[YOUR_AUTH_TOKEN]",
"[YOUR_ACCOUNT_SID]",
"2010-04-01",
"https://api.twilio.com:8443/");
var result = client.SendMessage("[FROM_PHONE_NUMBER]", "[TO_PHONE_NUMBER]", "Your system is ready for the upcoming change to the Twilio API's SSL certificate. No further action is needed");
If the above fails:
Outside of syntax errors, most likely your SSL libraries need to be updated. There is an SSL library on your server, and by the way it is not exactly the same thing as a Twilio helper library that you are probably using. You'll need to make sure your SSL library is up to date by December. If you are using a cloud provider, they can help confirm. If you are hosting yourself, your IT should check - if it is OpenSSL, for example, you should see if you can get it up to date.
Hope this helps.

Getting the list of youtube channels for the authenticated user

I am trying to display YouTube analytics data in a .Net application (Asp.net MVC 4 to be specific) using the google api .net client
The only sample I could find for this was a JavaScript sample located here for the most parts I was able to recreate the code in .Net, The only problem is that I don't seem to be able to find the counterpart for this lines of code which returns a list of Channels for the authenticated user:
var request = gapi.client.youtube.channels.list({
// "mine: true" indicates that you want to retrieve the authenticated user's channel.
mine: true,
part: 'id,contentDetails'
});
which should be then used here in my code:
var request = youtubeAnalyiticsService.Reports.Query(
"channel=="+ channelId, fromDate, toDate,
"views,likes,dislikes" // metrics to include in report
);
What I currently do to get it to work is to copy and paste the channel Id here and therefore "hard-code" it which is not practical in this my case and used only for testing purposes.
Hopefully I'm wrong but after searching for hours I think that the .Net API might be missing this part, can anyone confirm this? and if true are there any alternatives for doing this in the .net application?
I also guess that there might be a straightforward way to just use that part of the JavaScript code in the .net application but I'm not sure how!
Any help, hint or clarification would be much appreciated :)

This should work, assuming you've already got OAuth 2 setup and youtube is a YouTubeService object that's been properly authorized:
ChannelsResource.ListRequest channelsListRequest = youtube.Channels.List("id");
channelsListRequest.Mine = true;
ChannelListResponse channelsListResponse = channelsListRequest.Fetch();
string channelId = channelsListResponse.Items[0].Id;

Consuming a web service using POST instead of the going the usual WSDL route

This is how I have currently managed to consume a particular Microsoft web service. Notice that it is located on an HTTPS server and that it requires a username, a password, and a .cer file to be installed in the operating system's "root certificate authorities".
WSHttpBinding binding = new WSHttpBinding();
binding.Security.Mode = SecurityMode.TransportWithMessageCredential;
binding.Security.Message.ClientCredentialType = MessageCredentialType.UserName;
binding.Security.Message.NegotiateServiceCredential = true;
binding.Security.Message.AlgorithmSuite
= System.ServiceModel.Security.SecurityAlgorithmSuite.Default;
binding.Security.Message.EstablishSecurityContext = true;
EndpointAddress endpoint = new EndpointAddress("https://address.of.service");
//"GreatClient" was created for me automatically by running
//"svcutil.exe https://address.of.service?wsdl"
GreatClient client = new GreatClient(binding, endpoint);
//Username and password for the authentication. Notice that I have also installed
//the required .cer certificate into the system's "root certificate authorities".
client.ClientCredentials.UserName.UserName = "username";
client.ClientCredentials.UserName.Password = "password";
//Now I can start using the client as I wish.
My question is this: How can I obtain all the information necessary so that I can consume the web service with a direct POST to https://address.of.service, and how do I actually perform the POST with C#? I only want to use POST, where I can supply raw XML data using POST directly to https://address.of.service and get back the result as raw XML data. The question is, what is that raw XML data and how exactly should I send it using POST?
(The purpose of this question: The reason I ask is that I wish to consume this service using something other than C# and .NET (such as Ruby, or Cocoa on Mac OS X). I have no way of knowing how on earth to do that, since I don't have any easy-to-use "svcutil.exe" on other platforms to generate the required code for me. This is why I figured that just being able to consume the service using regular POST would allow me to more easily to consume the service on other platforms.)

What you are attempting to do sounds painful to do now and painful to maintain going forwards if anything changes in the server. It's really re-inventing the wheel.
If you haven't considered it already, I would:
(a) Research whether you can use the metadata you have for the service and use a proxy generator native to your target plaform. There aren't many platforms that don't have at least some tooling that might get you part of the way if not all of it. Perhaps repost a question targetting Ruby folk asking what frameworks exist to consume an HTTPS service given it's WSDL?
(b) Failing that, if your scenario allows it I would consider using a proxy written in C# that acts as a facade for the service which translates it into something easier to consume (for example, you might use something like ASP.NET MVC WebAPI which is flexible and can easily serve up standards compliant responses over which you can maintain total control).
I suspect one of these may prove easier and more valuable than the road you are on at the moment.

I had to go through something similar when porting .NET WCF code to other platforms. The easiest approach I found was to enable message logging on the WCF client. This can be configured to save both envelope and body and once everything is working on the .NET side of the house, you can use the message log to have "known-good" XML request/response to port to other platforms.
I found this approach to be more elegant since I didn't have to add an additional behavior to log messages, and it can be easily enabled/disabled/tweaked in the config. The Service Trace Viewer Tool that ships with Visual Studio is also handy for reviewing the log files.

I think when you say that the service should be consumed from other platforms, which do not have proxy class generation logic, you can go with REST services. This will allow you to create input as simple string concatenation instead of complex XML. Though its applicability depends on the situation.
Check this discussion : http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/6907d765-7d4c-48e8-9e29-3ac5b4b9c405/
As far as the certificate is concerned, refer http://msdn.microsoft.com/en-us/library/ms733791.aspx on how to configure it.
I know this is not a very precise answer, but you will be the best person to evaluate above procedure, hence posted. Hope it helps.

What I'll do:
1- Create a small c# app that can post on this webservice (using svcutil). And modify it to show the XML send/received. To view the xml there are several ways: logging, wireshark etc. To add it directly to the small app there is another question here that give a good answer.
2- Once you know what you have to send, you can do it in c# like this:
// implement GetXmlString() to return the XML to post
string xml = GetXmlString();
// create the url
string url = new UriBuilder("http","address.of.service",80).ToString();
// create a client object
using(System.Net.WebClient client = new System.Net.WebClient()) {
// performs an HTTP POST
client.UploadString(url, xml);
}

I'm not a .NET programmer but I've had to interoperate with a few .NET services and have lots of SOAP/WSDL experience. Sounds like you've captured the XML for your service. The other problem you'll face is authentication. OOTB, .NET web services use NTLM for authentication. Open-source language support for NTLMv2 can be hit and miss (although a quick google search pulled up a few possibilities for ruby), and using NTLM auth over HTTP may be something that you have to wire together yourself. To answer a question above: where are the auth creds? If the service is using NTLM over the wire, authentication is happening at some layer below HTTP. If the service is using NTLM to authenticate HTTP, your NTLM creds are in the HTTP Authorization header. You should be able to tell with wireshark where they are. You'll also probably need a SOAPAction header; this can also be sniffed with wireshark. For the C# client, I'm sure there are docs explaining how to add headers to your request.