Is it okay to put your Google Maps API Key into your source code and publish it?
Others could take it and misuse it, but I don't want every developer / user to get their own API key and type it in somewhere. If the owner of the key is responsible, should I create a new google account for the project? (The project is a desktop application in Objective-C and a small developer tool.)
What would be the best way to make this convenient?
I don't think it's legal, but even it were, it's technically impossible, because the Google Maps API Key is tied to your domain name. Google will check the referrer of the HTTP request to validate the key.
The key isn't secret anyway: simply viewing the source of a website using Google Maps reveals the API key.
Related
Is is possible to give google service-account's access to whole drive instead of just folders?
I'm unable to switch to a new directory using google docs API in python. It was possible to jump into a folder and then create the document there using google drive APIs but I want to use docs API only and I can't see any way to jump into another folder.
Is is possible to give google service-account's access to whole drive instead of just folders?
If you have a Workspace domain, I'd suggest granting domain-wide authority to the service account in order to impersonate the regular user's My Drive and access everything they can access. See Delegating domain-wide authority to the service account for more details about how to accomplish this.
If this is not an option for you, you should share all top-level items on the Drive, since there's no direct method to share the full My Drive.
It was possible to jump into a folder and then create the document there using google drive APIs but I want to use docs API only and I can't see any way to jump into another folder.
You need to use Drive API to move files between folders. Docs API cannot be used for that.
Sidenote:
Not sure if you're aware of this, but please notice that, if you create a document via Docs API, you can only create a blank document, since all fields apart from title are ignored in this method (see documents.create). If you want to add text, change other properties, etc., you'll have to use documents.batchUpdate.
I'm mentioning this since I don't know whether that was the reason you wanted to create the document via Docs API.
I am working on a project which needs User Authentication. The "Clients" are iOS (Swift) or Android (Kotlin) native applications. The original form of the API (NodeJS) used Facebook and Account Kit for OAuth and Phone authentication respectively. Since Account Kit shutdown, we moved to Firebase Phone Authentication for Phone but left Facebook in its original form. Now, we're wanting to consolidate our Authentication providers (to Firebase) but I can't seem to find a way to "convert" or "import" Facebook users to Firebase-based Facebook users.
So far, I've read through the Documentation, including the category about importing users, but it doesn't seem to indicate an ability to maintain backwards compatibility, while also moving forward to Firebase. What I mean is, it has an ability to set information, but it doesn't indicate that the same information will be used to authenticate that user as the same unique visitor.
What I am looking for is either transitory logic, which will handle this during login, or preferably, a "bulk-insert" type migration. Essentially, I want to have it setup so that the API only needs to keep a single authentication UID, and use only a single third party (even if they then use another subsequent third party) while maintaining user uniqueness (so that it doesn't create a new user for the same Facebook account).
Part of my problem in creating a temporary patch (not necessary if the main question is answered) is that I don't know of a way to differentiate between a Facebook UID and a Firebase UID to fork the logic. Again, this is only relevant if there isn't a solution for migration.
Feel free to request any more details that would be useful.
Update #1
I realized my question was open ended in what I was asking. I've been digging further and can better define my question:
I need a way to bulk insert users into Firebase's Authentication with a provider of Facebook. I know I can import them, via admin.auth().importUsers([...]) and that I can create accounts via admin.auth().createUser({...}) but when I do the former I can't seem to get back the user's UID, and the latter doesn't seem to allow specifying a provider. Am I missing something?
I'm trying to develop a Webapp that would allow users authenticate with their Google Account and store some information and files on their Google Drive.
It would be a static html/js page with no backend.
There is a quickstart example here:
https://developers.google.com/drive/api/v3/quickstart/js
It works fine but I am wondering if exposing my Client ID and API Key to everybody like in this example could not be a security problem. Anyone could use these id and key in their own app.
What do you think?
As per Changes to the Google APIs Terms of Service, you are asked to keep your private keys private.
Asking developers to make reasonable efforts to keep their private
keys private and not embed them in open source projects.
The author of that post was contacted and the exchange was made available on DaImTo's blog. This is a part of the reply:
Yes, you are not making your personal data available to them. You are,
however, allowing them to “impersonate” you in Google’s eyes. If our
abuse systems detect abuse (say, should someone try to DoS one of our
services using your key), you run the risk that they would terminate
your account because of it (and please note — they wouldn’t just cut
access to the key, they would shut down your console account).
I am a C# software guy by day and a SharePoint beginner. I am using a Content Editor Web Part with SharePoint Online and do not know how to securely store secrets. My SharePoint app must communicate with another application and todo so I must use custom credentials. Because I am in the Dev phase, I am able to hard code the creds inside of my Type Script files, but this is not what I want long term.
My ask is if someone can walk me through the proper strategy for storing secrets using SharePoint Online Content Editor Web Parts to be consumed by the TypeScript/JavaScript.
Thanks
Quite honestly, the proper strategy would be to not use JavaScript at all for sensitive API calls. Sensitive API calls should only be made server-side (so that any "secret" keys, passwords, etc. never reach the browser).
The problem with storing a secret value somewhere and accessing it with JavaScript is that JavaScript would have to decode the value somewhere along the way in order to use it. That means a savvy user could view the source code for your page, open their browser JS tools, and execute the same commands to get the value. Not great for security.
On-premise SharePoint actually has a solution for this called the Secure Store Service, but part of why that works is it's designed for use in server-side code. As of yet, Microsoft hasn't released a client-side API for that service in SharePoint Online (probably because using it with JS would be less secure as I mentioned).
The "proper" strategy depends on your goals. You've got at least 2 options:
If you want real security for your secret key/password/whatever, you'd need to develop a SharePoint Online "Hosted Add-In" which lives on another server or a cloud service like Azure. SharePoint provides "app parts" that wrap hosted add-ins with iframes and let you add them to a page, so you could use that to add your app to a SharePoint page and have it display results from an API call (very similar to how a Content Editor Web Part would look).
If you don't need real security and "security by obscurity" is good enough, then I'd recommend storing the secret value in a SharePoint list and doing some "fake" encryption on it like Base64 encoding. Then decode the value in JavaScript after reading it from the list. If you want to add even more obscurity, you can use PowerShell or JavaScript to make the list hidden so users don't see it in their browser, but that also means you'd have to add/edit values through code.
I want to make an option such that I can issue 3rd part developers access to my data and to do so, similar to the following: https://docs.sharedcount.com/, I want to create a system wherein those developers are provided an API key for which the consumption count can be monitored
Came through Waterlock but does not look like it has this feature: http://waterlock.ninja/
Curious, what would be the best approach to implement API keywords for a Sail.js app?
Sails makes this incredibly easy by use of policies. When a user signs up, assign them an API key, and then create a policy that checks the params for a valid API key -- i.e. req.param('APIKey') -- and deny access if one is not found.