I have a Web API using OWIN for OAuth, running in Katana/TopShelf.
When I install the Web API as a Windows Service, everything responds correctly, except a POST via resource owner flow (grant_type=password, username=x, password=y) returns 400 Bad Request (invalid_grant).
The exact same Web API, running in the same folder, except this time running in Command Line mode, using the exact same request from the same remote address, is successful.
The only delta is whether I run the .exe file directly in Console mode or I install and start it as a Windows Service.
I have to think this is a conflict at the network level but Windows Service is just acting as a thin host around the same HttpListener based host.
Whenever we see an issue like this with Topshelf it is almost always permission related. There's some resource that you have rights to but the service user doesn't. Are there resources on disk the service accesses or something similar?
Related
I have an UWP application one client cannot retreive data from the API. She had the application installed and working, but after an update this single client cannot access data from API, none of the API calls succeeds, all fails with error: A connection with the server could not be established.
We have checked the users internet-access and that the user has access to the API from that machine, we have tried Postman so the machine can access the API. But when the application tries to access API it does not reach the API.
I have checked the firewall and the app is allowed there on all three profiles. We have capabilities in the manifest for both internet and privateNetworkClientServer. (it works on all other machines, but stopped working after an update, not even older versions works from that machine any more).
The log files does not say anything either.
Where can I look for stuff that might block UWP traffic?
edit
We added the internetClientServer capability and then it worked.
I have two applications: one is WebAPI REST Service written on .NET 4.5, and another one is its client application written on .NET Core 2. There's a windows authentication enabled on the service side. Client one makes simple GET call using HttpClient with HttpClientHandler loaded with credentials from configuration, it is some service account. Very basic stuff that can easily be googled in tons of examples, there's nothing fancy there at all.
When this call is performed from my local dev laptop to DEV server then everything works as expected: user provided in the client's configuration gets authenticated successfully on the service and is able to perform whatever operations he is allowed to perform.
It also works fine if I perform this call from the browser (Chrome) - it asks me for credentials and then returns result that perfectly correlates with whatever credentials I put there. It works this way with both remote and local services.
However, if I run the service locally on my laptop (local IIS Server, not an Express one) and call is performed using localhost address then I observe strange behavior: windows authentication seems to work as well, but the user that service authenticates is not the one from client's configuration. Instead, it is my AD account with which I have logged on interactively in windows (btw, it's win 10 ent x64).
Of course, I've verified five times every single config setting and runtime value in my applications, all settings on local and dev server's IIS, on web application and IIS Server level and app pools used for apps. Everything I see looks good - except it behaves differently when on localhost. Also, I googled every question that I could imagine but still can't seem to find an explanation to this behavior.
So, why HttpClient uses my account on the localhost instead of explicitly provided credentials? What am I missing here?
Is it possible to make HTTP calls to applications outside of Azure from a web API running in Azure?
I'm trying to connect a ASP.NET web API in Azure to a wpf application that runs on a PC at my company. Both the applications request data from each other using HTTP calls with JSON. This works fine locally because i can use localhost but
when running the web API in Azure the web API can't reach the wpf application
I have looked into Azure Point-to-Site and Site-to-Site connections but most examples that i found show connection with a VM in Azure and nothing about web API's.
Thanks in advance!
I still don't get your scenario even after reading all the comments, however here's a shot in the dark.
First of all, no, there are no restrictions as to what destination you may call from Azure, yes that includes the dark web, although not necessarily a recommended destination for both traffic and tourism alike.
For the second part, if what you're calling is behind a firewall and your API runs in Azure App Service, take a look at Hybrid Connections, it's built as a solution to that exact scenario, no IPsec or firewall rules are in play. The connectivity from on-prem will be outbound.
I'm using a web service which works fine when I run it on my machine in an ASP.NET application using the default IIS Express VS 2010 comes with. However, when I move it to our server with IIS I get the error:
Error: There was no endpoint listening at 'web service name here' that could accept the message. This is often caused by an incorrect address or SOAP action.
'web service name here' is just a placeholder I put for this post. It has the right web service name.
So I pulled out the small login code that this is failing on into a console application and ran that from the IIS server and it worked! So I have to assume this is some kind of permissions issue with the IIS server on how it's running my web service code? In my ASP.NET program I have a separate DLL that handles the web service. The ASP.NET application fires off a separate thread that uses the DLL I made that uses the web service. Is it something to do with the separate thread permissions maybe? Any ideas?
Your first step when faced with this sort of issue is to search your config files for "web service name here" (or if this isn't actually the message you're getting the address given in the message). My suspicion is somewhere you'll have a WCF reference set up which needs a proper IP address.
Once you've got the address (assuming it looks valid) you need to check you can access it from the machine which is having the difficulties - it may be a firewall issue.
Now that you've established that your console application is connecting correctly from the same machine the next step is to check that both your IIS App Pool and Console application are running under the same user account/permissions. It may be that one identity has permission to access the network/internet and the other one doesn't.
Okay, I'm a very green developer (co-op student) so I'll try my best to make sense. Currently I have a web application (call it "Updater") that is an aspx and runs through IIS. My boss has asked my to look into creating a program (exe or command line) that can run the app through created encapsulated web server that can act like IIS. This is so that I can run the exe during an installer procedure on a client's machine so that the updater can configure the client's program.
So Far I've looked into sources upon sources on how to create a self hosted web server to handle a web app and I've managed to do the following:
-Create a command line server hosted at a given port #######.
-Use a StreamReader to read an html file
-Use HttpResponseMessage to set the Content to this html page.
Obviously this is very rudimentary, but I couldn't understand how to switch the app over to the server I created rather than the IIS.
Any help ont he matter would be appreciated, like I said I'm still quite new.
You can use OWIN to self host from within a console application.
Look for 'Self-Host OWIN in a Console Application' in the following link:
http://www.asp.net/aspnet/overview/owin-and-katana/getting-started-with-owin-and-katana
You need to start you self host server with the address your app is trying to contact. If your IIS is running with the default settings it should be http://localhost:80. Before you start the self host server you need to shut down your IIS website that is running on port 80. Two applications can not listen on the same port at the same time.
What you ask is a redistributable web server for ASP.NET. So, you might find interesting the UltiDev Web Server, formerly known as Cassini web server.
From their website:
UltiDev Web Server Pro (UWS) is an advanced, redistributable web server for Windows that can be use as a regular web server to host web sites and ASP.NET applications, or packaged with your ASP.NET web application and installed on your customers' systems along with your web app or site.