I am trying to customize the UI page on Azure B2C using an Azure storage blob using this article. It needs to be CORS enabled. I have tested it using test-cors.org and I know it is not but I do not know how to set it
Ther article uses https://wingtiptoysb2c.blob.core.windows.net/b2c/wingtip/selfasserted.html which I test and returns a 200 but mine does not
https://bookssorted.blob.core.windows.net/b2c/selfasserted.html
This article talks about using this PUT https://myaccount.blob.core.windows.net/?restype=service&comp=properties HTTP/1.1 but how do I run this?
EDIT: I am using Azure Storage Explorer and I have these rules set on the blob but it is still not returning a http 200 from test-cors.org
EDIT2: this is the url that makes the request to the authentication policy which loads the page that makes the request to load the blob
https://login.microsoftonline.com/bookssorted.onmicrosoft.com/oauth2/v2.0/authorize?p=B2C_1_bookssortedAuthenticationPolicy&client_Id=35f308cd-8914-4035-9f62-cec7600c1727&nonce=defaultNonce&redirect_uri=https%3A%2F%2Flocalhost%2Fbookssorted%2Fsecure%2Fsuccess&scope=openid&response_type=id_token&prompt=login
EDIT3: headers as requested
In order for a cross-origin request to succeed, the request must match the CORS configuration. This includes the request origin, request headers & exposed (response) headers. Any mismatch there would result in request to fail.
If the origin is known, then that URL must be specified (including protocol & port number if applicable) in the CORS rule. If the origin is not known and you can specify * as the origin and all URLs will be able to make such requests.
Same thing goes for request headers and exposed headers. Since different requests to Azure Storage make use of different request headers and return different response headers, it is advisable to set the value for these as * in the CORS rule. This will ensure that all request/response headers are accepted.
Related
I am looking for Integration of DocuSignApi with Angular. I am following these steps.
Angular Application
Backend Server using .net core Web API to handle and DocuSign api using nuget.
Can I achieve this?
Option 1 - Angular application - will hit - login method of middleware api application - middleware will communicate - docusign - after successful it will share details of logged in users.
Option 2 - Angular application - directly hit to docusign methods for this When I am doing like this
var url = "https://account-d.docusign.com/oauth/auth?response_type=token&scope=signature&client_id=XXXXXXXXXXXXXXX-01caXXXXXXXX&state=a39fh23hnf23&redirect_uri=http://localhost:81/";
return this._dataService.getThirdParty1(url, header)
.pipe(map((response: Response) => {
return response;
}));
- public getThirdParty(url) {
return this._httpClient.get( url).pipe().pipe(map(this.handleResponse)).pipe(catchError(this.handleError.bind(this)));
}
I am getting error
Access to XMLHttpRequest at 'https://account-d.docusign.com/oauth/auth?response_type=token&scope=signature&client_id=XXXXXXXXXXXXXXX-01ca8f1b220&state=a39fh23hnf23&redirect_uri=http://localhost:81/' from origin 'http://localhost:81' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: Redirect is not allowed for a preflight request.
account-d.docusign.com/oauth/auth?response_type=token&scope=signature&client_id=XXXXXXXXXX-411a-9bb9-01ca8f1b220&state=a39fh23hnf23&redirect_uri=http://localhost:81/:1 Failed to load resource: net::ERR_FAILED
Please provide a way to check these options.
First, your issue is that you are making client-side calls to DocuSign from a different domain which validated CORS policy which is a security concern.
(Cross-Origin Resource Sharing (CORS) is an HTTP-header based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading of resources. CORS also relies on a mechanism by which browsers make a "preflight" request to the server hosting the cross-origin resource, in order to check that the server will permit the actual request. In that preflight, the browser sends headers that indicate the HTTP method and headers that will be used in the actual request.)
Larry wrote extensively on this topic and here are some of the resources that can help.
Here is a three part series on the topic - https://www.docusign.com/blog/dsdev-building-single-page-applications-with-docusign-and-cors-part-1
Here is his code in GitHub showing you how to create a CORS gateway - https://github.com/docusign/blog-create-a-CORS-gateway
One other useful resource - https://www.cdata.com/kb/tech/docusign-odata-angularjs.rst
I have issues when trying to Post data to my API using ServiceStack's JsonServiceClient.
I get the following error message in the console
Access to fetch at 'https://192.168.10.191:5001/json/reply/CreateEquipment' from origin 'http://192.168.10.191:5000' has been blocked by CORS policy: Request header field headers is not allowed by Access-Control-Allow-Headers in preflight response.
I have added 192.168.10.191:5000 to the Whitelist.
I can see in the network tab that it tries to access "https://192.168.10.191:5001/json/reply/CreateEquipment" but nothing is showing when I capture the traffic using fiddler.
I have attached an image of the headers. https://i.stack.imgur.com/hUfII.png
Your requesting a https resource at port 5001 but your origin white list returns a http resource on 5000, they need to match.
I am learning Azure API Management and am seeing different response headers between Azure Portal, Developer Portal and Postman.
I'm doing an HTTP Get on this endpoint:
https://secondattempt.azure-api.net/speakers
With https://conferenceapi.azurewebsites.net/ as the web service URL.
I have compared them here:
Azure Portal:
Cache-Control
Pragma
Transfer-Encoding
Content-Type
Expires
Set-Cookie (not present)
Date
Op-Apim-Trace-Location
Vary
Developer Portal:
Cache-Control
Pragma
Transfer-Encoding
Content-Type
Expires
Set-Cookie
Date
Ocp-Apim-Trace-Location
Vary (not present)
Postman:
Cache-Control
Pragma
Transfer-Encoding
Content-Type
Expires
Set-Cookie
Date
Ocp-Apim-Trace-Location (not present)
Vary (not present)
And here are what they actually look like in the UI:
Azure Portal:
Developer Portal:
Postman:
Why are some headers present in some environments but not others?
Also, why are the headers appearing in different orders?
For Postman (Ocp-Apim-Trace-Location not present)
The OCP-Apim-Trace feature enables you to specify whether or not APIM should generate a trace file on blob storage.
While doing a GET request from Postman, OCP-Apim-Trace is not enabled.
Setting the header to 'true' within Postman, for example, will give you back an HTTP Header in the response called OCP-Apim-Trace-Location.
This will contain the URL to your trace file, which you can open in any browser.
For Postman and Developer portal (Vary not resent)
A request is not cached. Each request for a URL is supposed to be treated as a unique and uncacheable request.
For Azure Portal ( Set-Cookie not present)
See Trace and then forward request we do see "name": "Set-Cookie", "value": "ARRAffinity
Is there any reason to use an outbound policy in APIM? I tried a test where I used the same policy expression for inbound as well as outbound. The same expression worked without error and returned the same info for both. I don't see any need to configure an outbound policy if an inbound expression already captures all of the information. Have you also found the outbound section to be redundant and simply excluded the outbound section? Or have you found any reason to use the outbound section in addition to the inbound section?
Outbound policies can be used to manipulate/inspect a response body or headers returned from a backend API.
Examples of things you might do in an outbound policy:
Set the cache duration based on the Cache-Control header returned from the API
Remove headers created by the API framework like X-Powered-By and X-Aspnet-Version
Calculate an etag value using a checksum of the body
Create a signature header to prevent tampering with a response body
Update the returned response body with cached fragments
Log the returned response to a diagnostic system or audit trail
When enabling CORS on Azure blob storage, almost everything can be set but the "...Allow-Credentials" header, which is always true.
So when using a wildcard for the origin-header, the pre-flight request works fine and converts the wildcard into the actual origin.
But the subsequent GET request does not convert the wildcard and returns the following combination:
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
which is illegal in Chrome (and probably other browsers, too). The error is
XMLHttpRequest cannot load ...
A wildcard '*' cannot be used in the 'Access-Control-Allow-Origin' header when the credentials flag is true.
Origin 'http://localhost' is therefore not allowed access.
In the new WebAPI v2 CORS package wildcards are replaced with the actual origin.
Also, why would I need credentials such as cookies in a request to the blob storage? Better turn it off.
How could I fix that when I want to use the origin wildcard?
UPDATE
Here's the initialize code I run on App_Start
public static void Initialize()
{
// Azure blob storage settings
var storageAccount = CloudStorageAccount.Parse(ConfigurationManager.ConnectionStrings["AzureStorage"].ConnectionString);
var client = storageAccount.CreateCloudBlobClient();
var serviceProperties = client.GetServiceProperties();
serviceProperties.Cors = new CorsProperties();
serviceProperties.Cors.CorsRules.Add(new CorsRule()
{
AllowedHeaders = new List<string>() { "*" },
AllowedOrigins = new List<string>() { "*" },
AllowedMethods = CorsHttpMethods.Get,
ExposedHeaders = new List<string>() { "*" },
MaxAgeInSeconds = 3600
});
client.SetServiceProperties(serviceProperties);
}
The error that you encountered is due to setting withCredentials property on the xmlhttpreqeust to true ,in that case the browser will reject wildcard Access-Control-Allow-Origin.
In the new WebAPI v2 CORS package wildcards are replaced with the
actual origin.
Returning wildcard is the right thing to enable caching, take a look at the following scenario:
User A sends GET request to a public blob on MAS (Microsoft Azure Storage).
If you are using a CDN/Proxy to cache public resources which is a best practice then the CDN will cache the blob with Access-Control-Allow-Origin set to '*'.
Now User B sends the same request to MAS and gets the response from the cache instead, in that case since the cached blob has wildcard Access-Control-Allow-Origin the browser will allow that request and you don't need to hit MAS servers.
Now in the other case that you always return the actual origin, you can't cache that resources for multiple clients since the browser will fail the CORS request if the Access-Control-Allow-Origin has an actual origin that differs from request origin header.
Also, why would I need credentials such as cookies in a
request to the blob storage? Better turn it off.
You would need the credentials since one way to send authenticated requests is using the Authorization header, if the preflight request doesn't allow that then the browser should fail actual requests with Authorization header.
It actually does work when
withCredentials == false
on the XmlHttpRequest object. In my case this setting got messed up in the js framework I'm using.