I am testing QuickBooks Online API by using the source code from the following URL:
https://github.com/consolibyte/quickbooks-php
When I test the diagnostics.php http://mydomain.info/qb/docs/example_app_ipp_v3/diagnostics.php
I got the following error:
Warning: array_merge(): Argument #2 is not an array in /home/mydomain.info/public_html/qb/docs/example_app_ipp_v3/diagnostics.php on line 15
The connection is fine.
Please advise
If $creds is empty, it means that you have not yet established a valid OAuth connection to Intuit's servers.
You need to do that before anything is going to work. If you're just trying to get rid of the error, just cast $creds to an array.
To establish a connection, click the "Connect to QuickBooks" button that's shown on the /index.php script when you visit it in a browser. You'll be walked through the OAuth setup process (make sure you've changed the URLs, app token, and OAuth credentials in config.php first, and configured your URLs in your IPP app as well on Intuit's site).
Regarding your other questions:
$the_username and $the_tenant can be left at their defaults for testing.
In production, you will likely NEVER use $the_username (it's used only in very specific special circumstances). $the_tenant should be set to your unique tenant identifier within your SaaS app (or, if you're not a SaaS app, just leave it at it's default).
Related
It seems keeping all the browsers happy is a challenging task, what with all the security they are adding and the complexities of certificates.
I have a SPA (Vuejs) which is using oidc-client.js to implement OIDC, communicating with an Identity Server (Identity Server 4).
First thing to note is that everything works if I run both client and server on localhost.
It is when I deploy the Identity Server to a Staging Server inside our network that things go awry.
So, the hostname of the Idp now differs to that of the SPA (which would be normal in production).
After much work, I've got everything working except IE11 (yep IE).
I had to do several things to get me there such as:
solve the samesite cookie issue of Chrome
create self-signed certificates and install the root certificate in the Trusted Certificates
add Babel config code and Core.js at the client, to enable IE to not throw errors when promises come into play
So, it's been a long road, yet still, I have to deal with this (see animation):
I just can't quite figure out why IE is doing that.
It is not possible to use the dev tools to see any info.
The logs at the server do not contain any information that seems relevant.
Has anyone else seen these "Browser symptoms" in IE.
Happy to provide more information (code, logs etc.) if people think that will help. Just didn't want to dump all that in the initial question, as many people don't like that.
Here are a couple of Fiddler screenshots. The first is from Chrome:
The second on is for IE11.
For some reason, the Silent Refresh is being invoked over and over again with IE11.
I think I can see what is happening, but not sure how to fix it.
There appears to be 2 calls to the Authorize endpoint which fail, conspicuously missing the .AspNetCore.Antiforgery cookie. This results in 2 invocations of silent-refresh.html.
Then, for some reason there is some king of GET request to the base url of the Idp and immediately following on the heels of that request is a request to the Authorize endpoint which does have the .AspNetCore.Antiforgery cookie.
The ship is set straight until the next call to the Authorize endpoint which is the beginning of the next cycle.
However, with Chrome, after the user is logged in, the next call to the Authorize endpoint does contain the cookie.
So, I guess it is the missing cookie which is the issue.
Perhaps this has something to do with the code which I used from this post to solve the Chrome samesite cookie issue?
Cheers
I'm new to IdentityServer4 (2.5) and certificate setup so please bear with me. I think that I've chased down everything I could. I am using it with ASP.Net Core 2.2.0 in a proof of concept app. I have OpenIdConnect with an authority app and a client using cookies with X509Certificate2. Works great on my local machine; however, when I deploy to IIS I get this error:
System.InvalidOperationException: IDX20803: Unable to obtain configuration from: 'https://my.com/mpauth/.well-known/openid-configuration'. ---> System.ArgumentException: IDX20108: The address specified 'http://my.com/mpauth/.well-known/openid-configuration/jwks' is not valid as per HTTPS scheme. Please specify an https address for security reasons. If you want to test with http address, set the RequireHttps property on IDocumentRetriever to false.
The problem is here - http://my.com/mpauth/.well-known/openid-configuration/jwks. If I put that in the browser I get an error; however, if I change http to https I get the data. What setting controls this?
TL;DR
In most cases IdentityServer defers the base hostname/URI from the incoming request but there might be deployment scenarios which require enforcing it via the IssuerUri and/or PublicOrigin options as documented here.
More Info
The URL you are getting in your exception is part of the discovery lookup. It is necessary for validating tokens (e.g. in an applications auth middleware).
There should be a first request to .../.well-known/openid-configuration (the main discovery document) that refers to several other URIs and one of them should be the jwks (signing key sets). In most cases the other URIs in openid-configuration will point to the same primary hostname and protocol scheme your identity server is using. In your case it looks like the scheme changes to HTTP which might be unwanted in this day and age.
Is it possible, that the deployed IdentityServer lives behind a load balancer/SSL termination appliance? This could cause behavior.
I am not sure about IIS details but there might also be some kind of default hostname/URI thing at play.
I'm creating a VS Code extension with a webview that contains a React application. In the React code, I'm making a GET request to a REST API, but it keeps failing due to the following error:
Failed to load resource: net::ERR_CERT_AUTHORITY_INVALID
Any ideas on why this may be happening or a workaround? Maybe this is a restriction of webviews?
If I make the call in the extension code, it works fine.
I upgrade the version of my browser to the latest and it worked me.
find this below given link to know how to update browser version.
https://www.computerhope.com/issues/ch001388.htm
Assuming that you get this error about the certificate of the remote side (the one serving the REST API), you get this error because of one of the following:
the authority that signed the certificate is not recognized on the client side (ie : the authority is not installed on your PC)
the certificate has expired
your PC has a wrong date
You can correct the above, or as a workaround you can (depending on your tools) explicitly ignore the untrusted remote certificate. But this workaround should remain for test purpose only, as it is a security breach.
I'm trying to write a VSCode extension where users could log into Google AppEngine with a google account, and I need to get their SACSID cookie to make appengine requests.
So I'm opening a browser window at
https://accounts.google.com/ServiceLogin?service=ah&passive=true&continue=https://appengine.google.com/_ah/conflogin%3Fcontinue%3Dhttp://localhost:3000/
(generated by google.appengine.api.users.create_login_url)
The user logs in and is redirected to my local webserver at
localhost:3000/_ah/conflogin/?state={state}
Now I try to forward the request to my AppEngine app (since it knows how to decode the state parameter), so I do a request to
https://my-app.appspot.com/_ah/conflogin/?state={state}
basically just replacing localhost with the actual app.
but it doesn't work, presumably because the domain is different. I assume this is on purpose, for security.
Is there any way I can make this work ?
Not ideal, but the only solution I've found is to have an endpoint on my GAE instance that does the redirection. Then I can set that as the continue url, when I'm starting the authentication process
https://accounts.google.com/ServiceLogin?service=ah&passive=true&continue=https://appengine.google.com/_ah/conflogin%3Fcontinue%3Dhttps://my-app.appspot.com/redirect?to=http://localhost:3000
I think you should center the attention on the protocols you are using, since it’s known that the cookie name is based on the http protocol (HTTP : ACSID, HTTPS:SACSID), and that’s the security perspective till this point for me.
Having the error you are facing now would be helpful to understand the problem better. Also, how are you performing the call to the API and the code you are using would be helpful too.
I'm trying to setup the config.php with my values but I get this fatal error:
Fatal error: Uncaught exception 'Google_AuthException' with message 'Error fetching OAuth2 access token, message: 'invalid_grant'.
I entered the client ID, secret, simple API key, location and sqlite database as the documentation says here:
https://developers.google.com/glass/quickstart/php
Any idea of what I'm doing wrong?
Thanks in advance!
This happens when the URL where you're hosting your Glassware is not listed as a valid OAuth 2.0 redirect URI on the API console. Follow these steps to resolve it.
First, determine your OAuth 2.0 redirect URI. This is where traffic goes at the end of the OAuth dance. The correct value depends on where you're running the php quick start. If you're running it on a local web server, it's likely to be http://localhost/mirror-quickstart-php/oauth2callback.php. If you're running it on example.com, it might be https://example.com/oauth2callback.php.
Go to the API console. This link will lead you to the right panel (services), but double check that you're on the correct project.
Scrolling down you should see a section of the page that looks like this: . Click on 'Edit Settings...'.
This triggers a pop-up where you can enter your OAuth redirect URIs. Add your redirect URI to the top text area. Make sure to put each URI on its own line.
Reload the page for the PHP Quick Start and everything should work.
If you're still having an issue, please share the full error message on the page and the value you have for the base url in config.php.
If you're getting the invalid_grant error from Google : Instead of using the client ID from google developer console as your value for client ID in the code, try using the email address value from developer console. This is actually what they expect. So, to confirm - the value for Client ID should be the value from developer console ending #developer.gserviceaccount.com
Had similar problem in Windows PS dotnet environment when trying to connect to DialogFlow Google Cloud Project recently and it appeared to be intermittent fault but it turned out to be global $env:GOOGLE_APPLICATION_CREDENTIALS in windows PowerShell was pointing to a key file set when first setup access to GCloud days before and since regenereated keys in GCP Console
After generating new key file and setting it with new generated key file using $env:GOOGLE_APPLICATION_CREDENTIALS="[Path_To_JSON_Key_File]" the problem went away but fix only lasted as long as the window was open, then after a while ran $env:GOOGLE_APPLICATION_CREDENTIALS on a newly opened PS window and noticed it was still pointing to the old key file!
setting the system environment variable GOOGLE_APPLICATION_CREDENTIALS to the value of [Path_To_JSON_New_Key_File] fixed it, all newly opened PS windows had the correct key file and authenticated correctly using Service Account and .Net Google Cloud API calls worked after that