My idea is to use verifiable credentials for logging into my Kotlin Android app. For that purpose I use Aries Cloud Agent (aca-py). For communication with an agent there is an API. This agent enables creation of the connection between wallet (lissi, trinsic, esatus, etc.) and agent and afterwards sending proof request. The data from proof request (verifiable credential with for example first name, last name, email) are than used to login.
Each of these steps requires specific API request. It is possible to implement each step as separate button. In that case, user should first press button to create QR code that can be scanned from wallet and therefore establish connection. After than second button should be pressed to send proof request. And once the credentials are presented, third button should be pressed so that an app takes that info from agent with a GET request. However my idea is to automate this whole process.
That can be done using agents webhooks that can inform app once there is a new connection created and that can be used as trigger to send second proof request. The same happens once the proof request is sent. However, I am not sure how to implement push notification into my app once there is a new webhook.
I read that it can be done with Firebase and AWS Amplify. In both cases I think should pay for it and to be honest I am not too familiar with their services. Is there some other option? Does anyone know some free alternative? Currently my idea is just to build like a prototype so there is no need for production services. Thanks in advance!
A web hook is basically an external-facing URL which can take a payload, etc. You can create these endpoints using Cloud Functions onRequest. these use express based request/response callbacks
https://firebase.google.com/docs/reference/functions/providers_https_#onrequest
http://expressjs.com/en/4x/api.html#res
For example:
From the client side,
Start a listener in realtime db to the users ID, then: Create a dynamic link or a cloud function URL which can be rendered as a QR code A B C, and from there: a series of URL's and Dynamic Links for each step of the way. the user's client can get real-time updates from Firebase while this process is going on, allowing you to update the user with the current process and instructions.
https://firebase.google.com/docs/database/web/read-and-write#web-v8_2
The keynote is to associate the process with a one-time disposable token, so that your webhooks can know which user the process can follow. You could use the user's ID, but this can be predicted and spoofed if any webhook endpoint is exposed.
Realtime DB:
processing: // location for all clients processing can listen to for updates
+userId: { // userID so that the location is predictable should the client disconnect
+--"State": "state1",
+--"URL":"https://url.for.qr/code?=disposable_token"
}
status: // location for all webhook processing and tracking of stats
+token: { // userID so that the outcome is predictable should the client disconnect
+--"User": "userID",
+--"stage":"authenticating"
+--"createdAt":"Date.now()"// track when the process started, ensure that requests can expire after X minutes/hours
}
To the client, the button presses can be automated purely with a realtime db listener
My app does not have access to any privileged scopes but it does access ride_widgets scope. In it, it is clearly mentioned "Includes access to trip information for rides you request through the app and the current ride,...". So from where do I get access to this trip information (specifically Ride ID)?
The problem I am facing is while accessing the user's history, my app cant differentiate which among them was done through my app. The only unique identifier in it is request_id/Ride ID but while that trip happened, the ride request view is completely shielding my app from any details about the ongoing trip except those which my app provided (like start location, latitude etc)
Is it meant to be like this or am I missing something?
It is not currently possible with the Ride Request widget. The best way to find an in progress request id would require using the privileged request scope and the /requests/current endpoint.
You can get the ride id from the underlying service that the widget uses to make the ride request:
Ride ride = service.requestRide(rideRequestParameters).execute().body();
String rideId = ride.getRideId();
See more details for using the api via their android sdk.
You likely should request history scope if you want access to the users trip history. With the ride request widget you can only request a ride using the button or widget.
While trying to fetch contacts using google account of user , I am facing some issues after using people API.It only returns few email addresses out of all listed ones.Access token and all scopes have been set correctly.
Code for following :
People peopleService = new People.Builder(httpTransport, jsonFactory, credential)
.build();
ListConnectionsResponse response = peopleService.people().connections().list("people/me")
.setPageSize(500).setSortOrder("FIRST_NAME_ASCENDING")
.setAccessToken(tokenResponse.getAccessToken())
.setAlt("json")
.setRequestMaskIncludeField("person.names,person.emailAddresses,person.phoneNumbers")
. execute();
connections = response.getConnections();
Instead of this if I use contact API of google then I am getting more no of email addresses than people.Code for contact API :
URL feedUrl = new URL("https://www.google.com/m8/feeds/contacts/default/full");
ContactFeed resultFeed = myService.getFeed(feedUrl, ContactFeed.class);
// Print the results
System.out.println(resultFeed.getTitle().getPlainText());
for (ContactEntry entry : resultFeed.getEntries()) {
....
.....
.......
}
I want to know if there is any difference between both of them and which one i have to use for better results or am I missing something. please suggest. Thanks..!!
People API is more up-to-date. Reading through Google's blog announcement, People API simplifies what needed to be separate calls to Google+ API and Contacts API. Now you only need to use one.
"The new People API uses the newest protocols and technologies and
will eventually replace the Contacts API which uses the GData
protocol"
When getting the user's list of connections, be sure to specify the correct scopes when using it.
https://www.googleapis.com/auth/contacts - Requests that your app be given read and write access to the contacts in the authenticated user’s Google Contacts.
https://www.googleapis.com/auth/contacts.readonly - Requests that your app be given read access to the contacts in the authenticated user’s Google Contacts.
Check this link for similarities and differences between People API and Contacts API.
I'm not sure if there is any issues with the java code, but if you look at the request that is sent out it should be like this:
URL:https://content-people.googleapis.com/v1/people/me/connections?pageSize=300&requestMask.includeField=person.names%2Cperson.email_addresses&sortOrder=FIRST_NAME_ASCENDING&key=
I was able to get all the contacts with the correct email and name. If you google "manage google contacts" you will see a list of contacts. From there take that number, and just print out the connection count which should match. You just need to make sure the pageSize is big enough or you have to handle paging to get all the contacts.
Also i realized that the requestMask.includeField is really sensitive to what parameters and spaces you put. "person.name,person.email_addresses" worked and "person.name, person.email_addresses" did not.
With the older contact api, you can query the q parameter which I don't think the people api provides this ability. I think the ability to filter your search by key words is important to reduce the request size.
I have a simple app (needs user login with account). I provide some premium features for paid users, like more news content.
I need to record if the user has bought this item in my server database. When I provide data content to user's device, I can then check the user's status, and provide different content for paid user.
I checked the official Trivialdrive sample provided by Google, it does not provide any sample code for server-side verification, here are my questions.
I found the sample use my app's public key inside to verify purchase, it looks not good, I think I can just move the verification process to my server combined with user login credentials to see whether the user purchase completed, and then update the database.
Also there is purchase API I can use to query, what I need is to pass the user's purchaseToken into server.
I am not sure what method I should take to verify the user's purchase, and mark the user's status in my database, maybe both?
And I am afraid there is a situation, if a user bought this item from google play, but for some reason, just in that time, when my app launched verification to my server, the network connection is down or my own server is down, user just paid the money in google play but I did not record the purchase in my server? What should I do, How can I deal with this situation.
It sounds what you're looking for is a way to check if the user has premium features enabled on their account, so this is where I would start;
Ensure there is a flag of some sort on your database indicating if the user has premium features and include that in the API response payload when requesting account info. This flag will be your primary authority for "premium features".
When a user makes an in-app purchase, cache the details (token, order id, and product id) locally on the client (i.e the app) then send it to your API.
Your API should then send the purchaseToken to the Google Play Developer API for validation.
A few things might happen from here:
The receipt is valid, your API responds to the client with a 200 Ok status code
The receipt is invalid, your API responds to the client with a 400 Bad Request status code
Google Play API is down, your API responds with a 502 Bad Gateway status code
In the case of 1. or 2. (2xx or 4xx status codes) your client clears the cache of purchase details because it doesn't need it anymore because the API has indicated that it has been received.
Upon a successful validation (case 1.), you should set the premium flag to true for the user.
In the case of 3. (5xx status code) or a network timeout the client should keep trying until it receives a 2xx or 4xx status code from your API.
Depending on your requirements, you could make it wait a few seconds before sending again or just send the details to your API when ever the app is launched again or comes out of background if the purchase details are present on the app cache.
This approach should take care of network timeouts, servers being unavailable, etc.
There are now a few questions you need to consider:
What should happen immediately after a purchase? Should the app wait until validation is successful before providing premium content or should it tentatively grant access and take it away if the validation fails?
Granting tentative access to premium features smooths the process for a majority of your users, but you will be granting access to a number of fraudulent users too while your API validates the purchaseToken.
To put this in another way: Purchase is valid until proven fraudulent or; fraudulent until proven valid?
In order to identify if the user still has a valid subscription when their subscription period comes up for renewal, you will need to schedule a re-validation on the purchaseToken to run at the expiryTimeMillis that was returned in the result.
If the expiryTimeMillis is in the past, you can set the premium flag to false. If it's in the future, re-schedule it again for the new expiryTimeMillis.
Lastly, to ensure the user has premium access (or not), your app should query your API for the users details on app launch or when it comes out of background.
The documentation on this is confusing and weirdly verbose with the things that are almost inconsequential while leaving the actually important documentation almost unlinked and super hard to find. This should work great on most popular server platform that can run the google api client libraries, including Java, Python, .Net, and NodeJS, among others. Note: I've tested only the Python api client as shown below.
Necessary steps:
Make an API project, from the API Access link in your Google Play console
Make a new service account, save the JSON private key that gets generated. You'll need to take this file to your server.
Press Done in the Play console's service account section to refresh and then grant access to the service account
Go get a google api client library for your server platform from https://developers.google.com/api-client-library
Use your particular platform's client library to build a service interface and directly read the result of your purchase verification.
You do not need to bother with authorization scopes, making custom requests calls, refreshing access tokens, etc. the api client library takes care of everything. Here's a python library usage example to verify a subscription:
First, install the google api client in your pipenv like this:
$ pipenv install google-api-python-client
Then you can set up api client credentials using the private key json file for authenticating the service account.
credentials = service_account.Credentials.from_service_account_file("service_account.json")
Now you can verify subscription purchases or product purchases using the library, directly.
#Build the "service" interface to the API you want
service = googleapiclient.discovery.build("androidpublisher", "v3", credentials=credentials)
#Use the token your API got from the app to verify the purchase
result = service.purchases().subscriptions().get(packageName="your.app.package.id", subscriptionId="sku.name", token="token-from-app").execute()
#result is a python object that looks like this ->
# {'kind': 'androidpublisher#subscriptionPurchase', 'startTimeMillis': '1534326259450', 'expiryTimeMillis': '1534328356187', 'autoRenewing': False, 'priceCurrencyCode': 'INR', 'priceAmountMicros': '70000000', 'countryCode': 'IN', 'developerPayload': '', 'cancelReason': 1, 'orderId': 'GPA.1234-4567-1234-1234..5', 'purchaseType': 0}
The documentation for the platform service interface for the play developer API is not linked in an easy to find way, for some it is downright hard to find. Here are the links for the popular platforms that I found:
Python | Java | .NET | PHP | NodeJS (Github TS) | Go (Github JSON)
Complete example of using Google API Client Library for PHP:
Setup your Google Project and access to Google Play for your service account as described in Marc's answer here https://stackoverflow.com/a/35138885/1046909.
Install the library: https://developers.google.com/api-client-library/php/start/installation.
Now you are able to verify your receipt the following way:
$client = new \Google_Client();
$client->setAuthConfig('/path/to/service/account/credentials.json');
$client->addScope('https://www.googleapis.com/auth/androidpublisher');
$service = new \Google_Service_AndroidPublisher($client);
$purchase = $service->purchases_subscriptions->get($packageName, $productId, $token);
After that $purchase is instance of Google_Service_AndroidPublisher_SubscriptionPurchase
$purchase->getAutoRenewing();
$purchase->getCancelReason();
...
You can try using Purchases.subscriptions: get server-side. It takes packageName, subscriptionId and token as paramaters and requires authorization.
Checks whether a user's subscription purchase is valid and returns its
expiry time.
If successful, this method returns a Purchases.subscriptions resource in the response body.
I answer to this concern
the network connection is down or my own server is down, user just
paid the money in google play but I did not record the purchase in my
server? What should I do, How can I deal with this situation.
The situation is:
User purchases 'abc' item using google play service -> return OK -> fail to verify with server for some reasons such as no Internet connection.
Solution is:
On the client side, before showing the 'Google Wallet' button, you check if the 'abc' item is already owned.
if yes, verify with server again
if no, show the 'Google Wallet' button.
Purchase purchase = mInventory.getPurchase('abc');
if (purchase != null) // Verify with server
else // show Google Wallet button
https://developer.android.com/google/play/billing/billing_reference.html#getSkuDetails
Marc Greenstock's answer is definitely enlightening, a few things to pay attention though which took me a long time to figure out (at least way more time than I expected):
I had to check "Enable G Suite Domain-wide Delegation" on Service Account settings. Without this I kept getting this error: "The current user has insufficient permissions to perform the requested operation"
Image with Enable G Suite Domain-wide Delegation option checked
For testing purposes you can create a JWT token for your service account here, just don't forget to select RS256 Algorithm.
The public key is the "private_key_id" from your downloaded JSON file. It also has the following format:
-----BEGIN PUBLIC KEY-----
{private_key_id}
-----END PUBLIC KEY-----
The private key is the "private_key" from your downloaded JSON file
The required claims for the JWT generation are described here.
Confused about what exactly a JWT Token is and how it is assembled? Don't be ashamed, check this link. Odds are you are just like me and took a long time to bother looking for what exactly it is, it is (way) simpler than it looks.
I had some serious problems using the suggested google API python library, but implementing the communication from scratch is not so hard.
First of all you have to create a service account at Google Play Console as described in all answers and get the JSON file containing the private key. Save it to your server.
Then use the following code. No need to obtain the google API client library. You only need the following (very common) python libraries Requests and Pycrypto
import requests
import datetime
import json
import base64
from Crypto.Signature import PKCS1_v1_5 as Signature_pkcs1_v1_5
from Crypto.Hash import SHA256
from Crypto.PublicKey import RSA
jwtheader64 = "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9"
#SERVICE_ACCOUNT_FILE: full path to the json key file obtained from google
with open(SERVICE_ACCOUNT_FILE) as json_file:
authinfo = json.load(json_file)
packageName = #your package name
product = #your inapp id
token = #your purchase token
#create the JWT to use for authentication
now = datetime.datetime.now()
now1970 = (now - datetime.datetime(1970,1,1)).total_seconds()
jwtclaim = {"iss":authinfo["client_email"],"scope":"https://www.googleapis.com/auth/androidpublisher","aud": "https://oauth2.googleapis.com/token","iat":now1970,"exp":now1970+1800,"sub":authinfo["client_email"]}
jwtclaimstring = json.dumps(jwtclaim).encode(encoding='UTF-8')
jwtclaim64 = base64.urlsafe_b64encode(jwtclaimstring).decode(encoding='UTF-8')
tosign = (jwtheader64+"."+jwtclaim64).encode(encoding='UTF-8')
#sign it with your private key
private = authinfo["private_key"].encode(encoding='UTF-8')
signingkey = RSA.importKey(private)
signer = Signature_pkcs1_v1_5.new(signingkey)
digest = SHA256.new()
digest.update(tosign)
signature = signer.sign(digest)
res = base64.urlsafe_b64encode(signature).decode(encoding='UTF-8')
#send it to Google authentication server to obtain your access token
headers = {'Content-Type': 'mapplication/x-www-form-urlencoded'}
payload = "grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion="+jwtheader64+"."+jwtclaim64+"."+res
r = requests.post("https://oauth2.googleapis.com/token",headers=headers,data=payload)
if r.status_code == 200:
authdata = json.loads(r.text)
accesstoken = authdata['access_token']
bearerheader = {'Authorization':'Bearer '+authdata['access_token']}
#Now you have at last your authentication token, so you can use it to make calls. In this example we want to verify a subscription
url = "https://androidpublisher.googleapis.com/androidpublisher/v3/applications/"+packageName+"/purchases/subscriptions/"+product+"/tokens/"+token
subscription = requests.get(url,headers=bearerheader)
the network connection is down or my own server is down,
You don't have to think like this.
Client knows own's consume product. so, client can send all tokens back to the server.
Just re-check token with produce id and transaction id.
And Server checks consume product.
if you fail check
make UI button client can re-send token.
server re-check token for items.
It's done.
We want to be able to associate app users with real transactions done.The problem is that we have the user’s email address on application back end side, and we track user purchase amounts, but when we go into the Google Wallet transactions we have no way of knowing which transaction/s belong to that user. We need a solution for this, because even if we have the user's email, we cannot search transactions by email address.
Is it possible to update the receipt numbers we are sending in the API to include the Google Wallet Receipt number instead of the time stamp ?
Please, provide us your suggestions.
I thought the answer would lie in the postback facility. That gives google's user ID and order number. However, I didn't see how to convert either of those to an email address for sending the digital good just purchased.
BTW. I rejected doing the fulfilment client side as that seemed insecure. If I'm wrong about that then why would they offer the postback facility?
... then I realised, we could do part of it client and part server side.
I guessed that something comes back from the client-side success callback.
success: function(result) {
console.log('success',result.response.orderId);
complete(result.response.orderId);
},
So, I now have the google's orderId on the client side and there I know the user's ID. So my complete() function can send the orderId and our userId to the server which can then match this with successful payment orderId from the postback (which happens first) and fulfil the order.
Yes, this is inelegant, but I believe it to be a secure solution.
Maybe slightly more elegant is to use the [sellerData] property in the submission payload to contain our user ID and order ref. We then have more items to match after the success callback has happened. I think I'll hold off delivering the digital good until all those checks have been completed.
What I do not understand is why cannot this kind of suggestion (or a better one) be found in the wallet tutorial?
Paul
My answer here refers to the previous answer provided:
Totally agree on "why cannot this kind of suggestion (or a better one) be found in the wallet tutorial?".
Your suggested solution does not seem to be very secured (to say the least). You want the client to send you their username/email/client-id in the Success callback... This means that anyone will be able to send you their ID, even if they did not make a purchase. They can add a random order-ID and hope to get a match (and then repeat the process many times in order to increase the chances).
My guess is that the username/email/client-id lies somewhere in the request object sent from Google to the postback URL (your server's doPost routine). But I have the feeling that you need to add something in the JWT generated in your Purchase function before it is passed to the google.payments.inapp.buy routine.
Looking for an answer myself...
Here is a possible solution, although I have not yet tested it myself:
Download the 'zip' file from: https://code.google.com/p/wallet-online-quickstart-java/downloads/list
Take the entire 'com' folder and add it to your project source folder (sorry, I have not been able to find a JAR for this package). Then, add the following code to your servlet:
...
import com.google.wallet.online.jwt.JwtResponseContainer;
import com.google.wallet.online.jwt.util.JwtGenerator;
import com.google.wallet.online.jwt.JwtResponse;
...
public void doPost(HttpServletRequest request, HttpServletResponse response) ...
{
try
{
String maskedWalletJwt = request.getParameter("maskedWalletJwt");
JwtResponseContainer jwtResponseContainer = JwtGenerator.jwtToJava(JwtResponseContainer.class, maskedWalletJwt, SellerSecret);
JwtResponse jwtResponse = jwtResponseContainer.getResponse();
String email = jwtResponse.getEmail();
...
}
}
One thing I'm not so sure about, is request.getParameter("maskedWalletJwt").
You might have to add this parameter when calling the google.payments.inapp.buy routine.