Important: API has changed - Read this first:
https://developers.google.com/accounts/docs/AuthForInstalledApps
ClientLogin has been officially deprecated as of April 20, 2012. It
will continue to work as per our deprecation policy, but we encourage
you to migrate to OAuth 2.0 as soon as possible.
I want to build two application client (some python/java program) and server (Google App Engine application) and authenticated with google acount from client to server to get some secret information.
Let me explain scenario:
Server has address https://example.appspot.com.
Client want download restricted information from https://example.appspot.com/restricted so this url is defined and login: required in app.yaml.
Client use some Google Account example_login and example_password to get access.
How properly authenticate from client into Google App Engine to get access to https://example.appspot.com/restricted?
Another easy method, without login, is to use HMAC. You create a MAC signature based on timestamp (to make every request unique) and a secret MAC KEY. You request contains the timestamp and the MAC signature. The server can verify the MAC, because it also has the secret MAC KEY.
This Python code works on both sides (client and server)`:
import hmac, base64, hashlib
new_hmac = hmac.new(key=my_secret_MAC_KEY, msg=timestamp_in_request, digestmod=hashlib.sha256)
signature = base64.b64encode(new_hmac.digest()).decode()
if signature_in_request != signature : raise ValueError('access denied')
This works fine for a single user, because you have to manage a single key. When you have a lot of users, client login is a much better option.
Related
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 switch from basic Google Street View API to Premium. As such, when I'm using:
(space after https is added because I can't post more than two links in the post)
https:/ /maps.googleapis.com/maps/api/streetview?location=40.720032,-73.988354&size=400x400&fov=90&heading=235&pitch=10&key=MY_PREMIUM_API_KEY
I get an image with a Google watermark, which does not scale further than 640x640, same as when using a basic API key.
Okay, to use the advantages of Premium GSV API, I also need to make a digital signature. I've generated a secret key and signed my url (with dropped domain, as said in the tutorial) using python code from there: https:/ /github.com/googlemaps/url-signing/blob/gh-pages/urlsigner.py - it generates just the same signature as one on the Google website: https://developers.google.com/maps/documentation/streetview/get-api-key?hl=en_GB#premium-key
Finally, I add the signature to the URL:
(space after https is added because I can't post more than two links in the post)
https:/ /maps.googleapis.com/maps/api/streetview?location=40.720032,-73.988354&size=400x400&fov=90&heading=235&pitch=10&key=MY_PREMIUM_API_KEY&signature=MY_BASE64_SIGNATURE
However, this is what I get in return instead of an image:
"The Google Maps API server rejected your request. This API project is not authorized to use this API. Please ensure that this API is activated in the APIs Console: https://console.developers.google.com/apis/library?project=_"
It cannot be that API project is not activated, as basic API with this project & Premium key works. Any ideas, why does it happen and Premium image download doesn't work?
It appeared to be a purely technical problem, the quotas were exceeded.
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 { ... }
I am busy writing an mobile application that connects with IBM SmartCloud. Since I want to use OAuth 2.0 I find it difficult to handle the Secret Key and the Client ID.
Since I have to Register the Application within the IBM SmartCloud console, and copy the Client ID and Secret Key to the App I am creating... Well that ain't the biggest problem, but when someone wants to use my app on another environment he doesn't have the same Secret Key and Client Id.
What is the best way to deal with this, because I want to make it usable for others, and not only for my use.
You may want to refer to the ibmsbt.openntf.org - the sources include directory includes a project for iOS. It's tested with IBM Connections On Premises
http://www.openntf.org/main.nsf/project.xsp?r=project/Social%20Business%20Toolkit%20SDK/releases/F07E34DFDDA6C06686257C6B006C6393
The project uses a callback to a custom PROTOCOL/URL : ibmsbt://myapp?code=
For IBM Connections/SmartCloud, you'll want to register an OAuth2 Key.
When you register you'll want to register your application, ibmsbt://myapp/
Then You can use these endpoints and parameters:
https://apps.na.collabserv.com/manage/oauth2/token/manage/oauth2/authorize?response_type=code&client_id=app_20085940_1384885218905&callback_uri=ibmsbt%3A%2F%2Fmyapp%2Fcallback
https://apps.na.collabserv.com/manage/oauth/authorizeToken?oauth_token=OAUTH_TOKEN
I'm doing https web requests in silverlight using "WebRequest"/"WebResponse" framework classes.
Problem is: I do a request to an url like: https://12.34.56.78
I receive back a versign signed certificate which has as subject a domain name like: www.mydomain.com.
Hence this results in a remote certificate mismatch error.
First question: Can I somehow accept the invalid certificate, and get the WebBresponse content ? (even if it involves using other libraries, I'm open to it)
Additional details: (for those interested on why I need this scenario)
I'm trying to give a client access to a silverlight app deployed on a test server.
Client accesses the silverlight app at: www.mydomain.com/app
Then I do some rest requests to: https://xx.mydomain.com
Problem is I don't want to do requests on https://xx.mydomain.com, since that is on our productive server. For this reason I use https://12.34.56.78 instead of https://xx.mydomain.com.
Client has some firewalls/proxies and if I simply change his hosts file and map https://xx.mydomain.com to 12.34.56.78, web requests don't resolve to the mapped IP.
I say this because on his network webrequests fail if I try that, on my network I can use the hosts changing without problems.
UPDATE: Fixed the problem by deploying test releases to an alternative: https://yy.domain.com and allowing the user to configure for test purposes, the base url to which I do requests to be: https://yy.domain.com.
Using an certificate that contained the IP in the subject or an alternative subject would've probably worked too, but would have cost some money to be issued by a certified provider and would not be so good because IP's might change.
After doing more research looks like Microsoft won't add this feature too soon, unless there's a scenario for non-testing/debugging uses.
See: http://connect.microsoft.com/VisualStudio/feedback/details/368047/add-system-net-servicepointmanager-servercertificatevalidationcallback-property