I need to receive webhook requests in the same backend as my mobile app. They are sent as POST with content-type application/x-www-form-urlencoded. As far as I can tell, I have to use the [MobileAppController] attribute on my controllers, but this forces me to send in a header named "zumo-api-version" (which my webhook provider obviously does not send in the request). Any ideas on how to go about this?
but this forces me to send in a header named "zumo-api-version" (which my webhook provider obviously does not send in the request).
You can opt out of version checking by setting a value of true for the app setting MS_SkipVersionCheck. Specify this either in your web.config or in the Application Settings section of the Azure portal. After setting MS_SkipVersionCheck to true, zumo-api-version header is not required.
<appSettings>
<add key="MS_SkipVersionCheck" value="true"/>
</appSettings>
Related
We're trying to use a client certificate to authenticate when calling an OData service in SAP S/4HANA. And we're calling from an azure APIM instance. As certificate we've created a self-signed certificate and configured SAP S/4HANA according to this blog (https://blogs.sap.com/2020/05/03/x.509-certificate-based-logon-to-odata-services/)
Then we test this from the browser it works like a charm.
But calling from azure APIM we get the following response from SAP S/4HANA:
<?xml version="1.0" encoding="utf-8"?> <error xmlns:xsi="http://www.w3.org/2001/XMLSchema-Instance">
<code>HTTP/404/E/Not Found</code>
<message> Service /sap/opu/odata/sap/xxxxyyyy/xxyyzz call was terminated because the corresponding service is not available.The termination occurred in system UFI with error code 404 and for the reason Not found. Please select a valid URL. If it is a valid URL, check whether service /sap/opu/odata/sap/xxxxyyyy/xxyyzz is active in transaction SICF. If you do not yet have a user ID, contact your system administrator. </message>
SAP S/4HANA support says that then calling from browser they can 'see' certificate in payload but then calling from APIM, the payload is 'empty'.
I've got the trace logs from the SAP S/4HANA gateway server and I've noticed this subtly difference calling from browser vs calling from APIM:
Browser call (successfull):
[Thr 140708195055360] HttpModGetDefRules: determined the defactions: COPY_CERT_TO_MPI (1)
APIM call (failed):
[Thr 140708197697280] HttpModGetDefRules: determined the defactions: NOTHING (0)
So the certificate is obviously reaching SAP S/4HANA gateway server but not the SAP S/4HANA Odata server. So somehow, for some reason it's lost on the SAP S/4HANA gateway server only then it comes from azure APIM.
I've tried to make the calls 100% identical (same headers same values) but I can't control the way the certificate is added in azure apim or can one ?
I read that one can set the certificate body using policy below:
<authentication-certificate body="#(context.Variables.GetValueOrDefault<byte[]>("byteCertificate"))" password="optional-certificate-password" />
but I can't figure out how to get a proper value for "byteCertificate".
Has anyone done this? Or has anyone had a similar issue?
We finally found the solution!
Thanks to microsoft APIM support team, thanks a lot :)
APIM acts like a reverse proxy and adds headers related to this role. The header "X-Forwarded-For" causes SAP to deny the request with the above misleading error message. We found a solution that SAP could configure:
ICM parameter "icm/HTTPS/accept_ccert_for_x_forwarded_for_requests" has to be set to "true" - per default it's set to "false".
(The header can't be deleted with a policy on APIM side.)
I am using Azure API Management as front end for my Logic App. The "subscription required" setting needs to be enabled as we do need the protection. However, we must send the key via query parameter because our calling application only supports GET, not POST.
So my API call was sent to Azure using the format of https://my.azure-api.net/myapi/manual/paths/invoke?subscription-key=mykey
Now in Azure API setting I did create a policy set to delete action on the "subscription-key" query parameter, but here's the problem:
Even though the parameter is removed from the request body into Logic App, upon digging into the "RAW" outputs in Logic App where it shows various headers, we can see the subscription-key in these two headers:
"X-WAWS-Unencoded-URL": "/myapi/manual/paths/invoke?subscription-key=xxx
"X-Original-URL": /myapi/manual/paths/invoke?subscription-key=xxx
In other words, the full original query URL was made available to Logic App before the parameter was removed. This exposes the API subscription key to the Logic App.
Is there any workaround for this?
Ah I see now that those headers were actually sent automatically by Azure API Management to the backend Logic App API, so all I had to do was to set header policies to remove them in addition to the query parameter policy.
<set-query-parameter name="subscription-key" exists-action="delete" />
<set-header name="X-WAWS-Unencoded-URL" exists-action="delete" />
<set-header name="X-Original-URL" exists-action="delete" />
This takes care of it.
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.
I have an Owin WebAPI2 .NET app that I host on an AppService in Azure.
I want to add CORS support using Azure as in this article. It seems simple, you just add an Origin site to the list like this: http://screencast.com/t/r2ATq4u5
I would now expect the Response headers to contain this allowed Origin.
However, the CORS headers are not included in the Response Headers when I check it with Fiddler:
http://corstestqm.azurewebsites.net/breeze/restaurantsbreeze/basictest
Steps I have tried:
Stripped out all CORS Nuget libraries from my solution and all traces of CORS code in my API project.
Deployed to a brand new AppService
Enabled Owin Cors AllowAll
None of these had any effect. (ie. the Response does not contain the CORS header specified in Azure).
Am I missing something really basic here?
UPDATE
I simplified the problem even more:
In VS2015, I created a new API project and pushed it to http://corstestbasicap2.azurewebsites.net/api/values/
with no changes (ie. it should NOT have CORS enabled).
I then use Test-Cors tool to hit that API. It does not get a CORS error as expected. I then go into Azure and add a dummy URL (e.g http://www.example.com) and try the CORS test again. It should fail as Azure should only let example.com through. However, it works fine.
I then edit CORS again in Azure and add http://www.test-cors.org below http://www.example.com (so it should let either through) and now the headers return Access-Control-Allow-Origin:http://www.test-cors.org as expected.
But this makes no sense? Surely the previous call should fail when "http://www.test-cors.org" was NOT in the allowed Origins? It does not seem to be doing anything useful?!
You can achieve these by adding in your web.config bellow configuration:
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*"/>
<add name="Access-Control-Allow-Headers" value="Origin, X-Requested-With, Content-Type, Accept,Authorization"/>
<add name="Access-Control-Allow-Methods" value="GET, POST, PUT, DELETE, OPTIONS"/>
</customHeaders>
</httpProtocol>
</system.webServer>
In global.asax:
protected void Application_BeginRequest()
{
if (Request.Headers.AllKeys.Contains("Origin") && Request.HttpMethod == "OPTIONS")
{
Response.Flush();
}
}
If you want control from portal, please view bellow image:
Note, according with App Service CORS documentation you can not use both Web API CORS and App Service CORS in one API app. You have to clean your project about Web API CORS
Don't try to use both Web API CORS and App Service CORS in one API
app. App Service CORS will take precedence and Web API CORS will have
no effect. For example, if you enable one origin domain in App
Service, and enable all origin domains in your Web API code, your
Azure API app will only accept calls from the domain you specified in
Azure.
My problem was that I accidentally put http instead of https into Azure AD B2C custom page config blade ... After change to https it works like a charm.
CORS headers missing when deployed on Azure Web App / Azure API
I keep getting "AADSTS75005: The request is not a valid Saml2 protocol message." when I try to send an AuthnRequest to Azure AD/idp.
The XML looks like this before I zip it, convert to base64string and url encode the message.
<samlp:AuthnRequest xmlns="urn:oasis:names:tc:SAML:2.0:metadata" ID="ide13dd575-3f6c-4131-9b9d-e12c644cf18f" Version="2.0" IssueInstant="2016-11-14T14:28:27.5450323Z" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">{homepage url registered in azure app registrations}</Issuer></samlp:AuthnRequest>
the user is being redirect to https://login.microsoftonline.com/{SAML-P Sign-On Endpoint from endpoints in app in azure}/saml2?SAMLRequest={encoded saml request removed}
The same works when I send it to an other SAML2 idp (which use SimpleSAMLphp)
the web browser will be redirect to https://login.windows.net/{endpoint id}/saml2?SAMLRequest=jZBLasMwFEW3YjRXbKny72EbAqVgaCkkbQedBEVWiKktuXrP%2faytgy6pW6hJhoXQ6YV7OPf%2bfH1XqMdhgvVMR7exr7NFij7GwWHN5uDAa%2bwRnB4tAhnYru9uQa4SGC3pTpNmUXtds77rrCjy9KB4LpXian%2bV8aJLUl6Wpdknytg0y1n0ZAP23tVsQSxNxNm2Dkk7WqJEZFwILtSDlCBSkHIlZCbLtHhmZyU4uV4Wm4Inb%2fzAmurED%2f9ZoxFtoMWMNUeiCSGOx8%2fHTbu78WG3JW1e7t9sOAz%2bvYrP1KaK%2fx7X%2fAI%3d
As #Steve already mentioned above, the problem seems to be with the way you are deflating/encoding the AuthenticationRequest. Try using the sample code at https://stackoverflow.com/a/25155050/983244, assuming that you are using .NET ( You mentioned DeflateStream ).
I would also clear out the namespace declarations so that your AuthnRequest looks like
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="ide13dd575-3f6c-4131-9b9d-e12c644cf18f"
Version="2.0"
IssueInstant="2016-11-14T14:28:27.5450323Z">
<saml:Issuer>{homepage url registered in azure app registrations}</saml:Issuer>
</samlp:AuthnRequest>
I found the problem to this. I created the app in the new azure portal. It show the endpoint to be https://login.windows.net/{myid}/saml2
I created a new app in the old portal and now it shows the endpoint to be https://login.microsoftonline.com/{myid}/saml2
If I look at the both apps created (one in the new and one in the old portal) in the old portal, it show https://login.microsoftonline.com/{myid}/saml2
if I do the same in the new portal, it shows https://login.windows.net/{myid}/saml2 on both aps.
So there was not any error with my code, but the Azure AD portal is reporting invalid endpoints in the new portal.