Hi everybody,
well, here it is my problem.
I have a corporation gmail user, lets say developer-user#mycompany.com, and I would like to list all the gsheets I have in my gdriver trhough the google API for Java applications, so I generated the credentials I supposed to need:
the email, which was auto-created by google with a different domain,
in this case something like 1234567890#developer.gserviceaccount.com
then I created the p12 key file.
After that I tried the connection and everything ran fine, but It did not list the spread sheets I had, and I figured out that I can not list all the gsheets I had 'till I shared them with the 1234567890#developer.gserviceaccount.com mail/user, but the problem is that I can NOT share anything outside of the #mycompany.com domain, even though the email (1234567890#developer.gserviceaccount.com) created for the authentication is linked to my developer-user#mycompany.com account.
I am not sure if I was clear enough, but what I need is a solution for that. did someone figur out something? may you help me?
Anyway, thank you guys and I appreciate your time.
You'll have to ask your Google Apps Admin to enable sharing outside your domain on Google docs, that's the only way Drive will allow the service account to reach existing docs.
The only alternative is to recreate the docs using the service account (programatically) and share them with your account.
Your admin can delegate domain wide access to your app which will then be able to impersonate you.
Alternatively, don't use service accounts and simply generate a refresh token for your own account (which is by far the easiest solution).
Related
We are developing a Java application that is supposed to show models from users store.
initially, I'm trying to allow users to login using their autodesk account, and check if they are entitled to access my app.
I couldn't find any good example to show how it is done, I just want to confirm that what I will be doing is the recommended thing or if there is better options.
First, on app start, I will show an embedded webbrowser that will open
"https://developer.api.autodesk.com/authentication/v1/authorize?response_type=code&client_id=XXX&redirect_uri=XXX&scope=XXX"
the app will get the url from our server (so not saved locally) and the call back is pointing to an api on our server. then as user login and consent, will get the code from the url, close the login dialog and continue to get the bearer token using plain rest apis to /authentication/v1/gettoken.
As I said, not 100% sure if this is approved way or not or even if it is doable or not. so thought to check before we implement it.
After that I will just use rest apis to browse and get the model.
any thoughts or complains ?
Thanks in advance
Rest assured that the workflow being proposed here is actually orthodoxical and well “approved” by our official tutorials:
https://forge.autodesk.com/en/docs/oauth/v2/tutorials/get-3-legged-token/
http://learnforge.autodesk.io/#/oauth/3legged/
Unfortunaly the code sample for that bit is in node and we are still working on a Java equilvalent
Some of our endpoints require 3-legged oauth to access personal data - see here for an example and you can always refer to the authentication context section of each endpoint for the oauth flow required.
Is it bad if I shared with the ones developing my website my Facebook client id and secret id so that they can create the Facebook logged in button?
He also asked me for all these other information and I gave it all to him to create the Facebook, Instagram, and Twitter logged in button on my website. I also gave him the ones for google.
INSTAGRAM
Client_name
Client ID
Client Secret
Client Status
Website
Description
FACEBOOK
App_id
App_secret
App_page_id
TWITTER
Consumer_key
Consumer_secret
In short: No
This is a question the answer of which depends heavily on the circumstances and kind of setup you have, but in short these days its not a good idea as its easy to avoid the need to share these secrets.
The IDs are normally public so there is no harm in sharing that, but the secret keys should be entered directly into server's (or app service) environment settings if you can manage them yourself. Different hostings have different ways to enable this, consult your hosting provider and developer team to guide you.
When its fine
If you are not technical yourself, don't want to go through the hassle of managing access to your server, find it hard to learn and trust your developers greatly then its fine and they would need it to do actual deployment.
Remember, while they are developing and testing the website/service they can use temporary app-id and secret keys that they themselves can get in most of the cases.
Follow up questions:
Q. If I go to the settings and ask for a new secret key for all of these social services, will it affect the programming of the developers and create a problem or will it be fine since the client id is good enough for the job?
Answer Yes if you reset the secret keys the service would fail and would require the new keys to be configured on the server. There are tons of guidelines on each of Facebook, Google, Instagram developer pages that you can read on this topic and are pretty easy.
Q. Can they get inside my Facebook, Instagram, etc if they have the secret Id?
Answer No the keys are for the app/service to allow your website request user's information who allow your app, not for accessing your account.
Q. Please tell me whats the worst thing that can happen with the secret after sharing it with the developers if they do something wrong with it?
Answer Its basically a security risk. One of the worst things, IMO, that can happen is that they commit it into an open code repository or implement it in the wrong way so its accessible to anyone easily. That would allow attackers/hackers to get your app users to believe they are giving access to their requested data to your app (by using your app id and secret) in their attacks. But again this is heavily based on how careless the developers are, if they are good they would work to keep it secure. Ask them in your next meeting how they are using it and how it will be secure from other people copying it. Chances are they are good people and have taken this into consideration and would also explain it to you.
I have to send an email from IntentService. My data is mostly the backup from a phone. I am using smtp.google.com + javamail.I can use a gmail account and send data through it.(http://www.oracle.com/technetwork/java/javamail/faq/index.html#gmail):
From my point of view the problem with this approach is that my app uses the gmail account and sends data via my account. All personal data would go through one my account. Question#1 - Is it a good approach to do it?
The gmail api uses OAuth 2.0. And I have to store my client ID in some place of my program. I read that it is impossible to restore login/password from it. This token has validity. Question#2 Is it possible to use this token for reading or deleting something from gmail account until it is valid?
For all examples of my app would be the same gmail account. This think bothers me sometimes, because if something happens with gmail account I will not be able to do anything.
Question#3 Is it worth to use services like https://www.mailgun.com/ or maybe to create at least another gmail account and to use them both?
Only if you're the only one using your app.
Yes.
Email is probably not the right solution to your problem. But without knowing more about the problem you're trying to solve and what your requirements are, it's hard to know what to suggest instead.
wso2 identity server is installed and running. I was able to create a policy in it and test a simple scenario. There seems to be a lot of connecting pieces in into this.
it's not clear how to access policy from a Java program and programmatically pass in role, resource and check if logged in user is authorized for performing a particular action or not. I also have requirement to add/remove roles and resources programmatically. Couldn't find much info. Any pointers/examples would be appreciated.
Here are some tutorials on writing client
https://svn.wso2.org/repos/wso2/people/asela/xacml-samples/pep/SamplePEP/src/main/java/org/wso2/carbon/identity/entitlement/samples/pep/EntitlementServiceClient.java
http://hasini-gunasinghe.blogspot.com/2011/12/entitlement-service-xacml-pdp-as-web.html
http://insightforfuture.blogspot.com/2012/09/xacml-policy-definition-pointpdp-proxy.html
I am trying to build an application for android that uses Amazon SimpleDB. I have viewed the source code of the example code provided by Amazon. However in the demo, the credentials are just stored in a Constants.java and I believe this method is not secure at all as potentially there are people that could decompile the apk to expose the credentials even with Proguard on.
Therefore i went to read up on Amazon article regarding this and I could not quite understand as I am not very familiar with cryptography in android/java.
How am I supposed to actually allow access to Amazon SimpleDB from my application while keeping the access key safe from external parties?
Edit 1:
I want to use the application to retrieve data from the SimpleDB, showing in listview. For example like a simple review on food and other users will be able to retrieve the same review that other users posted. Maybe if the user wants to post a review, they would require to sign up an account and log in.
AWS offers a couple of solutions for delivering credentials to the device outside of hard coding them, one or both may meet your specific needs:
Token Vending Machine. AWS offers example TVMs for both Anonymous and User Authentication that can be customized to meet your needs.
Web identity federation which uses identities from Facebook, Google, and Amazon.
Our samples repository includes samples for integrating with both of these technologies, though not specifically in the SimpleDB example.
There is no foolproof way to do this. Whichever way we do, somebody taking your APK can potentially reverse engineer and crack the password (You make it difficult by obfuscating the code, but it is just making difficult and not foolproof).
If your app requires users to login (with some credential from your backend or using openid), then use this to let users access your server. Then on the server code, you can provide the AWS credentials using IAM Roles (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html).
So your web (REST) API access is allowed by using user-provided password and your server code gets the access by IAM roles. This is the most secure way.
If you dont want to have your server / backend, then there is no real foolproof way.
Answer from #Bob above is precise how to achieve this:
https://stackoverflow.com/a/21839911/2959100