I'm trying to retrieve inbound messages from the API on Mandrill, but when I call the sendRaw method, the API fails with an error saying I need to specify a raw message value. I guess the SendRaw is sending the message I specify, rather than returning the message I request?
static async Task<string> SendRaw(string key)//,string )
{
string sendRaw = mandrillAPI + "inbound/send-raw.json";
HttpClient client = new HttpClient();
client.BaseAddress = new Uri(sendRaw);
HttpResponseMessage response = await client.GetAsync(key);
string s = await response.Content.ReadAsStringAsync();
return s;
}
The raw message is the content I'm trying to retrieve, so I don't see how I can supply it.
Is there a way to retrieve messages from the server using the API? And if that is the wrong way to say it...lets put it this way: I set up a domain with Mandrill and sent a message to a fictional mailbox on that domain. The server relayed the message--I can go on the Mandrill dashboard and see the SendRaw API call for the message. I would like to retrieve the message from where-ever it is located...whether it is located on Mandrill's servers or whether it was sent to my domain where I needed to have something listening for the send, I don't know. I'm very new at this (circa yesterday). Either way, I need to get that message. Is it possible to do it using the API?
Or is Mandrill just relaying the message to my url when it is originally sent, and I need to set up the url to receive the message in order to get it?
Inbound mail can't be retrieved through the Mandrill API. Inbound mail is received by Mandrill, converted to an inbound/send-raw API call, and then POSTed to the webhook that you've specified for your inbound route. Mandrill doesn't store the message contents for API retrieval. Once they're POSTed to your webhook URL, the message is discarded. Note that inbound/send-raw is different than messages/send-raw. The inbound/send-raw API call allows you to mimic what would happen if you sent a message to a route that you've set up (ie, POSTing to the webhook URL).
More information about how inbound mail works and the webhooks can be found in the Mandrill KB: https://mandrill.zendesk.com/hc/en-us/categories/200277247-Inbound-Email-Processing
Related
I have successfully connected to Microsoft Graph using OAuth. I can receive and send emails from my Office365 account.
But I am completely stuck on how to receive emails automatically, similar to the IMAP IDLE routine.
I am referencing
using Microsoft.Graph;
using Microsoft.Toolkit.Services.MicrosoftGraph;
I have tried Subscription but have no clue what to do next, or even if this is correct.
Subscription sub = new Subscription {
ChangeType = "created",
NotificationUrl = "urn:ietf:wg:oauth:2.0:oob",
Resource = "/users/me/messages",
ExpirationDateTime = DateTimeOffset.Now.AddMinutes(20),
ClientState = "????" // if applicable, what is this
};
To make a subscription you need to expose a notification URL with https (see graph documentation).
POST https://graph.microsoft.com/v1.0/subscriptions
Content-Type: application/json
{
"changeType": "created,updated",
"notificationUrl": > "https://webhook.azurewebsites.net/notificationClient",
"resource": "/me/mailfolders('inbox')/messages",
"expirationDateTime": "2016-03-20T11:00:00.0000000Z",
"clientState": "SecretClientState"
}
If you want examples the graph documentation references a Node.js and asp.net example. Both use ngrok to expose an https URL (just for testing purposes though). The program tunnels HTTP requests through to your localhost (like a reverse proxy). If you have that setup, you have to validate your request. When you send your subscription request the first post message your notification URL will receive is a message with a validation token (see doc). You have to send this validation token back. Now you should receive notifications on your specified notification URL.
You can read about the Subscription resource type and its properties in the graph documentation.
For example, the client state is described as:
Specifies the value of the clientState property sent by the service in each notification. The maximum length is 255 characters. The client can check that the notification came from the service by comparing the value of the clientState property sent with the subscription with the value of the clientState property received with each notification.
Subscriptions are not in possible at this moment using Microsoft Graph for UWP, for notifications the Outlook 365 API should be used. The Microsoft graph api can be used for Auth and other tasks though.
Can Microsoft consider including streaming notifications in Microsoft Graph?
Can you with SignalR send information the client who has send the request? Here I've quickly draw the current situation with paint:
The client send a SignalR request to the server with
meldingenHub.server.vote();
and the server send a message back to all the clients with
Clients.All.SendOke();
The situation I will have is that only the sender of that request, receive the message I send form the server. All the other clients don't receive that message. Is there something I can use like this:
Clients.Sender.SendOke();
When the Server method is invoked, there is a Context object populated with the details of who called the method. There is a property in here called ConnectionId which has the identifier of the caller.
So to invoke a method only on the sender's client, simply call:
await Clients.Client(Context.ConnectionId).SendAsync("ClientMetodName");
What you need to do is send the connection id of the sender to the hub and then use Clients.Client(connId).broadcastMessage(....) see THIS other answer for an example.
Okay I'm developing a sevice application that runs on Cisco IP Phones. The application involves displaying messages to the phone.
I would like to make use of the way CISCO phones use the Expires header in a http Response. Basically a message i send to the phone will expire when the time specified in the header is reached (expired messages are removed from the message stack). The full documentation can be read at this address
http://www.cisco.com/en/US/docs/voice_ip_comm/cuipph/all_models/xsi/3_3_4/english/programming/guide/ip334ch5.html#wp1030621
In my C# WebService i construct the response using a HttpResponseMessage. Before i return my response i add the Expires header using
response.Headers.Add("Expires", "-1"); //Immediately expires.
My problem:
The previous line of code throws an InvalidOperationException
with the message Make sure request headers are used with HttpRequestMessage, response headers with HttpResponseMessage
I believe that the HttpResponseMessage is performing some validation and that Expires is not a valid response header. But its what the CISCO stuff requires.
Can i force this key value into the header even though its not strictly correct HTTP
The Expires header is on the Content object.
response.Content.Headers.Expires = new DateTimeOffset(DateTime.UtcNow.Add(new TimeSpan(0,0,0,5)));
We're consuming a web service (web reference, not service reference), and I need a way to output the entire message being sent (including headers) and the message that gets received.
When I add the web reference, the generated base type of the client object to send the messages is System.Web.Services.Protocols.SoapHttpClientProtocol
I send the messages like so:
ApiService api = new ApiService();
// set the certificate and basic http network credentials
var response = api.SendRequest(messageObject);
I'm able to get the body of the request by serializing messageObject, but can't figure out how to get the full message with the headers.
Since I'm using a certificate and basic authentication, tools like Fiddler, etc. aren't getting me what I need, so I believe I have do something programmatically to pull whats sent and whats received prior to being encrypted with ssl.
EDIT
What I want to see if the data being sent and received to another service from within my WCF service.... e.g.:
// this function is within my WCF service
public ResponseModel Auth()
{
// call to another service here... need to trace this
}
If this is for tracing purposes I have had some success using the tracing capabilities of the System.Net libraries, you should be able to enable the tracing through configuration only.
It's described here: How to: Configure Network Tracing
The resulting log file isn't the easiest to follow, but is described here: Interpreting Network Tracing
I'm creating a web test client for some services I'm working on, and as part of the requirements for that, I would like to be able to display the full request and response SOAP messages (and HTTP headers to the user).
I implemented a MessageInspector class implementing IClientMessageInspector, most notably the BeforeSendRequest and AfterReceiveReply methods to get access to the request & response messages respectively.
Capturing the response (AfterReceiveReply) works great, but capturing the request only partially works. I can access most of the message, however the SOAP header and HTTP headers are both empty. Viewing the request in Fiddler, I can see that WCF is sending a Security header in the SOAP message and "a bunch" of HTTP headers.
My BeforeSendRequest method is very simple...the gist of it is...
public object BeforeSendRequest(ref Message request, IClientChannel channel)
{
this.RequestMessage = request.ToString(); // Security header is missing from message
// Try to get HTTP headers
object req; // req is always null
if (request.Properties.TryGetValue(HttpRequestMessageProperty.Name, out req))
{
this.RequestHeaders = ((HttpRequestMessageProperty)req).Headers;
}
return null;
}
I'm not sure why the HTTP and Security headers are missing. Is there a better way to do this?
Wayne
The inspectors look at the messages right after the message exists the formatter, and before it reaches any of the protocol channels (such as security) which will (potentially) change the message before passing it over (see the diagram in the post about WCF channels at https://learn.microsoft.com/en-us/archive/blogs/carlosfigueira/wcf-extensibility-channels). So at the inspector level you won't be able to find any additional SOAP headers added by the message. The HTTP headers are added by the transport which is also reached after the message passes through the message inspector.
If you want to see all the SOAP headers in the message, you can either create a new "protocol" channel (the sample at http://msdn.microsoft.com/en-us/library/ms751495.aspx does exactly that) or a new message encoder (it can wrap the existing encoder, and inspect the outgoing messages right before they're encoded).
To be able to see the HTTP headers it's harder, since the transport is the last part through which the message passes in WCF. I think you could write a custom transport channel to do that, but that would definitely be a lot of code.