My team and I are working against a few webservices that require SOAP Message Headers to be available when making a request. We are not in control of these webservices so we can't change the implementation, even if we wanted to (or at least not without a lot of pain). We just need to be able to have authentication related information & a couple of other items passed through our message headers.
I've read of a few people who've had this problem in the past with no clear indication on if they succeeded in pulling it off on Monotouch.
Here's what I've read: http://forums.monotouch.net/yaf_postsm2104.aspx so far.
Any ideas on what we can do to overcome this on the Monotouch framework?
Here's what i'm trying to do for now:
using (var scope = new OperationContextScope (client.InnerChannel))
{
client.GetHistories += handler;
OperationContext.Current.OutgoingMessageHeaders.Add (MessageHeader.CreateHeader ("EnvironmentInfo", "http://schemas.contoso.com",
ServiceContext.Current.OperatingEnvironment));
OperationContext.Current.OutgoingMessageHeaders.Add (MessageHeader.CreateHeader ("AuthenticationToken", "http://schemas.contoso.com",
ServiceContext.Current.Token));
client.GetHistoriesAsync (ServiceContext.Current.OperatingEnvironment, ServiceContext.Current.Token, request);
}
Thanks for your time.
JM
I was not able to get Message Headers to work with WCF in Mono 2.6. I tried several different ways (including how you do it in your example) - it just doesn't work in Mono 2.6.
I raised a bug for this, which I then closed after discovering it is fixed in the latest trunk. So if you run against Mono 2.7 or greater, this should work.
Related
I have some rest and GraphQL services works with ruby and typescript (with nestjs framework).
I've noticed that a couple of days ago some of the POST requests failed due to params validation error.
After further investagaion, it seems like on some requests the body params sphoradicly drops from the requests somewhere on the network. It happen for small amount of requests (less than 1%).
This issue started when no changes deployed on the server or clients side. My clients are iOS and android apps and it happens for both platforms.
I've tried to find the exact point on the network that the body dropped, with no success.I've also tried to find a solutions to similar issue on the net.
Does anyone have any idea what can it be? I haven'e found any relevant information about similar issues.
Thanks!
I have a strange problem whereby any REST APIs relating to SharePoint versions work when testing at design time but generate a 403 Forbidden error at runtime. What is also odd is that all other REST API calls work fine at both design time and runtime and all the parameters are identical to the ones that don't work (headers etc.) and I've done a cut and paste on everything, but still anything relating to versions isn't working, although that might just be a red herring?
The app can successfully delete files and overwrite them, check in and out, etc. so seemingly there are no permission issues. I have also tried checking a file out before reading the version information just in case (as check out is forced before any actions can be carried out on this site) but that didn't work either.
This is an example of one of the calls that is causing the error:
https://mycompany.SharePoint.com/sites/{SiteName}/_api/web/GetFileByServerRelativeUrl('/sites/{SiteName}/Shared%20Documents/{FilenameAndPath}')/version
Look at this post:
https://sharepoint/_api/web/folders/getbyurl('Documents')/files/getbyurl('myfile.docx')/versions?$filter=VersionLabel eq '2.0'
Check the Accept and Content-Type headers in the OnBeforeRequest REST API callback.
I have found that when testing the IDE will send for instance "application/json" for both, but at runtime, the platform adds ";utf-8" to the values of these headers. The requests are then often rejected without a proper error specification/declaration.
In upgrading from an older version of Jodd I cannot identify how to display the conversation between the server and the client. In the past I wrote:
smtpServer.debug(true);
imapServer.setProperty("mail.debug", "true");
Now I tried to use:
smtpServer.debugMode(true);
but it had no effect.
I could not identify how to do this with imapServer.
I like to show the conversation to my students.
Unfortunately, there was a bug in Jodd. The debug and timeout were not applied.
The bug was fixed in the latest commits, soon to be released.
At least, we introduced some improvements, so now on the debug & timeout methods would be applied for all servers, so you would not need to use different setting for the IMAP and SMTP server :)
After many support cases we are realizing the biggest problem we have with our GWT-based application is that users are leaving it open for weeks at a time. This means when we do a hotfix every week or two the RPC stubs are out of sync and cause silent exceptions to be thrown making the site look "broken". Does anybody know of a way to auto-detect and avoid this issue? A few ideas I have had are...
On catching an RPC mismatch exception refresh the browser.
When loading the host page inject the version number in source control the build came from, have a status checker/timer that check that the number did not change. When it does reload.
Reload on an arbitrary timer (perhaps twice daily).
Any ideas?
I'd like to present a fourth option.
Create an RPC Proxy and UI Object proxy that all UI requests and RPC requests are routed through. This way whenever this proxy detects that something is out of date it can dynamically load the widget or change it's expected RPC models.
This is pretty how Vaadin does things and it works great. Vaadin is a UI toolkit built on GWT in case you're not aware. We have several long running production applications using this over the last couple of years and we have made some tweaks in their UI Def language (UIDL) to add version mismatch.
This diagram is a good representation of what they do and if you don't want to build something like this yourself I'd of course recommend moving to Vaadin.
Implement security that logs users out after an hour of idle time. Assuming your releases are overnight or on weekends, the users are logging in after the release. No need to refresh the app.
this is viable especially if your site eventually needs users to login.
We made a simple application and using GoogleAppEngineLauncher (GAEL) ran that locally. Then we deployed, using GAEL again, to our appid. It works fine.
Now, we made a web service. We ran that locally using GAEL and a very thin local python client. It works fine.
We deployed that, and we get this message when we try to visit our default page:
"Move along people, there is nothing to see here"
We modified our local client and tried to run that against our google site and we got an error that looked like:
Response is "text/plain", not "text/xml"
Any ideas where we are falling down in our deployment or config for using a web service with google app engine?
Any help appreciated!
Thanks // :)
Looks like you're not setting the Content-Type header correctly in your service (assuming you ARE actually trying to send XML -- e.g. SOAP, XML-RPC, &c). What code are you using to set that header? Without some indication about what protocol you're implementing and via what framework, it's impossible to help in detail...!
Looks like we aren't going to get to the bottom of this one. Just not enough information available at debug time. We've managed to affect a fix on the service, although I hate ot admit it we never found out what was causing this bug.