I have deployed Swagger UI (version swagger-ui-2.0.8) in tomcat. This will define a set of APIs which invokes services deployed in Tibco BW in another domain. so far everything worked perfectly fine but when we just implemented our Tibco BW service as SSL (uses **https**:xxxxxx:9090/user). Swagger send OPTIONS request since it is deployed in tomcat in another domain (CORS request). I have configured CORS for all responsee headers as "*".
The problem we have now is OPTIONS request from swagger does not have authentication header to hit BW service. How to achieve this. Please help
window.authorizations.add("Authorization", new ApiKeyAuthorization("Authorization", "Basic XXXXXXXX", "header"));
Thanks in Advance.
I think preflight OPTIONS request does have not to use authentication. Simply make the server respond to OPTIONS requests without any authentication.
Related
My week so far:
In the last couple of days i worked on deploying our identityserver4 .net core application to an Azure Kubernetes Cluster (AKS). After a few problems, everything seemed to work fine. We are not using the built-in http-routing functionalities because we don't want to route using subdomains and for some reason; we can't seem to get letsencrypt working when http-routing is enabled. We are using https:// to access the services hosted in AKS using nginx.
anyway..
The problems arose when i deployed one of our mvc clientapplications to AKS. The homepage of the client works as expected. When the client redirects me to the login page of our idsrv4 service, and i log in using my credentials: a redirect loop kicks in. I know this means that the authcookies aren't properly set.
The problem
I discovered that the authentication roundtrip works in Google Chrome and Firefox, no redirect loops in those browsers. Edge, IE and Safari don't work and cause redirect-loops when redirecting to signin-oidc.
Discoveries so far:
I tested the mvcclient application using my local docker for windows installation. Using HTTP connection - not https -, the roundtrip works in all browsers
When i use Fiddler with HTTPS decrypt to diagnose the roundtrip using the services hosted in remote AKS: the roundtrip works in all browsers
When i disconnect Fiddler and test the services hosted in remote AKS, the roundtrip doesn't work in Edge, IE and Safari.
Does anyone know how i can configure Nginx to support all browsers for setting cookies and forward the correct headers? What are the requirements for identityserver4 in this situation? is there any additional configuration rin nginx or cookieauthentication required in my clientapplication or identityserver4 (besides setting publicorigin in identityserveroptions in startup.cs)?
After i did a fresh install of a new AKS cluster and tryied once more to get Let's Encrypt working using the standard addon-http-routing, which i got working, i tried and tried and finally thought: why is my redirect to /signin-oidc registering as HTTP/2 in Edge and IE. This turned out to be the main part in a combination of the problems i had last week.... anyway: I did some research and figured out how to update some parts of the configuration to the built-in ingress controller (addon-http-routing). for anyone experiencing a signin-oidc loop when using AKS (Azure Kubernetes Service). You can overwrite the configuration for the standard http routing addon provided in AKS and disable http/2 manually (enabled by default!).
Because i got a bit frustrated by the fact that there was little information on the web for configuring an AKS cluster on Azure in combination with Let's Encrypt and addon-http-routing & because i couldn't find any information on deploying IdentityServer4 in an AKS cluster in Azure. I cooked up some .yaml files (all files i used to get everything up and running), expanded them with comments and published them for anyone wanting to host IdentityServer4 securely in an Azure Kubernetes Service.
This is my first, although small, public contribution ever. If anyone has problems implementing my .yaml files using my rudimental Readme.txt: please let me know and i will see what i can do.
https://github.com/leonvandebroek/Identityserver4-deployments/tree/master/Azure%20Kubernetes%20Service
I have an api hosted on IIS that I am trying to call through a Blazor.Net client app with the HttpClient as provided in the example.
Since the api endpoint is hosted on IIS with windows authentication, I need to include credentials when the call is made.
I tried to create an instance of the httpClient instead of using the static method provided in the examples but I receive the PlatformNotSupported exception.
Is there a way to pass credentials with the Static HttpClient as used in Blazor.net?
If I use JavaScript interop with XMLHttpRequest and set withCredentials to true, the api returns data. However I would rather not use js to get the data but rather C#.
Thanks,
Normally the browser should take care of this, that's why you need a browser that is Windows Authentication compatible. See here for an explanation of how Windows Authentication interacts with the browser.
So if that does not work by default, I guess Blazor/Mono does not supports this yet. But you are able to include your own authorization headers in the http call in blazor. I have an example here how to do that (for a jwt token). So if you are able to somehow get the Windows token from somewhere you could try that.
I am trying to use BreezeJS with an existing OData server, that was implemented using .NET System.Services.Data.DataService, Version 4.0. As it seems, BreezeJS is doing a http OPTIONS request to get $metadata, but the server throws a NotImplemented exception.
When I manually request $metadata using http GET in the browser, I am getting (XML formatted) metadata fine.
Is there a way to configure Breeze to use http GET or would I need to somehow adjust the server to support http OPTIONS?
Any help would be appreciated.
The OPTIONS request is part of CORS, as explained in this answer. You need to configure your server to support CORS, or don't use cross-origin requests from the browser.
See this answer and this answer regarding using WCF with CORS. It seems the recommendation is to switch to Web API.
How can I use an existing webapi service with breeze? Note that my webapi service resides at "server1/api" and the web application is at "server2". I tried changing the service name in the dataservice, but get an XMLHttpRequest Exception 101. This is a cross domain error. Is it possible to use breeze with a webapi service from another domain?
Cross-origin Breeze Apps
Yes it is possible to get the Breeze client app from one server and have that Breeze app communicate with a data service hosted on a different server.
A Breeze client app runs cross-origin quite well on a CORS-supportive browser when the service is configured for CORS.
Cross-origin issues and CORS solutions are in a more general category of web security problems. They aren't Breeze-specific. We plan to post a topic on CORS + Breeze in the "Cool Breezes" section of the Breeze web site.
UPDATE: 10 Dec 2013
This sample uses a primitive CORS implementation that we no longer recommend if you have upgraded to Web API2. Please read this excellent article "CORS Support in ASP.NET Web API 2" which explains basic CORS and how to engage Web API2 CORS support.
The rest of this answer remains as originally written.
Todo Sample with CORS
Until then, take a look at the code for the Todo Sample. The server for that sample is setup for CORS, has been deployed to todo.breezejs.com, and you can see it in action by looking at the jsFiddle at the bottom of the Breeze Todo Sample topic page.
Four points of interest:
App_Start/BreezeSimpleCorsHandler.cs does the work
App_Start/BreezeWebApiConfig.cs turns it on
// CORS enabled on this server
GlobalConfiguration.Configuration.MessageHandlers.Add(new BreezeSimpleCorsHandler());
A Web.config line you'll need for IIS7 (not needed for IIS8 or VS2012's IIS Express)
Scripts/app/dataservice.js is ready to point to a foreign server; see this line:
// * Cross origin service example *
//var serviceName = 'http://todo.breezejs.com/api/todos'; // controller in different origin
Hope that tides you over for now.
I have a Rails website that allows an authenticated client to post XML to a specific URL. In this particular instance, the post request is coming from a BizTalk 2009 server. Rails keeps responding with 401 Unauthorized and I'm not sure why.
The authentication on the Rails side is handled by Restful Authentication via HTTP basic auth. I have tested posting XML to the production site using curl and the credentials of the client in question and it appears to work fine. The owner of the BizTalk server and I have verified the credentials and the URL.
Is there something particular about the way BizTalk handles its basic authentication? Or is there something weird with Rails or Restful Auth? Any ideas? The web server on the Rails side is Nginx with Passenger 3.
What credentials are you using to authenticate? It would need to be that of the BizTalk service account that is sending the request. What adapter are you using?
Unfortunately, the problem went away undetected. I had to modify the auth code to deal with authentication problems in Internet Explorer (see http://rails_security.lighthouseapp.com/projects/15332/tickets/5-using-http-basic-authentication-with-ie-not-working). It's possible that BizTalk would have the same problem, but I can't verify.
It's also possible that the owner of the BizTalk server updated the credentials used to contact our service, but again I can't verify.
As we have bigger fish to fry, it's not worth it to us to track down the exact issue since all is working fine now. Of course that could change and I'll dig deeper and perhaps update this thread.