error: (407) Proxy Authentication Required in the IPP .Net AggCat DevKit - intuit-partner-platform

I'm trying to perform some basic actions on the .NET Sample App for Customer Account Data.
The problem happens in the following code snippet (when I'm selecting a bank and expecting its details):
protected void institutions_SelectedIndexChanged(object sender, EventArgs e)
{
try
{
if (institutions.SelectedValue == "PleaseSelect")
{
InstitutionDetails.Visible = false;
}
else
{
InstitutionDetails.Visible = true;
AggregationCategorizationService svc = Services.AggCatService.GetService(Cache, HttpContext.Current.User.Identity.Name);
InstitutionDetail insutitutionDetail = svc.GetInstitutionDetails(long.Parse(institutions.SelectedItem.Value));
I recieve the following error:
Error detail: Error occurred while calling GetInstitutionDetails:
WebException: The remote server returned an error: (407) Proxy
Authentication Required. Proxy-Authenticate:
Negotiate,Kerberos,NTLM,Basic realm="fw.solar.local" Via: 1.1 FW
Connection: close Proxy-Connection: close Pragma: no-cache
Cache-Control: no-cache Content-Type: text/html Content-Length: 701
I'm executing the sample as is, without any modifications.
What can be the reason of it? And how can I fix it?

Can you test the calls using CC bank (dummy institution) details:
https://developer.intuit.com/docs/0020_customeraccountdata/customer_account_data_api/testing_calls_to_the_api

Can you please check if your keys and SAML process is working fine using CAD apiexplorer
https://developer.intuit.com/apiexplorer?apiname=CustomerAccountData
Key generation using openssl - https://developer.intuit.com/docs/0020_customeraccountdata/007_firstrequest
After generating these keys, you can create a sample app with the public key. https://developer.intuit.com/docs/0020_customeraccountdata/009_using_customeraccountdata/0010_gettingstarted/0015_create_an_cad_integration
then use the .p12 file with pwd(if any) for SAML assertion in apiexplorer Link - https://developer.intuit.com/apiexplorer
This code(407) is similar to 401, but indicates that the client should first authenticate with a proxy server.

Related

Connect with PayPal - invalid_client Client Authentication failed with sandbox

I am implementing Connect With PayPal on my vuejs application following this documentation, but I keep getting an invalid_client error when I try to get the access token.
I have created the sandbox REST app on my account and I've enabled "Connect With PayPal". I have also set my return url in the app settings. To build the button I used the button builder and specified my client id, return url and set auth end point as "sandbox". I have added the external script in my index.html and the paypal.use() method in my component.
So now I have the connect button on my interface and when I click on it I am redirected to https://www.sandbox.paypal.com/connect/ which is normal. I can login with my two default sandbox accounts, then I am redirected to the return url that I specified in my app settings, with two url parameters : "code" and "scope" as described in the documentation.
However I am stuck at this step where I need to get an access token for the connected user.
I have tried to run this curl request with my client id / secret and the code from the url but as I said before it doesn't work and I am getting this error everytime :
HTTP/1.1 401 Unauthorized
Cache-Control: max-age=0, no-cache, no-store, must-revalidate
Content-Length: 77
Content-Type: application/json
Date: Wed, 08 Jul 2020 22:01:03 GMT
Paypal-Debug-Id: 8abaa5940b688
X-Paypal-Token-Service: IAAS
{
"error":"invalid_client",
"error_description":"Client Authentication failed"
}
I have checked my client id and secret multiple times and I can't understand why this is not working, does anyone have an idea ?
Solution for this type of error is to verify and validate everything is being sent correctly in the request, and properly encoded
curl's -u flag makes username:password header authentication easier
curl's -v flag will give visibility about the actual communication, to validate

Large Azure DevOps (and Azure DevOps Server 2019) changesets fail with "Request Entity Too Large"

We seem to be hitting a limit when trying to add a large binary file to Azure DevOps using the REST APIs. The same file check-in works fine using the old SOAP APIs and also works using the TFVC CLI (tf.exe). But we have a use case where we need to occasionally check in large files programatically from machines that don't have VS installed. We're trying to migrate our application from the old SOAP APIs to the REST API because we're moving to .NET Core where the SOAP API is not supported.
A POST to the /_apis/tfvc/changesets (Create Changeset) API with large (> about 19 MB) files results in:
HTTP 400: Bad Request
This issue has been reported a couple of times on the Azure DevOps .NET Samples github repo, but that isn't the right forum for this question so it hasn't been answered there.
https://github.com/microsoft/azure-devops-dotnet-samples/issues/176
https://github.com/microsoft/azure-devops-dotnet-samples/issues/104
How do we create large files in TFVC using the REST API?
Update 2020-01-13
Here's a sample console app we've used to demonstrate the problem:
using Microsoft.TeamFoundation.SourceControl.WebApi;
using Microsoft.VisualStudio.Services.Common;
using Microsoft.VisualStudio.Services.WebApi;
using System;
using System.Collections.Generic;
using System.IO;
using System.Text;
using System.Threading.Tasks;
namespace ConsoleApp1
{
internal class Program
{
internal static async Task Main(string[] args)
{
var orgUrl = new Uri(args[0]);
string serverPath = args[1];
string localPath = args[2];
string contentType = args[3];
string pat = args[4];
var changes = new List<TfvcChange>()
{
new TfvcChange()
{
ChangeType = VersionControlChangeType.Add,
Item = new TfvcItem()
{
Path = serverPath,
ContentMetadata = new FileContentMetadata()
{
Encoding = Encoding.UTF8.WindowsCodePage,
ContentType = contentType,
}
},
NewContent = new ItemContent()
{
Content = Convert.ToBase64String(File.ReadAllBytes(localPath)),
ContentType = ItemContentType.Base64Encoded
}
}
};
var changeset = new TfvcChangeset()
{
Changes = changes,
Comment = $"Added {serverPath} from {localPath}"
};
var connection = new VssConnection(orgUrl, new VssBasicCredential(string.Empty, pat));
var tfvcClient = connection.GetClient<TfvcHttpClient>();
await tfvcClient.CreateChangesetAsync(changeset);
}
}
}
Running this console app with a ~50MB zip file against an Azure DevOps TFVC repository results in a VssServiceResponseException (with inner ArgumentException) with a message of: The maximum request size of 26214400 bytes was exceeded.
Update 2020-01-14
Added display of file size and base64 content length before sending TFVC request in my sample code.
Corrected my observations about the file size limit.
Corrected the error code returned by Azure DevOps (400, not 413).
Originally I stated that the limit was around 13 MB. This was based on the failures I saw with files > 20MB, success with files < about 10 MB, and the limits described in the linked github issues.
I have run more tests of my own and have narrowed in on about 19,200 KB as the actual limit. This seems correct based on the error message indicating a 26,214,400 byte limit. A 19 MB base-64 encoded file would expand to about 26 MB.
I also noticed in my most recent tests, when monitoring with Fiddler, that Azure DevOps returns a 400 status code (not 413). My notes had indicated a 413 Request Entity Too Large was observed at some point in the past. Perhaps this with with an older version of Azure DevOps Server? In any case, the error we see now is 400 Bad Request.
Here is what Fiddler shows for the request headers:
POST /<...REMOVED...>/_apis/tfvc/changesets HTTP/1.1
Host: dev.azure.com
Accept: application/json; api-version=5.1
User-Agent: VSServices/16.153.29226.1 (NetStandard; Microsoft Windows 10.0.18363)
X-VSS-E2EID: 6444f0b5-57e0-45da-bd86-a4c62d8a1794
Accept-Language: en-US
X-TFS-FedAuthRedirect: Suppress
X-TFS-Session: 9f8e8272-db48-4e93-b9b0-717937244aff
Expect: 100-continue
Authorization: Basic <...REMOVED...>
Accept-Encoding: gzip
Content-Type: application/json; charset=utf-8; api-version=5.1
Content-Length: 26324162
And the raw response:
HTTP/1.1 400 Bad Request
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 206
Content-Type: application/json; charset=utf-8
Expires: -1
P3P: CP="CAO DSP COR ADMa DEV CONo TELo CUR PSA PSD TAI IVDo OUR SAMi BUS DEM NAV STA UNI COM INT PHY ONL FIN PUR LOC CNT"
X-TFS-ProcessId: 7611d69f-e722-4108-8050-e55a61b1cbb4
Strict-Transport-Security: max-age=31536000; includeSubDomains
ActivityId: 15e046e5-3788-4fdb-896a-7d0482121ddd
X-TFS-Session: 9f8e8272-db48-4e93-b9b0-717937244aff
X-VSS-E2EID: 6444f0b5-57e0-45da-bd86-a4c62d8a1794
X-VSS-UserData: <...REMOVED...>
X-FRAME-OPTIONS: SAMEORIGIN
Request-Context: appId=cid-v1:e3d45cd2-3b08-46bc-b297-cda72fdc1dc1
Access-Control-Expose-Headers: Request-Context
X-Content-Type-Options: nosniff
X-MSEdge-Ref: Ref A: 7E9E95F5497946AC87D75EF3AAD06676 Ref B: CHGEDGE1521 Ref C: 2020-01-14T14:01:59Z
Date: Tue, 14 Jan 2020 14:02:00 GMT
{"$id":"1","innerException":null,"message":"The maximum request size of 26214400 bytes was exceeded.","typeName":"System.ArgumentException, mscorlib","typeKey":"ArgumentException","errorCode":0,"eventId":0}
Until now, the most useful solution is to allocated a sufficiently large buffer via modifying the configuration in IIS.
Go machine -> open IIS manager:
(1) Select the site of your collection
(2) Double click “Configuration Editor”
(3) Insert system.webServer/serverRuntime into Section
(4) Expand the uploadReadAheadSize value based on your scenario.
Then click Apply to apply above changes.
I know, it would be very costly for large request bodies. But, as I know, this is the often method we used.
I opened a support ticket with Microsoft. The support engineer indicated that this was a known limitation of the Azure DevOps service. He suggested that I create a feature request. I've done that. If this limitation is problematic for you, please upvote the feature request.
https://developercommunity.visualstudio.com/idea/1130401/allow-creating-large-tfvc-changesets-via-the-api.html

TFS Web Calling an external REST Service throws 401 error

When creating a web hook within TFS (to access an external rest service url), I get a 401 error when testing (within the TFS application). I think call is not hitting API at all.
Below is the response I can see
Status Code: 401
Reason Phrase: Unauthorized
HTTP Version: 1.1
Headers:
{
Server: Microsoft-IIS/7.5
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
X-UA-Compatible: IE=EmulateIE8
Date: Fri, 30 Mar 2018 21:05:26 GMT
Content-Length: 1293
Content-Type: text/html
}
Any help would be appreciated!
The error ID 401 usually related to the authorization.
You could first use postman to double check user ID access to the API.
Also use week hook to access some other rest service url such as the example in Web Hooks. This will narrow down if the issue related to rest service url.
Besides try to use Basic Authentication, you can use alternate account instead. How to please take a look at:Protecting a VSTS Web Hook with Basic Authentication

The MAC signature found in the HTTP request '...' is not the same as any computed signature

I'm sending the following request in Postman to retrieve a simple .jpg from Azure Blob storage at this URL https://steamo.blob.core.windows.net/testcontainer/dog.jpg
GET /testcontainer/dog.jpg HTTP/1.1
Host: steamo.blob.core.windows.net
Authorization: SharedKey steamo:<my access key>
x-ms-date: Tue, 26 May 2015 17:35:00 GMT
x-ms-version: 2014-02-14
Cache-Control: no-cache
Postman-Token: b1134f8a-1a03-152c-2810-9cb351efb9ce
If you're unfamiliar with Postman it is just a REST client - the Postman-Token header can probably be ignored.
My access key is copied from my Azure Management Portal.
I get this error:
Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature. RequestId:2482503d-0001-0033-60da-9708ed000000 Time:2015-05-26T17:35:41.4577821Z
With this AutheticationErrorDetail:
The MAC signature found in the HTTP request '<my access key>' is not the same as any computed signature. Server used following string to sign: 'GET x-ms-date:Tue, 26 May 2015 17:35:00 GMT x-ms-version:2014-02-14 /steamo/testcontainer/dog.jpg'.
How do I fix this? Let me know if you need any more info from me.
Authentication for Azure Storage is not simply a matter of providing the access key (that is not very secure). You need to create a signature string that represents the given request, sign the string with the HMAC-SHA256 algorithm (using your storage key to sign), and encode the result in base 64. See https://msdn.microsoft.com/en-us/library/azure/dd179428.aspx for full details, including how to construct the signature string.
Just got this working, here's my code:
string signWithAccountKey(string stringToSign, string accountKey)
{
var hmacsha = new System.Security.Cryptography.HMACSHA256();
hmacsha.Key = Convert.FromBase64String(accountKey);
var signature = hmacsha.ComputeHash(Encoding.UTF8.GetBytes(stringToSign));
return Convert.ToBase64String(signature);
}

OSB - Processing Http errors from Restful service in Proxy Service

I'm invoking a REST service from an OSB Proxy Service, which is working fine if the rest service response is a valid response, i.e., there's no errors. However if the rest service replies with an http error code (e.g. 400 Bad Request), I'm not able to capture anything else except the http error code:
$fault variable in OSB:
<con:fault xmlns:con="http://www.bea.com/wli/sb/context">
<con:errorCode>BEA-382502</con:errorCode>
<con:reason>
OSB Service Callout action received an error response
</con:reason>
<con:details>
<con1:ErrorResponseDetail xmlns:con1="http://www.bea.com/wli/sb/stages/transform/config">
<con1:http-response-code>400</con1:http-response-code>
</con1:ErrorResponseDetail>
</con:details>
<con:location>
<con:node>PipelinePairNode1</con:node>
<con:pipeline>PipelinePairNode1_request</con:pipeline>
<con:stage>stage1</con:stage>
<con:path>request-pipeline</con:path>
</con:location>
</con:fault>
But the rest service, is not only replying with 400 Bad Request, but also adding a message:
<Error>
<Message>The message header contains an invalid brand code.</Message>
</Error>
Which I'm not able to process in my proxy service. Does anyone knows if it is possible to access this message details in OSB or is it a limitation?
The rest service is clearly sending the message, because invoking it directly through soap-ui I'll get the following response:
HTTP/1.1 400 Bad Request
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 84
Content-Type: application/xml; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Mon, 09 Feb 2015 16:15:32 GMT
<Error><Message>The message header contains an invalid brand code.</Message></Error>
Thanks
I've just found out this is an OSB bug, in case of an HTTP Error code 400 being returned, if the http-content is "Application/XML" the message is ignored.
Oracle released a Patch at the end of last month to fix this issue, which I've tested and it works. I can get the message details in the $body variable now.
Patch: 16986497
If I understand your question, you want to get in addition to the http code, the message error?
I think you should use, in your message flow, an errorHandler , so that you can catch the error and do whatever you want with.
The proxy service operation selection algorithm cannot determine the operation name from the request or returns an invalid operation (one which is not in the WSDL or null). Possible reasons include the following:
An error occurs while computing the operation.
The operation selection algorithm returns null.
The operation selection algorithm returns an operation that is not of the of the operations declared by the WSDL.
Source