Request for Request Token from Intuit IPP gives permission denied - google-app-engine

I am doing this on my local development site without problems. But when I try to setup a new connection to a QuickBooks file from my live site, I get a permission denied error.
Here is the error returned: "Post https://oauth.intuit.com/oauth/v1/get_request_token: permission denied"
Here are the request headers
Content-Type
application/x-www-form-urlencoded
Authorization
OAuth oauth_consumer_key="MY_KEY",
oauth_nonce="MY_NONCE",
oauth_signature="MY_SIG",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="1377287041",
oauth_version="1.0"
Here is the request body:
oauth_callback=http%3A%2F%2Fwww.intheloop-notes.com%2Fqb%2Fconnect%2Freturn%2F
---- EDIT ----
The response is nil altogether, I am getting an error from my Go code on:
response, err := client.Do(request)
Which is why I have added a couple of tags to this question (go and google-app-engine) to try and broaden my audience. I am pretty sure that the error is in the way that my OAuth library is sending the request. I am using this library: https://github.com/kurrik/oauth1a, which has been working just fine on my local development site, but gives me the "permission denied" error when I make the call from my live site. I think there is some difference in the way that the development app engine server creates the request from the way the live engine does, but I am not sure exactly what.
Any ideas?

Eureka! I figured it out! And thank you, Manas, I would not have found this solution without that last link you gave. For anyone who is wondering: I had to create a custom http.Client using the appengine.urlfetch library. Once I figured that out, the solution was simple, I just had to change one line of code that created the client into this:
client := urlfetch.Client(appengine.NewContext(r))
Problem solved!

Related

IdentityServer API unauthorized if hosted in IIS

I added additional API to the Duende IdentityServer 6.2 as described here. Then I tried to access it from a sample App, using typed httpClient using their own library called AccessTokenManagement (aka Identity.Model) pretty much following their simple example. I use Authorization Code flow, everything pretty much simple and default.
It works well until both server and client are on the same dev machine under localhost. As soon as I publish IdentityServer to IIS, the API stops to work, while the rest still works well (I can be authenticated, and I see in the Fiddler that token exchanges work normally).
The call to API consists from two calls:
Calling to /connect/token using refresh token. Server returns access token.
Calling my endpoint using this new access token.
The flow fails on the step 1. Call to /connect/token is already unauthorized and I can't understand why. The "good" and "bad" calls looks the same, I cannot see any differences. Previous call moment ago to /connect/userinfo consists of the same two steps and it works. Logs on both server and client give no clues.
No reverse proxies, just good plain simple URI. Automatic key management is enabled and the keys are in the SQL table, common for dev and published server. Asp.Net Core Data Protection is enabled and keys are also common.
Relevant parts of logs are below. I noticed that "No endpoint entry found for request path" is specific to IdentityServer and it doesn't actually mean that endpoint was not found. It was found but not processed. I also noticed reacher response headers from bad request and log entry about "Cookie signed-in" in good request but not sure what does it mean and whether it's relevant.
I'm running out of ideas.
Bad response from IIS while trying to get new Access Token:
Proper response while developing:
///////Relevant part of log for BAD request
|Duende.AccessTokenManagement.OpenIdConnect.UserAccessAccessTokenManagementService|Token for user test#test.com needs refreshing.
|Microsoft.AspNetCore.Authentication.Cookies.CookieAuthenticationHandler|AuthenticationScheme: cookie was successfully authenticated.
|Duende.AccessTokenManagement.OpenIdConnect.UserTokenEndpointService|refresh token request to: https://auth.mysite.org/connect/token
|Duende.AccessTokenManagement.OpenIdConnect.UserAccessAccessTokenManagementService|Error refreshing access token. Error = Unauthorized
|System.Net.Http.HttpClient.IdsService.ClientHandler|Sending HTTP request POST https://auth.mysite.org/mycontroller/myaction
|System.Net.Http.HttpClient.IdsService.ClientHandler|Received HTTP response headers after 117.7278ms - 401
///////Same part of GOOD request
|Duende.AccessTokenManagement.OpenIdConnect.UserAccessAccessTokenManagementService|Token for user test#test.com needs refreshing.
|Microsoft.AspNetCore.Authentication.Cookies.CookieAuthenticationHandler|AuthenticationScheme: Cookies was successfully authenticated.
|Duende.AccessTokenManagement.OpenIdConnect.UserTokenEndpointService|refresh token request to: https://localhost:5001/connect/token
|Microsoft.AspNetCore.Authentication.Cookies.CookieAuthenticationHandler|AuthenticationScheme: Cookies signed in.
|System.Net.Http.HttpClient.IdsService.ClientHandler|Sending HTTP request POST https://localhost:5001/mycontroller/myaction
|System.Net.Http.HttpClient.IdsService.ClientHandler|Received HTTP response headers after 1994.9611ms - 200
///////Server log during BAD request
Duende.IdentityServer.Hosting.EndpointRouter No endpoint entry found for request path: "/mycontroller/myaction"
Duende.IdentityServer.Hosting.LocalApiAuthentication.LocalApiAuthenticationHandler HandleAuthenticateAsync called
Duende.IdentityServer.Hosting.LocalApiAuthentication.LocalApiAuthenticationHandler AuthenticationScheme: "IdentityServerAccessToken" was not authenticated.
Duende.IdentityServer.Hosting.LocalApiAuthentication.LocalApiAuthenticationHandler AuthenticationScheme: "IdentityServerAccessToken" was challenged.
Okay, found it. Thankfully, looked at Fiddler's WebView and had seen familiar picture!
Then, found this topic. The solution was disabling Basic authentication in IIS settings. Access token request has basic authentication header and it seems like IIS intercepts it. Still a bit unclear why other parts of flow worked.

