In mirror api glassware we identify users by the unique user id generated and sent to the glassware by Google-oauth... But my glassware contains a gdk counterpart which needs to send information to the mirror api service. My question is that how do we send such information (e.g. an url request to the glassware mirror-api service) automatically in the background, without using "google notification by sharing with a specific contact", so that we can uniquely identify the user from mirror api glassware side as well as extract the information for the rest of the purpose.
Is there any glass Id that I can send along with the request from gdk and on the mirror-api side get the user's google account from this glass Id and using some other api generate the user Id from the google account just like google-oauth. Once we have the user Id, we can send static timeline cards to that user using simple mirror-api.
Please guide me with whatever solutions available other than "notification subscription".
I've already asked a question like this here: How to call the Mirror API from GDK?
It's seeming like the answer right now is that we can't communicate between the two APIs and everything in Mirror is separate from GDK. I've been doing some digging, trying to get things like the device's contact list since the Mirror documentation refers to your app adding a Contact but it seems like it doesn't use the same Content Providers as Android for this.
From the other thread, my best two ideas for binding a GDK app to a User is to:
1) Generate a QR code on your web service side and scan that in, it will have an encoded authentication token the app will be able to use to identify the user. Obviously this requires integration with the ZXing library and working with the camera.
2) Generate or allow the user to enter a phrase on the web service side that can be treated as a bearer token. In the GDK, prompt the user to speak this phrase and then pass it to your web service, which will reply with a similar authentication token to tie the app to the user. As odd as this is, I do kindof like it since it's simpler from a GDK implementation side.
An application that uses the Mirror API is more likely than not some type of a web service. Why can you not invoke HTTP commands from Glass to your application being hosted on a server?
The Mirror API is a set of REST commands invoked to a Google Server. That same google server then syncs to Glass where Glass will pull the updated content with HTTP requests.
Simply put, create a path in your web app that accepts HTTP commands.
Related
I have an App Engine project which:
uses google.appengine.api.get_current_user() to handle users (and login:required)
has a URL to collect some data (which requires login)
has Google users but on a custom domain
I used to have a script to pull the data using the old https://www.google.com/accounts/ClientLogin interface, but now that interface is deprecated, I'm trying to work out what I need to do to get OAuth2 working to access my App Engine URL with a user value set.
I have worked my way through OAuth2 for devices to get myself an access key for my script (i.e. I can run it, authenticate in a web browser, then poll for the access key), as described in OAuth2 For Devices.
But I'm not sure:
what scope I should be using to request the access_token compatible with get_current_user(),
how to pass this in my request to App Engine so that it can create the the user header, and
whether I need to modify my app to use this access_token, eg adding callbacks etc
With regards to the last point, user was set by google's front end infrastructure so I’m hoping that that same infrastructure can somehow convert my OAuth access_token into a login name without me needing to update my app to do the callback part, because it should all be in appengine's infrastructure right and user is set before the request comes to my app.
I understand how the authorization process with Oauth works but is it somehow possible to authorize my access to my endpoints API without the user having to sign in? So what I'm trying to do is to restrict access to my API so that only certain websites, that I allow, have access to it and no others.
In Google APIs console I have created a 'client ID for web applications'.
In your described use case, the preferred solution is to use OAuth. In following the examples in the documentation, you'll be limiting the web sites (via the "JavaScript origins" value for the keys you obtained in the APIs Console).
Sites not listed in the origins will not be able to display the required authentication prompt (the client ID and origin are checked before Google will provide tokens). Developers will not be able to create their own client IDs with their preferred JavaScript origins, because your backend will be checking the client ID of the request is on a whitelist that is part of your code.
Hello dear contributors!
I am stalling again, I have researched for a tutorial or some directions as to how to adapt this wonderful tutorial:
http://msdn.microsoft.com/en-us/WAZPlatformTrainingCourse_ACSAndWindowsPhone7
To a in browser silverlight application instead of the windows phone ? I'd like to keep the current model, with public and private databases and ideally plug the silverlight application into the azure social games pack :
https://github.com/WindowsAzure-Toolkits/wa-toolkit-games
Which uses a similar ACS pattern, the directions I need are regarding the client handling of Oauth2.
Thanks in advance for any help in this matter.
If it's an in-browser silverlight application, why don't you treat it as a regular website? The flow will be something like
The user browse your app
Before you send the XAP, your website shows the list of identity providers. The user pick one and gets redirected to log in.
User logs in and you will get a token posted to your app (which is the Social Gaming Toolkit). The good news is that the Social Gaming Toolkit already provides integration with ACS on the website so there is not much work to do. The user will get a cookie generated by Windows Identity Foundation with the claims inside (no silverlight involved for now).
Now you send the XAP and the Silverlight app gets loaded
From now on every request done from the XAP to your app (which will have the Social Games Toolkit) will have the Principal populated because the WIF cookie is sent in every request.
If you want to change the user experience a bit and instead of showing the identity provider list in a regular HTML/asp.net page, you want to do it from the Silverlight app (like the Windows Phone lab shows). Then you only need to consume the ACS JSON endpoint which lists your identity providers from your Silverlight app.
The toolkit is already doing that and you can extract the basic ideas from:
https://github.com/WindowsAzure-Toolkits/wa-toolkit-games/blob/master/code/SocialGames.Web/Services/AuthService.cs#L29
The request to get the list of identity providers in JSON looks like this:
https://your_servicenamespace.accesscontrol.windows.net/v2/metadata/IdentityProviders.js?protocol=wsfederation&realm=your_application_realm&version=1.0&context=some_contextual_data_youwanttokeepacrossredirects"
Finally, this lab should help you as well
http://msdn.microsoft.com/en-us/IdentityTrainingCourse_SilverligthAndIdentity2010
FWIW, the way the Windows Phone will works is by using the JavaScript notify endpoint in ACS, which is different from what I described above.
The flow is something like
Phone shows the login options (Facebook, LiveID, etc.)
User click on one of them
User is redirected to ACS and then redirected to the chosen identity provider
User logs in and some kind of token is sent back to ACS (depending on the identity provider)
At this point ACS will render an HTML page with a bit of JavaScript. This will instruct the browser (which is hosted in your Windows Phone) to send an external signal with a payload (the token in this case).
window.external.Notify('THE_TOKEN');
The phone app will detect the notification and grabs the token
I'm not sure how the JavaScript notify mechanism will work on a Silverlight in-browser application because you are already in the browser. But if you try that, keep us posted.
Matias
I'm pretty new to SalesForce and their Apex language. I've been reading some documentation and tried the integration between Google and SalesForce.
I'm wondering is it possible to emulate an auth token from google to SalesForce?
I'm trying to read a google spreadsheet and then fill up a SalesForce object automatically. The user login will always be the same/universal for this spreadsheet, so I have the credentials required to login.
I am working off of the sample that requires a visualforce, and I'm wondering how would I automatically do the session id token that the google spreadsheet API requires.
Any ideas?
The old-school, hard way would be to send a login() call to the API (available through SOAP messages). Salesforce API is well documented and plenty of examples are available (both in programming languages and for raw XML requests/responses).
But I have no idea what possibilities you have from Google side, if it's only JavaScript then you might not be able to send and retrieve AJAX-like calls to another domain...
Recently another option emerged and that is REST API (no SOAP needed). Looks more promising and easier in my opinion. Quick intro is available here and you'll find more documentation on the bottom of the page.
Last but not least - 2 interesting links:
http://code.google.com/apis/gdata/articles/salesforce.html for some integration tutorial
and built-in integration offered by Salesforce: http://www.salesforce.com/assets/pdf/datasheets/SalesforceGoogleApps.pdf
I've used custom settings to do this. Use OAuth to get a token for Google, then store that token in Salesforce custom settings (Setup-Develop-Custom Settings). You can then retrieve the token for callouts to Google from that custom setting for any user needing access to Google Apps. The downside is, every user will authenticate as your custom setting token user. The upside is that they won't need to individually authenticate. Custom settings are retrievable via Apex using a simple getter, and live as Apex-like objects.
Also keep in mind, Google requires each service to use it's own token. So, if your user wants to use Calendars and Spreadsheets, that's two separate tokens that will need to be stored and retrieved for the callout.
I generally allow users to create their own authenticated session tokens via OAuth if they want to do that, then failover to the custom settings to get the general admin token if necessary.
Are you trying to log into Google Apps from SFDC? There are options for Google Apps within Salesforce, go to Setup > Administration Setup > Google Apps > Settings. I've not used this and it requires some setup, but thought I'd point it out. Aside from that I can only blurt out OAuth (getting users to authenticate with Google from within Salesforce when trying to access Google Apps) and SSO (which I know can be used to authenticate from an external system, though not sure if it works the other way).
Look into the "Named Credentials" menu in salesforce setup.
There, you can store auth credentials for the services accessed via Apex:
"A named credential specifies a callout endpoint and its required authentication parameters. When setting up callouts, avoid setting authentication parameters for each callout by referencing named credentials."
a username/pass combo can be used, or a certificate, or an AWS signature, and there is a JWT option..
Help docs: https://help.salesforce.com/articleView?id=named_credentials_about.htm&type=5
I need to send emails from my web application (on account creation, password reset, etc.). This application will most likely be hosted on a standard hosting site (or possibly on Amazon EC2), not on Google App Engine.
However, I like the ease of use for sending email through App Engine. Is there a way to host your application elsewhere but use App Engine to send emails programatically? I suppose I could send a web request from my application to a custom application on App Engine, parse the request, and then send the email from App Engine.
However, I would like to avoid having to create an application on App Engine even if it is very simple as it would be another item to maintain. Is there a simpler way to just use App Engine as the email gateway, similar to using Google Apps for my Domain?
I don't need to receive email by the application. Also, I would like all emails to come from the same domain (like mail#example.com) regardless of if it were sent from the hosted application or App Engine.
You can do this using remote_api. Simply upload a Python app with nothing but the remote api handler included; you can then use the Python remote api library to send emails via App Engine.
Note that emails sent by the App Engine Mail API have to be from an administrator of the app (or the logged in user, but this doesn't apply over remote api). Thus, you'll want to add whatever from account you want as an administrator to the app.
Edit: As mentioned, I am totally wrong! Above post is correct.
First, I am very positive if you want to use App Engine's features you need to actually build an app on it. You can't use their API on external applications. You are right though that you could simply send a request to your app engine app if you wanted it to send email. I don't see how it would be too hard to maintain if that's all it is doing.
Second, if you are planning to send emails via GMail's service, they don't allow you to mask the from address so you will always see it from whatever gmail address you're sending it from.
Why not just send emails from your application but use whatever email service you use now? In most languages and frameworks, SENDING email and not managing it is a breeze.