In an Asp.Net Web API (not core) application we are using the regular OAuthAuthorizationServerProvider to expose the \token call. This is a forms post per standards. One of our development machines has started returning this string in unicode.
I have tested the normal api json calls and those are returning normal text. It seems to only be the token call from the forms post. Only on this single machine... sadly it is my own machine. Frustrating.
Has anyone else seen this? and corrected it?
found my own answer and felt silly. wanted others to see... I just had to enabled WebDAV publishing. I have no idea what turned it off but it was off.
Related
I have a DNN website and also a WebAPi.
In the past both wasn't related.
I'm finding a way to do something that related them.
Such as getting all users in DNN website,Create a user,Change password via WebAPI.
DNN has its own implementation of WebAPI allowing you to create extensions that are then exposed with WebAPI.
The implementation of this process is more complicated than can be answered in a simple StackOverflow post, but the DNN Wiki Information should help get you going. Once you get going you can ask more specific questions here.
I am new the webAPI2, so please excuse me if my question is trivial. I want to implement token based security for my webAPI, so that other applications (apart from my SPA) can also call my webAPIs.
I started with Owin OpenAuth and implemented a POC. Everything worked well. But when I had to send client to Authorization to Authorization server, I could not find any inbuilt function to do that. I had to build this my self. Then I came across DotNetOpenAuth that provides APIs to set the communication as well. As far as I could find out, Microsoft is favoring Owin OpenAuth over DotNetOpenAuth.
Can anybody please provide the differences between these two? Also, which one is recommended?
Thanks In Advance
Brock Allen answered a similar question here
The OWIN middleware is grated more for just the protocol bits, but has
none of the necessary persistence bits (or replay protection or
refresh token support or many other things). If you are interested in
working directly with the protocol because you want to learn it and
really learn how to build a server, then the OWIN middleware is an ok
place to start. But if all you want is a sever that already has all of
those pieces implemented, then consider looking into IdentityServer
or DotnetOpenAuth
I am trying to build my own WOPI host using ASP.NET MVC and its WebAPI functions according to this example
https://code.msdn.microsoft.com/office/Building-an-Office-Web-f98650d6
I successfully used that example to connect to my Office Web App Server and I can use that to access files of Excel and PowerPoint in local path and I am able to edit it, but I cannot use it to open word document in editing mode as the Post action handler isn't implemented completely without any response so that it cannot handle any edit request.
In order to add support for editing of Office document, I tried this example with POST request handler based on Cobalt library extracted from Office Web App Server.
https://github.com/marx-yu/WopiHost
With this example I managed to edit ans save all kinds of document with Office Web App Server. However, when I tried to integrate these two together I found that even if I can enter the edit window of Excel and PowerPoint and I can see that Post Requests from Office Web App Server like locking and Cobalt are handled by my WOPI Post API action handler. Those change doesn't take any effect on my local file at all. Moreover, I still cannot edit word document and when I checked the back log of Office Web App Server, I found the error message is Cobalt is not supported while I have already set the SupportsCobalt in CheckFileInfo response to true! Any help is very appreciated!
I think I have exactly what you are looking for. Check out my implementation of the WOPI host. It's an MVC6 app that takes the best from the both examples you are referring to and adds some extra features.
I've run come across a behavior with HttpWebRequest that I believe is intended, but as I have not been able to find any source that definitively says this is correct, I thought I would post it as a question and see if anyone has encountered this and/or can verify this is correct.
For starters I have an MVC3 app running on IIS 7.5. It has 1 controller and supports 1 post method. I have Windows Auth and ASP.NET Impersonation enabled within IIS. The idea behind the MVC3 app is just to have a simple service that can be used for logging information from a variety of client applications(console apps, silverlight, asp.net, AJAX, etc). One of the things the service does is uses the User property from the controller to also log who the person who posted data to this service.
To simplify the processing for the consuming applications I created some client libraries, Silverlight, DotNet, and a js library.
This all worked out as expected except when using the DotNet library within another MVC3 application. For the DotNet library I'm using an HttpWebRequest and using the asynchronous methods (Begin/EndGetRequestStream)/(Begin/EndGetResponse) to post the request. I'm also setting the .Credentials on the request to CredentialCache.DefaultCredentials, but when the logging application starts the processing of the request from another MVC3 app it shows the User as the service account of the app pool from which the post was received.
When I found this I added a synchronous version of the post to the DotNet library and found that the logging service was using my personal credentials.
I assume that HttpWebRequest could be using different DefaultCredentials depending on the context in which it is used. Since this is asp.net and the async method of the request are being called, my library code may not have even finished before the client MVC3 app has returned a response.
What I haven't been able to find is if this is definitively the case or not. If anyone has and answer or or an article that could point me in the right direction I would greatly appreciate it.
Thanks in advance
What I was encountering was intended behavior. The root of the problem comes down to under which identity do threads from the .Net thread pool execute when servicing the asynchronous requests. In my case the threads were executing as the owner of the app domain that was created by the app pool. In my case it was a service account.
I was able to capture the identity of the impersonated user prior to the start of any asychronous processing and use the WindowsImpersonationContext to force my library code to run as the impersonated user. By doing this CredentialsCache.DefaultCredentials used my credentials(impersonated user) instead of the account running the app pool when setting it on the HttpWebRequest instance.
I'm having a really hard time trying to find a resource or online tutorial that explicitly walks you through setting up a WF4 workflow activity that can call out to an external web service. All the videos and online samples I've come across simply demonstrate how to consume a web service that's part of your Visual Studio solution, but my situation entails calling out to a web service on a non-Microsoft server.
I have a service reference added to my VS2010 workflow console project for the web service in question, and it's pointing to the WSDL of the external web service. So far, so good (I think). I have a very basic workflow sequence, using a SendAndReceiveReply workflow control to communicate with the external server, and I believe I have the Send piece configured correctly. The ReceiveReplyForSend is giving me trouble, however, and I'm not sure if I have its Content options set up the right way. I'm invoking an operation called FileCheck, which at the moment for testing purposes always returns a value of 1 like this:
<SOAP-ENV:Envelope>
<SOAP-ENV:Body>
<FileCheckResponse>
<FileCheckResult>1</FileCheckResult>
</FileCheckResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
If I try to run this, however, I get the error "Badly formed SOAP message." For what it's worth, my ReceiveReplyForSend has a single parameter set up called FileCheckResult, though I don't know if that's the correct way to get the above value.
I can put a breakpoint at either activity, but I have no idea how to see what the SOAP call looks like at that point. Can someone either give me some workflow Send/Reply debugging tips or point me in the direction of an excellent step-by-step tutorial of how to consume an external web service in WF4?
Update on Feb. 2, 2011: Thanks to Maurice's suggestion, I see exactly what is failing now. The web service call in my workflow is failing because Visual Studio is generating a reference to the wrong namespace in my workflow Send call. Here is the single bit of XML that is wrong in the SOAP message - I'll leave off the rest of the SOAP envelope for succinctness:
<FileCheck xmlns="http://tempuri.org/">
This is what the WCF Test Client generates, which gets a successful message in return:
<FileCheck xmlns="http://someserver.org/test/" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
This is probably a really newbie question, but is there a setting somewhere that I'm overlooking that adjusts the xmlns value? I tried searching for "tempuri" in my project, but it's nowhere to be found, so I bet I'm overlooking a default setting somewhere.
Update on February 8, 2011: Maurice's latest tip did the trick! I needed to add the proper namespace to the ServiceContractName property for my Send workflow activity.
Adding a reference to an external web service is not much harder than one that is part of the same VS2010 solution. Only in this case you need to provide the URL where VS2010 can find the web service WSDL. As the communications mechanism is standard WSDL and SOAP there should not be a problem in calling the other service.
If you want to debug messages the best tool to use is Fiddler. It will let you see messages on the wire and even build request on the fly. If you have an existing client that can work with the service in question you can monitor its messages and compare them with the messages you are sending. Provided the service doesn't use complex and custom data types the WCF Test Client is a good way to check if the service responds with a standard .NET client app.
The SOAP namepsace is part of the ServiceContractName. Use the following syntax
{http://someserver.org/test/}FileService