Issue with Access to XMLHttpRequest has been blocked by CORS Policy (Python/Angular)

I am getting the following issue on Angular application, which is currently live on the web.
Users can't log in because of this. And, already logged in users can't use the website properly.
Error: Access to XMLHttpRequest at "Frontend (Domain)" from origin "Backend (Domain)" has been blocked by CORS Policy. No 'Access-Control-Allow-Origin' header is present on the requested resource.
I already seen many posts related to the same issue. Already implemented most of the solutions to the application. Let me explain in detail.
Application Details :
Frontend: Angular 7, SSL Installed.
Backend: Python 3.7, Django Rest framework, 'CorsHeader' Plugin installed, CORS_ORIGIN_ALLOW_ALL is True and 'corsheaders.middleware.CorsMiddleware' is at the top of the middleware list.
Apache on Server: 'rewrite', 'wsgi' and 'headers' enabled.
Most Importantly: After implementing the solutions, the errors are gone for a while. But, after a few days/weeks, the same error occurs again. Rebooting the server will fix the issue. But, the same will come again after a few days/weeks.
What is the proper fix for this issue? Or Am I doing anything wrong on my side?
NB: I am not testing from local/postman. Everything works perfectly on local and Postman.
Adding two screenshots of a request. This request is done two times automatically. The first Request has no response. And, the Second request has a 503 response.
I found the root issue, please see your screenshot, there is Access-Control-Request-Method: GET and it should not be there.
In your angular code remove the below code.
request.headers
.set('Access-Control-Allow-Methods', 'GET')
.set('Access-Control-Allow-Origin', '*');
Hope it resolve your issue.

The reply URL returns error using https://xxxxx.azurewebsites.net/xxxxxxx/ and works well using https://xxxxx.azurewebsites.net/

