I have integrated PayPal SDK in my android app and done transaction successfully in sandbox environment.Now the second step mentioned in docs is verification . I tried to hit rest Api with payment id in browser but it dint give me any response . So please tell me the proper way of verification .Here is the link I have followed
Also I have got client secret key but dont know where to use it . Will it be needed in verification process ?
Yes, you will need your ClientID and Secret to generate an Access Token that will then be used in subsequent Payment Lookup call. More information on creating the Access Token can be found here under step 2 of Getting an Access Token. That Access Token is then used in the payment lookup API call that you see on the Verify Mobile Payment link you provided in your question. More information/samples of a RESTful Payment Lookup call can be found here as well.
Related
I would like to create an app in which there is a mobile (Android) client which uses REST API from the server. A user has to login with Facebook account (using Facebook SDK's LoginButton); on success this should create a user account on the server at the first log in.
I've already read a lot of tutorials about how to secure HTTP API using SSL and access tokens, but there is one point which I don't get. The flow should look like this:
a user log in on the Android app with the Facebook LoginButton
in the Android app I receive an access token on successful log in which I can push to the server
I can validate this access token against Graph API
if validation in 3. is succesful I can create a user account on the server
all other calls to my server API can be secured with received access token or other token which would be created by me
but what about the 2. point? I have to expose API call which takes an access token and creates an account. This API call won't be secured, so if someone calls it with stolen/properly fabricated access token, then I will create an account which shouldn't exist. How to solve this? Do I have to assume that if my create account API is called with an access token which is valid (because I validate it in 3.) then everything is ok? Is there a better solution?
You are right, never trust the client. Always validate all client input again on the server.
In your case, you're validation of the token on the server in Step 3 should include comparing the result from Graph API with the result from decrypting the user info from the token. If both match, then proceed.
There are several code examples on Facebook website on how to do this correctly. They are available in several server languages (e.g. PHP) so I recommend reviewing them.
I am creating an Android app with an App Engine backend and am trying to use OAuth2 to authenticate users through their Google Account on the Android device, but am not able to figure out if I need to carry out all of the following steps or whether just step 1 would suffice.
Step 1: In this tutorial by Google, they have created a GoogleAccountCredential using the Google account found on the device and passed it to the backend API hosted on App Engine.
Step 2: In this other tutorial, they have passed this credential only if getting an OAuth2 access token in the Android app returns no error.
Step 3: In yet another tutorial, it has been advised that the backend should check the token sent by the Android client to verify that Google generated this token and that the device that asked for the token matches the audience value in the backend.
So my question is: do we really need steps 2 and 3 in an Android app whose backend is hosted on App Engine or does App Engine take care of 2 and 3 if we pass a credential created for the Google Account found on the phone to the backend API?
Another thing is how often and where in my code should I authenticate the app user:
1. Is it required before each endpoint call?
2. Or is it enough to just run the authentication code just when the app launches?
3. Or better yet, if it is enough to authenticate based on just step 1, would it be okay if I get the user's Google email address from the AccountManager, store it with SharedPreferences and create a GoogleAccountCredential based on the stored email whenever I make an endpoint call until the user explicitly asks to sign out or switch account?
Please help me decide which approach would make most sense. Like always, thanks so much for helping out! :)
Tim's article (step 3) above is correct. When a server receives a token it must verify that it was intended for them. This is something that Google Cloud Endpoints will do for you, by configuring the client IDs / audience fields such as per the example here: https://developers.google.com/appengine/docs/java/endpoints/auth
I ended up passing the GoogleAccountCredential created with the account name found on the phone to the endpoint builder. Then, in the endpoint API method, I added a User parameter which was automatically populated by App Engine after authenticating the user based on the credential passed to the endpoint builder. As a final check, I compared whether User.email was giving the same email address that I used to create the GoogleAccountCredential.
For sure authenticate on the back end. If you pass them in in the standard way GAE should automatically use that as your credentials. The UserService should give you the user details with no effort on your part on the server side.
My Android app needs to send an authorization code to my server so that the server can use that to acquire an access token for the user's Google Drive account. I have been trying to figure out how to acquire the authorization code and I found this in the Google API documentation (Using OAuth 2.0 for Installed Applications):
This sequence starts by redirecting a browser (system browser or
embedded in the application as a web view) to a Google URL with a set
of query parameters that indicate the type of Google API access the
application requires. Like other scenarios, Google handles the user
authentication and consent, but the result of the sequence is an
authorization code. The authorization code is returned in the title
bar of the browser or as a query string parameter (depends on the
parameters sent in the request).
After receiving the authorization code, the application can exchange
the code for an access token and a refresh token. The application
presents its client_id and client_secret (obtained during application
registration) and the authorization code during this exchange. Upon
receipt of the refresh token, the application should store it for
future use. The access token gives your application access to a Google
API.
Now I am not sure how to get this authorization code in my Android app since the Android examples I have seen seem to get the access tokens directly. I am looking at the Android AccountManager class and it has a method getAuthToken but this seems to refer to the access token and not the authorization code.
So how does one acquire the authorization code that can be shared with a server? If it is possible I would greatly appreciate some example code. If this is not possible what are the possible workarounds?
You may want to take a look at the Cross-client Identity document. It should keep you from needing to pass user tokens back and forth.
I believe you can actually take the access token returned by the Android AccountManager, send this to your server, then have your server make a call against the Google Drive API using that same access token - it is a bearer token and not bound to the channel that created it, so please take good care of it and only send over encrypted connections.
Documentation on how to get that access token can be found here:
https://developers.google.com/drive/quickstart-android
While that access token is good for immediate use, it will expire in less than 1 hour, so if you are looking for a solution that enables your backend server to have continued access to the Drive data, without the user being present at your app at the time of request, an alternate approach will be needed.
I'm trying Google Plus sign-in in an Android app (with backend support).
I could get access token and email from the user, but know I don't know how should I recognise this user from the server. I'm sending this to the server (email and oauth token) with a POST throught SSL
Of course I could recognise them with their email, but that would open the doors for everyone how knows another email that's on the database.
How could I verify that the user's correctly authenticated and has sent me the correct oauth token for this email?
Thanks!
Two thoughts:
1) Generally, you shouldn't be sending the auth token over the wire if you can help it. Instead you should be using a hybrid flow where the client gets a one time code when it authenticates, passes you this one time code, and you can redeem this for an auth token and a refresh token. Using this method, your server also has offline access on behalf of the user. See https://developers.google.com/+/web/signin/server-side-flow for details. However, I'm not entirely sure how this works with the Android library.
2) Regardless of (1), generally what you can do is to use the plus.people.get method on the server with the userID of "me" to get the user's userID and verify this against what you're expecting. See https://developers.google.com/+/api/latest/people/get for more details.
Yours is a perfect case to use the Authorization code flow.
See this link. It has some workflow diagrams that you might want to see. In your case the user should authenticate and receive an authorization code (and not a token!).
He would then send the authorization code to your server, you can exchange this code for access + refresh tokens. Have your client registered for the scope and have the client credentials.
The access token flow (called the implicit grant flow) is generally used when requests need to be sent directly from the user's browser.
And, as #Prisoner already mentioned, you will have offline access too. That would be a much better design.
EDIT - you might also want to take a look at What is the difference between the 2 workflows? When to use Authorization Code flow?
I'd like to be able to send a POST request from an Android app to App Engine and have it linked to the user's Google account. I read that you need to obtain an authentication token and send it with the POST request. Does Android provide a way to request this token? And how would GAE process it?
I feel like this should be easy and I'm missing something obvious.
Thanks!
See my blog post on how to authenticate with an App Engine app using credentials stored in the phone.
It is possible to authenticate users programmatically. In the Python SDK, the appengine_rpc module performs this function. In a nutshell, the procedure is this:
Use ClientLogin to get a one-use authentication token given the user's username and password.
Make a POST request to yourapp.appspot.com/_ah/login, with the arguments continue=http://localhost/&auth=authtoken (where authtoken is the one-use token you got from step 1).
Intercept the 302 response returned and capture the returned Google cookie.
Supply the cookie on all subsequent requests.
For excruciating detail, see the source of appengine_rpc.py, linked above.
As of Android 2.0, you can use AccountManager to request an auth token for accounts of type com.google. You can then authenticate the user to an App Engine app by hitting the url:
http://[yourapp].appspot.com/_ah/login?auth=[theauthtoken]
The cookies set in the response can be piggybacked onto future requests to your app to authenticate the user against your app.
In the absence of sample code that does exactly this, you can check out the Sample Sync Adapter code (bundled with the SDK) for a general idea about requesting auth tokens.
EDIT: Just realized Nick wrote about the second part, but the AccountManager#getAuthToken bit is new as of Android 2.0.