I'm using googlerequest object to retrieve notification data for a certain serial-number in sandbox environment.
POST argument (xml) I send to google:
<?xml version="1.0" encoding="UTF-8"?><notification-history-request xmlns="http://checkout.google.com/schema/2"><serial-number>631274667786221-00005-6</serial-number></notification-history-request>
Response from curl:
HTTP/1.1 500 Internal Server Error
Content-Type: application/xml; charset=UTF-8
Date: Mon, 03 Jun 2013 12:28:57 GMT
Expires: Mon, 03 Jun 2013 12:28:57 GMT
Cache-Control: private, max-age=0
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Set-Cookie: S=payments_api=P4yzgVwZyqdAb7S_BUtJXw; Expires=Mon, 03-Jun-2013 12:58:57 GMT; Path=/; Secure; HttpOnly
Server: GSE
Transfer-Encoding: chunked
<?xml version="1.0" encoding="UTF-8"?>
<error xmlns="http://checkout.google.com/schema/2" serial-number="f9338a0b-b14a-4afc-956b-5618b9741245">
<error-message>Internal error in server</error-message>
</error>
Can't answer for Google but it seems Google Checkout sandbox seems to have been shutdown / deprecated (already). This is my guess/perception as I cannot login to my Google Checkout sandbox which was at https://sandbox.gogle.com/checkout/sell for sandbox related activity like integration settings, debug console, etc.
I do see that the former sandbox Merchant center is accessible at:
https://wallet-web.sandbox.google.com/manage
So you can check sandbox orders (across different APIs) but as stated, it doesn't have the knobs/switches relevant to Google Checkout (other APIs have different "consoles" for API settings).
I don't know why (if it's early deprecation)...perhaps it's late in the game as it pertains to Google Checkout retirement to start debugging now....
See Google Checkout deprecation/retirement in November 2013 announcement and more info.
Update
Q: issue happens when I set the following options and send them via curl(): $options['shopping-cart.buyer-messages.include-gift-receipt-1'] = 1; $options['shopping-cart.buyer-messages.special-instructions-1'] = '';
You mean in the initial Checkout POST you sent to Google? If so, that instruction tells Google to offer those screens at the Google Checkout web site (not yours). I believe you shouldn't provide values for one field only - you'll have to provide all fields if you want to pre-populate from your web site.
Sorry, really tough to debug without Integration Console (which was part of the original Google Checkout console/UI in both sandbox and production) - which likely would have shown more error detail....
Related
According to QuickBooks Ruby API documentation, it provides an example of using curl to submit a POST request to the authorization url obtained from Step 1, but right underneath it, it shows that if the web application doesn't support browsers, to use Playground or a web component.
My question is – is it actually possible to use the curl command as shown in the example? If I take the exact URL and try to establish a POST request, I get the following results:
bash-3.2$ curl -X POST "https://appcenter.intuit.com/connect/oauth2?client_id=[redacted]&redirect_uri=http%3A%2F%2Flocalhost&response_type=code&scope=com.intuit.quickbooks.accounting&state=be17472c59724eb46bfe2690"
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
bash-3.2$
Obviously it's trying to redirect to another URL, but the API documentation doesn't show the usage of the -L parameter to follow redirects. If I try to provide the -L parameter for curl to follow redirects, then I get the following response:
bash-3.2$ curl -X POST "https://appcenter.intuit.com/connect/oauth2?client_id=[redacted]&redirect_uri=http%3A%2F%2Flocalhost&response_type=code&scope=com.intuit.quickbooks.accounting&state=be17472c59724eb46bfe2690" -L
<HTML><HEAD>
<TITLE>Bad Request</TITLE>
</HEAD><BODY>
<H1>Bad Request</H1>
Your browser sent a request that this server could not understand.<P>
Reference #7.2500e8ac.1592267832.14229c52
</BODY>
</HTML>
Again, doesn't work even following redirects. If I append -I to the curl command, then I get the following:
bash-3.2$ curl -X POST "https://appcenter.intuit.com/connect/oauth2?client_id=[redacted]&redirect_uri=http%3A%2F%2Flocalhost&response_type=code&scope=com.intuit.quickbooks.accounting&state=be17472c59724eb46bfe2690" -LI
HTTP/2 301
date: Tue, 16 Jun 2020 00:37:17 GMT
content-type: text/html
content-length: 162
location: https://appcenter.intuit.com/app/connect/oauth2?client_id=[redacted]&redirect_uri=http%3A%2F%2Flocalhost&response_type=code&scope=com.intuit.quickbooks.accounting&state=be17472c59724eb46bfe2690
server: nginx
cache-control: no-store, no-cache, must-revalidate
strict-transport-security: max-age=3156000; includeSubDomains; preload
HTTP/2 302
date: Tue, 16 Jun 2020 00:37:17 GMT
content-type: text/plain;charset=utf-8
content-length: 406
location: https://accounts.intuit.com/index.html?partner_uid_button=google&offering_id=Intuit.sbg-fms.ippdevx&redirect_url=https%3A%2F%2Fappcenter.intuit.com%2Fapp%2Fconnect%2Foauth2%3Fclient_id%3D[redacted]%26redirect_uri%3Dhttp%253A%252F%252Flocalhost%26response_type%3Dcode%26scope%3Dcom.intuit.quickbooks.accounting%26state%3Dbe17472c59724eb46bfe2690
server: nginx
strict-transport-security: max-age=15552000
intuit_tid: 1-5ee8143d-29a68cec2ec922da5c6be528
x-spanid: ad76586b-a5ac-41bd-b2df-022148a5a78b
x-amzn-trace-id: Self=1-5ee8143d-3aa839e8b2cf25d846078238;Root=1-5ee8143d-29a68cec2ec922da5c6be528
x-dns-prefetch-control: off
x-download-options: noopen
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
cache-control: private,no-cache,no-store,pre-check=0,post-check=0,must-revalidate
expires: -1
pragma: no-cache
set-cookie: hosted-shell=%7B%22clientId%22%3A%22a4676677-5191-4eca-873e-34a04b5b1dd4%22%7D; Path=/; Expires=Fri, 14 Jun 2030 00:37:17 GMT; Secure
vary: Accept, Accept-Encoding
cache-control: no-store, no-cache, must-revalidate
strict-transport-security: max-age=3156000; includeSubDomains; preload
HTTP/2 411
server: AkamaiGHost
mime-version: 1.0
content-type: text/html
content-length: 223
expires: Tue, 16 Jun 2020 00:37:17 GMT
date: Tue, 16 Jun 2020 00:37:17 GMT
If I take the same URL and request it via a web browser, then it just takes me to the redirect callback URL as it's supposed to. I can't figure out why curl isn't doing the same thing. I don't understand what it means by "web component" if I can't even replicate the same thing via curl. I also have another web module that I'm using for GET and POST requests, and they're bringing me to an HTTP200 but not the callback URL.
Any idea how I could accomplish getting this authorization token from the redirect callback URL like it does in the web browser? Here's another example of me trying to do this via the web component in the Ruby script:
[3] pry(#<QuickBooksAPI>)> grant_url
=> "https://appcenter.intuit.com/connect/oauth2?client_id=[redacted]&redirect_uri=http%3A%2F%2Flocalhost&response_type=code&scope=com.intuit.quickbooks.accounting&state=be17472c59724eb46bfe2690"
[4] pry(#<QuickBooksAPI>)> response = WebRequest.new.get_request(grant_url)
=> #<Net::HTTPMovedPermanently 301 Moved Permanently readbody=true>
[5] pry(#<QuickBooksAPI>)> response['Location']
=> "https://appcenter.intuit.com/app/connect/oauth2?client_id=[redacted]&redirect_uri=http%3A%2F%2Flocalhost&response_type=code&scope=com.intuit.quickbooks.accounting&state=be17472c59724eb46bfe2690"
[6] pry(#<QuickBooksAPI>)> response = WebRequest.new.get_request(response['Location'])
=> #<Net::HTTPFound 302 Found readbody=true>
[7] pry(#<QuickBooksAPI>)> response['Location']
=> "https://accounts.intuit.com/index.html?partner_uid_button=google&offering_id=Intuit.sbg-fms.ippdevx&redirect_url=https%3A%2F%2Fappcenter.intuit.com%2Fapp%2Fconnect%2Foauth2%3Fclient_id%3D[redacted]%26redirect_uri%3Dhttp%253A%252F%252Flocalhost%26response_type%3Dcode%26scope%3Dcom.intuit.quickbooks.accounting%26state%3Dbe17472c59724eb46bfe2690"
[8] pry(#<QuickBooksAPI>)> response = WebRequest.new.get_request(response['Location'])
=> #<Net::HTTPOK 200 OK readbody=true>
[9] pry(#<QuickBooksAPI>)> response.uri
=> #<URI::HTTPS https://accounts.intuit.com/index.html?partner_uid_button=google&offering_id=Intuit.sbg-fms.ippdevx&redirect_url=https%3A%2F%2Fappcenter.intuit.com%2Fapp%2Fconnect%2Foauth2%3Fclient_id%3D[redacted]%26redirect_uri%3Dhttp%253A%252F%252Flocalhost%26response_type%3Dcode%26scope%3Dcom.intuit.quickbooks.accounting%26state%3Dbe17472c59724eb46bfe2690>
This time it sends me to a 200 but it never actually sends me to the callback/redirect URL.
I'm just simply trying to complete step 2 but cannot do so without a browser it seems, even using "web components" and curl.
Am I just going to have to manually use OAuth Playground and continuously just refresh my token since my API is all backend and no front-end/user redirect, etc.?
The OAuth grant flow needs your end user to grant your authenticate your application before you call API using access tokens. So here is what you process would look like
Present your user with a Connect to Intuit (or equivalent) button
User Clicks on the button and goes through authentication on intuit website (seems like the first bit of code you have inserted in your question. This cannot be automated)
Intuit redirects to the redirect url with a authorization_code
Rest is automated - Your browser or server takes the authorization_code from the url, combines it with a few other parameters and requests for an access_token
You can then continue to use the access_token to make your calls on behalf of the end user.
From Step3. onwards you can use curl to process all of it. Hope this helps :)
EDIT
No, In your case you would use OAuth differently. Using the Oauth Playground will take create an initial access_token for you. Steps 1-4 are taken care of.
Now you can use this token to authenticate all your API calls. However, the token will expire. So when you do get an expired response then you have to do a curl to fetch a new token using the info here...
https://developer.intuit.com/app/developer/qbo/docs/develop/authentication-and-authorization/oauth-2.0#refresh-the-token
HTTP/1.1 401
X-message-code: PWD_WRONG
WWW-Authenticate: Basic realm="SAP HANA Cloud Platform"
Transfer-Encoding: chunked
Date: Fri, 18 Oct 2019 11:06:40 GMT
Server: SAP
Set-Cookie: BIGipServerl4097iflmapavrhcip.factory.customdomain=!Nu8jU3HA2IxyvHz2sXeD7QV2Vba36noiDcfL3aW4P6aJ3bFLqxzKN/NcLEGyHmjUFAx3qBE6h10zBwU=; path=/; Httponly; Secure; httponly; secure
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Some times, the site may encode the password at the frontend and then send it to the server which can decode it. Check with your dev team if the password is encoded by a javascript before being sent
Logically X-message-code: PWD_WRONG indicates that you provided wrong password. Double check your credentials in the HTTP Authorization Manager, it might be the case you made a typo, even characters which are not visible like whitespace or line break matter.
Looking into Create new user on Cloud Integration thread:
The message displayed (PWD_WRONG) means the member has never logged into the SCP Account and no credentials were provided to it.
Also looking here it might be the case you need to supply an appropriate client-side certificate
I'm a bit unsure what it happening here but ill try to explain what is happening and maybe write a better question once i figured out what i'm actually asking.
I have just installed Varnish which seems awesome for my request times. It is a Magneto 2 store which I have followed the default configuration within dev docs for varnish.
My Issue
Currently my issue is that the browser seems to be caching the page until i click refresh. I believe i am successfully flushing / purging the cache with magento / varnish. As when using Curl to request the page i can see a new page is generated each time i flush cache and just serves cached page if i don't.
Within chrome and firefox however on my client pc however the whole page markup seems to be cached (when clicking a link to page or pasting url in browser) until clicking refresh which seems to reload the real page. When deploying new static files etc as the old resources are still in the cached markup and the new location for resources is signed e.g. version1234/styles.css and not matching the markup i get CSS less pages until client clicks refresh and loads the actual markup from server?
How can i setup caching so that this does not happen?
Curl -IL result of URL:
HTTP/1.1 200 OK
Date: Fri, 24 Nov 2017 12:08:32 GMT
Strict-Transport-Security: max-age=63072000; includeSubdomains
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Expires: Sun, 26 Nov 2017 15:55:17 GMT
Cache-Control: max-age=186400, public, s-maxage=186400
Pragma: cache
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Vary: Accept-Encoding
X-UA-Compatible: IE=edge
Content-Type: text/html; charset=UTF-8
X-Magento-Cache-Control: max-age=186400, public, s-maxage=186400
X-Magento-Cache-Debug: HIT
Grace: none
age: 0
Accept-Ranges: bytes
Connection: keep-alive
Browser caching takes please because of these headers being sent:
Expires: Sun, 26 Nov 2017 15:55:17 GMT
Cache-Control: max-age=186400, public, s-maxage=186400
You should adjust your server configuration so that those are not sent for PHP. Most likely you have a configuration block in nginx or .htaccess that applies to the whole website, as opposed to just static files.
I try to use fetch list of Calendar Resources (https://support.google.com/a/answer/60766?hl=en) from my company's Google Apps, using Google API. I try to use it using OAuth 2.0 Playground page (https://developers.google.com/oauthplayground). What I do:
1. I select scope & authorize API with my company's admin account and using this scope https://apps-apis.google.com/a/feeds/calendar/resource/
2. I xchange authorization code for tokens
3. I put a requested URL: https://apps-apis.google.com/a/feeds/calendar/resource/2.0/my-company-domain-url/
4. I send request and I get error:
HTTP/1.1 403 Forbidden
Alternate-protocol: 443:quic,p=1
Content-length: 207
X-xss-protection: 1; mode=block
X-content-type-options: nosniff
Transfer-encoding: chunked
Expires: Fri, 18 Dec 2015 22:09:43 GMT
Server: GSE
-content-encoding: gzip
Cache-control: private, max-age=0
Date: Fri, 18 Dec 2015 22:09:43 GMT
X-frame-options: SAMEORIGIN
Alt-svc: quic=":443"; ma=604800; v="30,29,28,27,26,25"
Content-type: text/html; charset=UTF-8
<HTML>
<HEAD>
<TITLE>You are not authorized to access this API.</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
<H1>You are not authorized to access this API.</H1>
<H2>Error 403</H2>
</BODY>
</HTML>
I've already enabled this API in Developers Console.
Question: what else do I need to do to make it work, i.e. be able to fetch calendar resources list?
I was simply missing the enabled flag for Administrative API access, described here:
https://support.google.com/a/answer/60757?hl=en
second thing, more obvious is that only domain admins have access to this API.
Additionally, I've just found that in version 1.21 of Admin-SDK Java Client library (com.google.apis:google-api-services-admin-directory) Google added support for Calendar Resources! So all you need to do now is:
Directory.resources().calendars().list("my_customer").execute();
The scope is new: https://www.googleapis.com/auth/admin.directory.resource.calendar so one needs to authorize it API in Google Apps Admin console.
You might want to try this link, https://developers.google.com/google-apps/calendar/v3/reference/acl/list.
This should give you a list of resources.
Here is a link for the Overview info, https://developers.google.com/google-apps/calendar/v3/reference/acl.
I hope it helps.
I am not using the SBT, but making direct REST calls with Abdera to the current version of Connections on IBM SmartCloud. REST URL in question: https://apps.na.collabserv.com/search/serviceconfigs
Observations
When testing from my laptop (using Firefox and the REST client add-on,) this works as expected. I get back an ATOM feed.
When testing from a server (on a different network,) using the same method (Firefox + REST client,) I get back HTML that is a log-in page.
In addition, I get this same result when I call the URL from a Java program on the same server.
In all cases, I am using the same credentials with basic authentication.
Update: If I log into SmartCloud first, on a separate tab in Firefox on the server, then call the URL as before, from another tab, it works. I get the ATOM feed as desired. Naturally, this is unsuitable as a solution, but I present it as additional information that could lead to an actual solution.
Update: Further testing shows that the local (laptop) log-in exhibits the same behavior as the server. A form-based log-in is required from the same browser, then subsequent REST calls work.
Update: Here is a relevant simplified code snippet:
private static Abdera ABDERA = new Abdera();
private static AbderaClient ABDERA_CLIENT = new AbderaClient(ABDERA);
...
String host = "https://apps.na.collabserv.com";
ABDERA_CLIENT.addCredentials(host, AuthScope.ANY_REALM, "basic", new UsernamePasswordCredentials("user", "password"));
...
ClientResponse response = ABDERA_CLIENT.get("https://apps.na.collabserv.com/search/serviceconfigs");
Summary
It appears that something about the originating server or the call is causing SmartCloud to respond with a log-in page. Whereas, the same call and credentials from my laptop, work as expected.
Question
Where should I start to trouble-shoot this? How can I build the client credentials to allow programmatic log-in?
Response Headers
If it helps, here are the response headers that I get back in each case.
Unsuccessful
Status Code: 200 OK
Cache-Control: no-cache
Connection: keep-alive
Content-Encoding: gzip
Content-Length: 1850
Content-Type: text/html
Date: Tue, 08 Oct 2013 14:15:03 GMT
Pragma: no-cache
Server: WebSEAL/6.1.1.3 (Build 110428)
Set-Cookie: PD-H-SESSION-ID=4_0_IR4***masked***oRKlJI;secure; Path=/; HttpOnly BIGipServerE3A-WebSEAL-80-fe=2132806922.20480.0000;secure; path=/
Vary: Accept-Encoding
p3p: CP="NON CUR OTPi OUR NOR UNI"
Successful
Status Code: 200 OK
Cache-Control: public, max-age=86400, s-maxage=86400, no-cache=set-cookie, private, must-revalidate
Content-Encoding: gzip
Content-Language: en-US
Content-Length: 1164
Content-Type: application/atom+xml; charset=UTF-8
Date: Mon, 07 Oct 2013 17:21:12 GMT
Expires: Tue, 08 Oct 2013 17:21:12 GMT
Server: WebSphere Application Server/8.0
Vary: Accept-Encoding
p3p: CP="NON CUR OTPi OUR NOR UNI"
x-lconn-auth: true
x-powered-by: Servlet/3.0
#Grant is your login using SAML? I could see this redirect happening. also could be TFIM related... maybe you should grab the auth on a different page, store the cookies, and then try connecting to the endpoint above.