I just created a *.provisionprofile through the Apple developer portal and I am not sure if I can add this to my Git repo. The documentation refers to this at multiple locations, but I am unable to find further information if this file is something that can be shared.
Is this a file that contains private information?
Private, at least to the general public. You'd need to deploy it in your team's CI so your team would be able to see it too, but there's no risk of them getting access to your account with it. There's also the risk of others using it to generate a malicious copy of your app, but actually deploying it to a device requires more workaround. They can't just push it to App Store without breaking into your account, at which point they could just generate a new profile.
Related
If I've deployed a smart contract on NEAR, how do I upgrade it to a new version? How can I tell if an existing smart contract can still be upgraded or has been frozen?
In addition to the answer Erik already provided, I want to mention that even when there is no full-access keys on the account, the contract code can be re-deployed by the contract implementation itself (obviously, it should have a built-in support for that). You may also want to combine that with DAO to make the upgrade process backed by a voting process.
Upgrading is done with access keys. If you want to be upgrading, you keep a full access key to the account, which allows you to deploy or delete/recreate/deploy.
Anyone can view the upgradeability of a contract (eg whether it can still be changed by the original owner) by viewing its keys to make sure that all full access keys have been removed using:
NEAR_ENV=mainnet near keys contract_name.near
If I ask the app development company to host an app on their App store or their Google play store accounts, does this make them the legal owners of the app?
I want to stay the legal owner of the app. Does this affect my ownership rights by any means?
To ensure ownership of the App concept, IP and confidentiality:-
- Sign a IP rights document with the Dev Company.
- Sign a NDA with the Dev Company.
You might need more documents depending upon the laws of your country, so this step is not possible without consulting a lawyer.
Also, you need to ensure that:-
- You get all the source code with proper documentation.
- Also, make sure there are no encrypted files/libraries present in the source code.
Since, 2013 Apps can also be transferred between accounts if you happen to create one later.
================================
On the flip side
Why do you want to get into such a mess?
It is easy and cheap to create a Developer account. Just some straighforward paperwork and not more that 100$ for each platform (compared to the amount of resources you have already invested in creating the App)
Once you have the account, give the Dev company Developer access to your account. They can upload the App to your account with it. Once this is done and you have also ensured the you have all the source code, you have no dependencies on the Dev company.
Is it possible to change ownership of a Heroku add-on? If so, how can we do that? In fact, I want to move an add-on from one Heroku account to another.
Let me elaborate my scenario a bit more to be clear.
I created an add-on with my test provider acount. Is there any way that I can delete the add-on from my test account and create the add-on with the same name with my official provider account? As a matter of fact, there is nothing about deleting the add-on or moving it under a different account in the Provider's documentation.
A Google search lead me to this support page, which says
This currently depends on whether or not the app has any paid resources associated with it.
For an app with no paid resources, you can use "heroku sharing:transfer" from the command line to transfer the app to a new owner.
For an app with paid resources, you have two options.
1) Remove all paid resources, transfer the app like a free app, then have the new owner re-add the paid resources.
2) Both the old and new owners should file a support tickets at http://support.heroku.com authorizing the transfer and with the new owner accepting charges for the app.
Also check out the Transferring apps and Collaborating with Others articles on Heroku's Dev Centre.
Since you're talking about ownership of add-ons as an add-on provider and not just ownership of your heroku app, I would say you should probably contact the heroku add-on support team via email. See this page here for an email address. Hopefully as an add-on provider if you submit a help ticket they'll be able to help you as well.
Our organization has a number of Rails applications (websites) deployed to Heroku. A former devleoper has left the organization, and as good practice we want to change the Heroku API key associated with our account to prevent any modifications to the apps via the Heroku CLI.
I know that the Heroku API Key is used for Heroku CLI access (it gets cached in ~/.heroku/credentials), but not certain what else it is used for. Specifically, do 3rd-party add-ons in the Heroku platform (e.g. New Relic, Hoptoad/Airbrake, Sendgrid, etc) use this, and therefore require reconfiguring if the API Key is changed? Heroku throws up a fairly generic (and non-informative) error message when you click the "regenerate" button to change it.
Because the term "API Key" is so generic, want to be clear that this is the single API Key associated with each Heroku account accessible via "My Account" link. Image (and warning message) below.
Asked Heroku Support. This is what I got back:
"you can safely change your API key at any time, as we don't give it to any add-on providers. That alert is meant to remind you that if you added your API key to any application or service (ie for auto scaling, manually provision workers, etc) it will stop working until you provide it a new key."
I requested that they update the interface/documentation to make this more clear.
Also remove him from being a collaborator on all your projects so he can't push to them via git.
Out of curiousity (i'd never seen reset key in the admin) I tried it. When I then tried to use the CLI against one of my apps I was asked to reauthenticate - but i can't now get back in - doh! The same username/password works via the site. I'll ping support and report back,
UPDATE:
So it appears my problem is entirely due to the Heroku Accounts (https://github.com/ddollar/heroku-accounts) plugin that I'm using which stores a copy of the key in the ~/.heroku/accounts/ file. Support got me to remove the folder and it all works now - just something to be aware of if you reset your API key.
My app is required to upload a csv and convert to Google Sheets. So we are asking this permission "https://www.googleapis.com/auth/drive" from our user. But some of our users complain we are asking too many permissions. Is there any other settings that we can use to avoid asking too much?
Here are the permission list when user authorizes:
Upload, download, update, and delete files in your Google Drive
Create, access, update, and delete native Google documents in your Google Drive
Manage files and documents in your Google Drive (e.g., search, organize, and modify permissions and other metadata, such as title)
What scope or scopes does my app need?
As a general rule, choose the most restrictive scope possible, and avoid requesting scopes that your app does not actually need. Users more readily grant access to limited, clearly described scopes. Conversely, users may hesitate to grant broad access to their files unless they truly trust your app and understand why it needs the information.
The scope https://www.googleapis.com/auth/drive.file strikes this balance in a practical way. Presumably, users only open or create a file with an app that they trust, for reasons they understand.
https://www.googleapis.com/auth/drive.file Per-file access to files created or opened by the app
Requesting full drive scope for an app
Full access to all files in the user's Drive (https://www.googleapis.com/auth/drive) may be necessary for some apps. An app designed to sync files, for instance, needs this level of access to Drive. Apps with special needs related to listing or reorganizing files might need full scope.
Requesting drive-wide read-only scope for an app
Read-only access to all of a user's Drive files (https://www.googleapis.com/auth/drive.readonly) may be useful for certain apps. For instance, a photo browser might need to reorganize image files in a unique presentation order for a slideshow, or a mobile app might have to work around unique display constraints without needing to write anything. For apps that only need to read file metadata for all files in Drive, there's https://www.googleapis.com/auth/drive.metadata.readonly.
Requesting full drive scope during app development
One common and completely valid case for using full scope is iterative development. It may just be easier to avoid authorization-related constraints and use the full scope while testing your app during development. Then before you actually publish your app, you can back off to the file-level scope or whatever scope you really need for production operation.
Conculsion
That text was ripped directly from Google Drive Scopes page which I use as a rule of thumb when developing drive applications. In your case because you need to be able to upload files I would say you should consider testing a little with the https://www.googleapis.com/auth/drive.file scope, I haven't tried this one before but it sounds like it may work in your instance. Unfortunately I think that is your only other option besides full drive access.