I've followed the Order Processing tutorial to receive and handle order notifications in my GAE application from Google Checkout.
Everything works OK in the sandbox environment. I can send a fake order and the app gets a notification and handles the order.
When I switch to the production environment and make a real order, I can see the order in the Google Checkout Merchant account but I don't receive any notifications.
To switch to production I simply edit my ApiContext object to use Environment.Production and the real merchant id and key. The Integration settings are the same. I've also tried changing the callback URL to use HTTPS (https://blah.appspot.com/not) but still nothing.
What am I missing?
The "Integration Console" in the Checkout Merchant Center gives you information about the callbacks (XML sent, XML received, HTTP errors, etc.). Hopefully you can figure out the problem from that data. Some related links below:
https://checkout.google.com/support/sell/bin/answer.py?hl=en&answer=72217
http://code.google.com/apis/checkout/developer/Google_Checkout_XML_API.html#integration_issues_console
http://code.google.com/apis/checkout/articles/Troubleshoot_Integration_Console_Errors.html
Related
I've been studying logs in Logs Explorer in Google Cloud Platform and noticed that available logs don't show the body of a POST request, which is crucial for my task (I run Google Tag Manager Server-Side and need to study logs of all inbound Measurement Protocol requests). Is there a way to enable the body contents for requests like this one?
There's no built in feature in GCP Logging to do this just as norbjd said.
Only thing that's being logged by default are GET requests and only the first line:
First line of the request, containing method, path, and HTTP version. Example: GET / HTTP/1.1
Have a look at the answer here and then the fallowing comments fallowing:
A logging.info() shows up (link)
I have, and it does show up (with an i left to it) in the Stackdriver request logs and that is the only way to see POST arguments (link)
You may also try a solution from the next answer:
post request data isn't shown in request logs.
In your app, you must explicitly log it
logging.log(myRequest.PostData)
Edit: just be careful logging sensitive customer information.
It was working fine till last day and suddenly stopped pushing to endpoint. Checked all settings including endpoint URL and found everything remains unchanged. Can you guys suggest possible causes.
Not receiving a message on a push endpoint could happen for many reasons. The first thing to do would be to go to Stackdriver and create a graph for the subscription/push_request_count metric. You can break this down by response_code to see how many requests Cloud Pub/Sub is sending to your push endpoint and what response codes it is returning. If there are requests being delivered that are returning errors, this graph will show that.
It might also be worth checking the publish side to ensure messages are still being published as expected. You can look at the topic/send_message_operation_count metric, which can also be broken down by response_code, to make sure the publish requests are all returning success.
You should also check to ensure the subscription still exists using the Pub/Sub Subscriptions page in the Cloud console. After 30 days of inactivity (including inability to successfully deliver a message to a push endpoint), subscriptions are potentially deleted.
If the issue still unsolved after those steps, it is best to contact Google Cloud support with your project ID and subscription name so that things can be investigated for your specific case.
In my case we work with other companies which would consume our APIs along with our internal javascript client. I think we need to create a web client id for javascript client. But when exposing APIs externally, is it correct to generate new web client id per company? If so do we have to update clientid each time and redeploy application?
I'm following this documentation and in their example client ids are hardcoded, if I need to give access to new 3rd party users, then I need to generate new client id for them but I'd expect to not redeploy application.
Update: I've created a feature request as per #Alex's suggestion below.
Unfortunately the docs at https://cloud.google.com/appengine/docs/python/endpoints/auth very specifically say, and I quote,
Because the allowed_client_ids must be specified at build time, you
must rebuild and redeploy your API backend after adding or changing
any client IDs in the authorized list of allowed_client_ids or
audiences
so it appears that your perfectly-reasonable use case is very explicitly not covered at this time.
I recommend you visit said page and enter a feature request via the "Write Feedback" link (around the upper right corner of the page) as well as entering a feature request on the Endpoints component of the App Engine feature tracker, https://code.google.com/p/googleappengine/issues/list?can=2&q=component=Endpoints&colspec=ID%20Type%20Component%20Status%20Stars%20Summary%20Language%20Priority%20Owner%20Log -- we monitor both, but with different processes, so trying both is best.
Sorry to be a bearer of bad news. For now, it seems the only workaround is to distribute to the other companies one of a bunch of client ids generated in advance (you can only change the valid bunch when you re-deploy, sigh) and perhaps add some extra, app-layer authorization check of your own -- exactly the kind of work endpoints should be doing on your behalf:-(.
You can use an asterisk as the client ID, that will allow any client to call it without redeploying your API backend. Not sure if this is a documented feature or not, but it works (at least) with both Python and Java.
#Api(name = "myapi",
version = "v1",
scopes = {"https://www.googleapis.com/auth/userinfo.email"},
description = "My flashy API",
clientIds = {"*"})
public class MyAPI { ... }
Steps to Reproduce (unexpected behavior in bold):
I successfully create an app contact via the Python Starter App
I successfully subscribe to timeline notifications
I take a photo with Glass
I share that photo with my app contact
The photo is duplicated on the timeline
The app's callbackUrl is never pinged (yet POSTing manually via curl works fine)
Attempting to delete the duplicated photo card makes the Glass OS glitch out until reboot
Posting some sample code with actual URLs may help us spot a possible error, but two things you may want to look into as you're debugging:
Don't forget that the URL in your contact must be HTTPS. HTTP URLs are not supported.
Check the contact object that is returned when you create the contact. It may be worth checking to make sure the URL and everything else is as you expect it to be... and then test against THAT URL.
Can you also clarify what you mean by "glitch out" in this case?
One of my clients uses Trend Micro InterScan Messaging Security to protect their internal mail services.
Suddenly InterScan decided to filter out all messages coming from Google App Engine.
Unfortunately they haven't been able to whitelist the sender address as each e-mail gets a different one. For example, *3ckihSOVMMHlZHSL.JSMMHlZHSL.JS*#apphosting.bounces.google.com, with everything before the # being variable.
Update I'm including this screenshot of how Interscan sees the incoming e-mail. Notice that all senders are different:
If I look into the e-mail headers, the apphosting domain appears inside the Return-Path field:
Return-Path: <36kSiSwYIBh0883XL3E7.5EH883XL3E7.5E#apphosting.bounces.google.com>
The "From" field looks ok. It says what I set it to say, but the spam filter only looks at the Return-Path.
My client sysadmin doesn't want to whitelist the whole apphosting domain, as it wouldn't be only whitelisting my application.
How could I bypass this e-mail filters if I can't get an unique sender?
Thanks,
You can't change the return-path header of mail sent by App Engine. The way I see it, you have two options:
Whitelist everything from App Engine. Spam from App Engine is not a big problem, because it's expensive to send in the huge numbers spammers need, and we're constantly monitoring for spamming and shutting spammers down.
Whitelist based on the X-Google-Appengine-App-Id header, which will be set to the app ID of your app.
I am not well versed in spam filters, but it seems to me that if it can only whitelist based on one field, it is pretty lame. Unfortunately that does not help you. If this is an important client, and they absolutely refuse to budge, I see two possible paths forward:
Do some research into interscan to see if you can give the client some pointers (tactfully) on how to configure it to whitelist in such a way that your mail can get through, but only your mail.
Maintain a server outside app engine specifically for the purpose of sending emails. You can build a super simple web app that just sends out emails, and call it from within your app engine app.