I'm wondering if it is somehow possible to display a private report if we don't have access to the account or company's Data Studio environment? Using the Google API would be ideal.
The reason why we need an API is because the reports need to be displayed on a distributed network of displays where user interaction is not possible. They are all separated from each other and run on their own browser instance. Setting the reports public to embed them is not an option due to sensitive data being exposed to the internet. Embedding is fine but we need some way of accessing the customers data without user interaction, i.e. via access tokens or something. If the user authenticates to our app beforehand and that allows us to then use their access token inside of the embed iframe would be fine too.
As far as I can tell I cannot display private reports through the official google-data-studio API. I did find another stackoverflow link that mentions something about community connectors. Would this still be a solution to our problem if we don't own the reports itself? We are just displaying the reports but do not have access to their Google Cloud environment nor their data sources.
Any help is appreciated.
This is not supported by Google Data Studio.
In short, if you can't make your report public, and you can't authenticate to view it, you're out of luck.
The link you provided is much more a hack than a feature. It suggests you to make your data public with a custom authentication mechanism developed in a Community Connector that requires a token as parameter.
This way, your report will be available to anyone, however, since your report requires the token to work (a kind of password), it won't show any data to unauthorized users (those who don't provide a valid token).
Although it is possible, I think it requires so much effort to make it work, and, of course, it requires that you change the connector of your report. So 'yes', you need to own the report to connect to your data through the suggested Community Connector.
Related
I have written a plugin in dynamics CRM. This plugin accesses a few Web API 2 methods that are deployed in Azure cloud (via HTTPS). The plug-in is triggered when a contact data in the CRM changes. Many CRM account holders will update the contact data.
I am going to hard code a 'secret key' (a one time generated Guid) in the plug-in and send this key every time I access the web api methods. I'll validate this guid in the web api methods to prevent un-authorized access.
I do not like to store the secret key (guid) in the source code.
Questions
What are my alternatives if do not want to 'hard code' the secret key?
What are the security flaws in this approach?
Note
In general, all my Web APIs are authenticated by a custom authentication web api filter, but the Web APIs that are accessed from the plugin are not part of the custom authentication.
CRM version is 2013
As the previous answers states, the first option is to store your information in a configuration custom entity that you can retrieve from your plugin. Those records are going to be protected by the CRM security model, so if your plugin is running in the calling user context you will need to make sure that the users have privileges to read that information (not really a good idea) or change the plugin to be executed under an admin user context.
Another option is to use Secure/Unsecure Configuration:
Those are two (string) parameters that you can configure within the step and you will be able to read them from the plugin. I would say that the secure configuration fits your requirement but give it a look. You can also easily find how to implement it (example).
The third and last option that I can think of, is to create an XML WebResource and read it from the plugin. Again, you will need to make sure that the user context under the plugin is running has access to it.
I don't think this approach will ever be secure.
It's possible to extract the plugin assembly from CRM. Someone could then disassemble the assembly and find the Guid. Effectively your password is stored in plain text.
At the very least you could store the user name/password/secret key in a CRM record. The CRM record can then be protected with CRM security.
You are probably better off implementing the authentication 'normally'.
The main use case is using IPython as CLI to my own Google accounts. What I am really after is minmizing the fussing around between starting the IPython shell and actually issuing usefull calls against the API.
The docs for authenticating with Google APIs focus on setting up application which other user will use to access their data.
This leads to a lengthy Oauth dance involving a browser in order to allow other users to authenticate without compromising their credential.
However, I do not mind sharing my private credentials with myself. I am not planning on sharing the code. If I did share the code I would use something like dotenv to separate the credentials from the code.
Twitter provides developers a second set of credentials
that allows developers to access their own accounts for testing.
Thus it is possible to access ones own account programmatically
by just providing to sets of credentials: the developer credentials that allow the calls to the API and the other credentials that grant access to the developers own data. For example:
from twitter import *
t = Twitter(
auth=OAuth(token, token_key, con_secret, con_secret_key))
# Get your "home" timeline
t.statuses.home_timeline()
# Update your status
t.statuses.update(
status="Tweeting from Python")
Where con_secret* are the developer credentials and
and token* are the account access credentials.
How can I do something equally simple with Google APIs?
Where can I get credentials to access my own account?
How would I use them in Google API?
As an example what would be the simplest procedure for retrieving the contents from one of my own Youtube playlists?
I have com to think that a Python headless browser library could be give me what I need. I have asked a related question on SE Software Recommendations
https://softwarerecs.stackexchange.com/questions/35744/python-headless-browser-library-for-oauth2-authentication-from-ipython-console
I would like to download a set of credentials
Google offers this ability through it's client_secrets.json file. There are different ways to download this, depending on the type of account you want to use (Web application, installed application, Service account). The different techniques can be found here .
Store the credentials locally and keep using them without requiring
new credentials every call
This also isn't a problem, the client secret is valid until you renew it - AFAIK there is no automatic expiry unless you specify otherwise.
Once you have downloaded your client_secrets.json, store the file in a non-public directory (normally inside your project directory/config).
Similar to the downloading of the file, there are different techniques (flow classes) to use the JSON file depending on what type of account you are using. As an example, the below would be used for installed and web applications;
from oauth2client.client import OAuth2WebServerFlow
...
flow = OAuth2WebServerFlow(client_id='your_client_id',
client_secret='your_client_secret',
scope='scope URL here',
redirect_uri='http://example.com/auth_return')
Other flow class examples can be found here
Hope this helps - If you need further information, the official documentation (which be warned, can be incredibly inaccurate and confusing) can be found here https://developers.google.com/api-client-library/python/guide/aaa_oauth
I have this example - Embed API Third Party Visualizations - working locally and on a test server, but I'm unsure of what I need to do to ONLY display our organization's Google Analytics data instead of the user's personal GA account.
I created the project and clientID within our org's Google Account, but I'm obviously not understanding something big here.
I'm completely new to both GA's API and oAuth in general, so while I'm sure this has been answered multiple times, I wasn't completely sure which direction to look in. If someone can give a helpful nudge in the right direction I'll happily be on my way.
Thanks everyone!
Embeded API uses Oauth2 to authenticate. Oauth2 requires that a user give you access to their Google Analytics data.
You want to show your person Google Analytics data to other users. Normally I would say you should use a Service account, a service account gives the application direct access to a specific account it has to be set up like you would add a user to Google Analyitcs. The problem is the Embeded API uses JavaScript, for security reasons its probably not a good idea to use a service account with JavaScript. I also think it may be against Googles terms of service to use a service account with JavaScript. That being said I have never found anyone who has gotten a service account to work with JavaScript probably for the reasons I just stated.
Drop the embedded API and switch to a server sided language of some kind and code it yourself. What you want to do cant be done with the embedded API.
I have a google calendar that I have marked as shared. it stores all appointments for the day.
I have a webpage. from the webpage, the user enters a date and I use the google api (javascript) to pull back all info from my shared calendar for that date and present it to the user.
I also want the user to be able to make appointments during free times on any given day.
problem is, I must be signed in to my google account. if I am NOT signed in, I get a little popup asking for my userid/password.
how do I get rid of that? I had hoped that making the calendar shared and specifying the client ID and api key (assigned via Google's API Console) would have been enough.
I've run across this: http://cornempire.net/2012/01/08/part-2-oauth2-and-configuring-your-application-with-google/ which explains doing this via Oath and refresh tokens in PHP.
unfortunately, I'm doing this in javascript and MUST do it from the client side. is that possible?
I think you should look into using a service acccount for this.
http://code.google.com/p/google-api-php-client/wiki/OAuth2#Service_Accounts
By using a service account you wont have to worry about people loging in. They will have access to the calender for the service account.
Update: I have searched for examples of how to do this in Javascript and have been unable to find any. After considering this issue for a while now i have come to the conculsiton that even if you could use a service account via javascript for security reasons its probably not a good idea.
Unfortuantly this leaves me to beleave that the anwser to your question is No. You cant do this client sided. If you use normal OAuth2 its still going to prompt you for the autentication. You need to try and reconsider a server sidded option. PHP for example
Our company has a web application that is only used internally by our employees. We also have Google Apps Premier Edition. We would like to make it so our employees can log into our private web application using the Google Apps account that they already have.
Requirements: We want to display our own login form. We don't want to pass the email/password in plain text through the internet.
Which authentication mechanism should we use to achieve this?
Note: our application is written in PHP using Zend Framework (if that matters).
I would look into some combination of OpenID and your domain users (i.e. only let those at domain.com can log in).
Google API
They also have libraries for PHP and other languages that you can leverage to make this happen.
EDIT:
Some more info
When it comes to integrate Google Apps and an internally used private system, we simply have two options.
Use Google as the authentication center. Modify the private system to authenticate at Google's server. We could use OpenID or AuthSub. Check http://code.google.com/apis/accounts/docs/OpenID.html and http://code.google.com/apis/accounts/docs/AuthSub.html for more information.
Use the private system as the authentication center. In this case, we have to implement SAML protocol in the private server and configure Google Apps's SSO settings. Check http://code.google.com/googleapps/domain/sso/saml_reference_implementation.html for more information.
It is easier to accomplish SSO with the first method since there's already bunch of OpenID libraries out there. But, as you described in the requirements, you want to use your own login form. So I guess you have to go with the second method.
BTW, if your private system has to get or set information from Google, you may want to use OAuth for authorization. See http://code.google.com/apis/accounts/docs/OAuth.html for more information.
Use the ClientLogin API, it does exactly what you're after: allow you to verify username and password. (the link goes to provisioning API doco but that is not relevant here)
Pro's:
you get to use you own login form
Cons:
you don't get SSO with Google Apps, i.e. users already in Apps will be prompted to login again (you didn't mention that as a requirement, but it seems a reasonable thing to want)
Google won't like you (they're trying to discourage ProgrammaticLogin.
you will get occasional CAPTCHA tests you'll need to show your users.
OpenID specifically prevents you from displaying your own login page, so if that's a hard requirements, Programmatic Login is really your only choice.
Going the SSO route let's you do pretty much anything, but may be a bit of overkill to take on authentication for the whole domain to make one app authenticate in a nicer fashion? If you really want to go down this route, check out SimpleSAMLphp.