I'm facing issue with the reply URL when authenticating on an Azure website. Everything works well when logging in normally, but it generates the "reply URL" error when logging in using some other pages.
As an example, using "https://xxxxx.azurewebsites.net/" works well, but using "https://xxxxxx.azurewebsites.net/xxxxxxxx/" returns the following error:
AADSTS50011: The reply url specified in the request does not match the reply urls configured for the application: 'XX2782c9-XXXX-XXXX-9789-XX750058XXXX'.
I have also tried using the instructions from Microsoft’s documentation on configuring the reply URL settings.
Error with:
https://login.microsoftonline.com/common/oauth2/authorize?response_type=id_token&client_id=XXXX82c9-6873-4096-XXXX-02750058XXXX&redirect_uri=https%3A%2F%2Fxxxxxxxxx.azurewebsites.net%2Fdashboard&state=xxxx2209-5986-4ce3-8498-8863daaxxxx&client-request-id=xxxxfcfa-fb5e-409e-834e-5fd4666bxxxx&x-client-SKU=Js&x-client-Ver=1.0.15&nonce=db5d9934-818a-43ad-98df-f1ced93f358d
Works with:
https://login.microsoftonline.com/common/oauth2/authorize?response_type=id_token&client_id=XXXX82c9-6873-4096-XXXX-02750058XXXX&redirect_uri=https%3A%2F%2Fxxxxxxxxx.azurewebsites.net%2F&state=xxxx2209-5986-4ce3-8498-8863daaxxxx&client-request-id=xxxxfcfa-fb5e-409e-834e-5fd4666bxxxx&x-client-SKU=Js&x-client-Ver=1.0.15&nonce=db5d9934-818a-43ad-98df-f1ced93f358d
It should work with the both reply URLs, however.
I reproduce your problem. When you change reply url from https://xxxxx.azurewebsites.net/ to https://xxxxx.azurewebsites.net/xxxxx and try at once, it will get this error.
Just wait for several minutes and try again it will work fine. If you still have problem, please feel free to let me know.
You could refer to this article to send the sign-in request.

Google API app engine redirect uri

can someone point me in the right direction re: redirect uri
right now i have app hosted on appspot (nothing done or uploaded to it at this point)
"Error: Server Error
The server encountered an error and could not complete your request.
If the problem persists, please report your problem and mention this error message and the query that caused it."
do i need to upload anything for this to work?
https://developers.google.com/accounts/docs/OAuth2InstalledApp#choosingredirecturi
POST /o/oauth2/token HTTP/1.1
Host: accounts.google.com
Content-Type: application/x-www-form-urlencoded
code=4/v6xr77ewYqhvHSyW6UJ1w7jKwAzu&
client_id=8819981768.apps.googleusercontent.com&
client_secret={client_secret}&
redirect_uri=https://oauth2-login-demo.appspot.com/code&
grant_type=authorization_code
i just want to authenticate so that i can use the calendar api
Do upload the application. I am not sure what you mean by saying that the app is hosted on appspot but nothing done or uploaded at this point. So, first make sure that you have uploaded a version of your application.
The OAuth process is redirecting the flow if I understand correct to oauth2-login-demo.appspot.com and you must have registered this callback url when setting up your application.
So it seems that the redirection is probably taking place but you are seeing the General Exception that is normally thrown by App Engine.
You should look into the Admin Console -> Logs for your application to understand the reason for the failure. You might get some information there about the cause.
If there is a problem with your code, it will point that in the logs. Alternately, put in some exception handlers and bump up the Log Level to INFO in your logging.properties to have a better chance of tracking down the root case.

Unauthorized dataimport-scheduler calls

I'm trying to setup an dataimport-scheduler for solr, everything's working and the deltaimport url is called every 30 minutes, the only problem is I'm using jetty and activated authentication in jetty.xml so the dataimport_scheduler gets:
<index update process> Response message Unauthorized
(saw in log file), How can I solve this?
The DataImportScheduler needs to have access to your solr/dataimport url via http. The error you see in the log file is because of the authentication you added. As far as I know the DataImportScheduler doesn't support authentication out of the box, but it should be easy to add it to the code.
Unfortunately it doesn't use http-client, which would have made things a bit easier and flexible I guess, but you can have a look at this answer to find out how to add http basic authentication to http calls made through the HttpURLConnection class.

Resources