Automated testing of installation process for Google Marketplace app - google-apps-marketplace

Is there any easy way to repeatedly test the installation process of a Google Marketplace App on a new domain? It seems as though when you try to install an app to a domain to which it's already been installed, parts of the process are short-circuited, even if the app's permissions on that domain have been revoked. Is there any way around this short of registering a throwaway domain for every test? Being able to automate this test would be even better, but even a repeatable manual test would be very useful.

Unfortunately you need to delete the application and install it again each time from what I gather.
You can revoke the auth here: https://www.google.com/a/your-domain-here/IssuedAuthSubTokens

You definitely don't need to register throwaway domains every time.
If you're trying to test your integration, there is "TEST INSTALL FLOW' button right in the Google APIs Console that starts a test flow. Here's a screenshot:
That's especially useful when you want to test your integration before it is published to the Google Apps Marketplace (but it still works once it is published.)
If you actually install it from the Marketplace as a tester or once published, you can go to the app listing and remove the app. Since we've launched I've added and removed my apps that way quite a few times :) Here's a screenshot:
#aleckz suggestion won't actually work since tokens are Admin authorized and not revokable by the domain user.

Related

How do you automatically enable ACM for Heroku review apps?

I'm trying to get review apps up and running on Heroku. In my usecase I have a bunch of custom domains and I have postdeploy and pr-predestroy scripts that correctly setup all of that. However ACM is not getting enabled for the new apps, so none of the URL's gets certs until someone goes and manually enables ACM. Is there a way to have ACM automatically enabled for new review apps? If it matters any we are manually triggering the creation of the review apps.
The best answer I found was to use the platform API to enable ACM from the postdeploy script https://devcenter.heroku.com/articles/platform-api-reference#app-enable-acm

Why won't server certificate persist after a reboot?

I've written a Windows TCP (NOT IIS) server program in VB that provides the backend for an enterprise iPhone app that I have also developed. The system utilizes Apple Push Notifications, and that works fine, unless the server reboots for whatever reason.
Part of the Push Notification system is the inclusion of Apple certificates on the server. I followed the steps shown here to install the necessary certificates, and even though it's for ASP.NET applications, it works for my Windows-based server. Except, as I said, a reboot requires installing the certificates all over again.
I found this page on Server Fault that suggests adding a user to the certificate through the MMC snap-in, but that didn't work either.
Two questions: Following the steps shown on the Server Fault page, do I need to add a specific user? The only users that pop up are SYSTEM (which I tried), Administrators(ComputerName/Administrators) (also tried) and "S-1-1-5-blah, blah" (didn't try). Would there need to be a different user added to make it work?
Q2: If this won't ever work, is there a different way?
Full disclosure: This is the second time I have submitted this question, but the previous one (four months ago) was never responded to. I'm hoping someone who knows will see this.
Thanks for any advice.
AFTERTHOUGHT: The instructions I linked to above say to install the certificates to Personal/Certificates. Maybe this is wrong? This stuff is way over my head, so I don't understand the function of all the different stores.
Found the problem.
The page on Server Fault left out something. I needed to add a user that the system would recognize to the Permissions list. I added my user authentication, selected it, and after that the certificate persisted after a restart.
It is at least working on my development server. I haven't tried it yet on my production server.
Update: Works the same on the production server. Also, instead of using my user authentication, I used the IUSR authentication, meaning that it should work even after my name is removed from the active directory.

How to create a developer account for Google Apps for Work

I am developing an app that uses Directory API to create user accounts within Google Apps for Work. I have been testing this on a Free (legacy) account but now I need to test adding and removing domains, which Free account doesn't support. I don't want to get a paid account just yet and rack up a huge bill by adding and removing accounts in testing. I also don't see a way to get a sandbox/developer account to test this out. How can I accomplish this?

Is it safe to add a user with a "technical" role in iTunes Connect for using test flight to send them a beta build?

I am trying to recruit some beta testers for an app of mine using Test Flight. None of the testers will be in house employees or anything like that- just some folks I know who would like to help test my app (I'm a hobbyist and don't have any employees anyways).
When I went to add somme users in ITC for test flight it made me assign them a role. The only role that made sense to me was "Technical". However, I am worried that assigning somebody I don't know well the technical role will allow them to make changes to my app descriptions, reject or submit binaries, and things like that.
Is that something I need to worry about? Is there a way to assign a user the role of JUST tester without giving them access to my apps via ITC?
Apple's documentation does not seem to explicitly state what users with various roles can do.
No, this isn't really safe, and it's not a good idea to give the 'Technical' role in iTunesConnect to someone you don't fully trust.
The iOS 8 TestFlight system has a way to setup external testers, see the "External testers" section on https://developer.apple.com/app-store/Testflight/
The downside is that your app has to go through the review team each time you make any major changes before it goes to external testers (hence if the tester is really a close part of your team it is still advantageous to add them as an internal tester by giving them the technical role). The reviews don't take as long as a normal App Store review.
Alternatives (that don't involve a review) are Crashlytics Beta Distribution (owned by Twitter) or HockeyApp (owned by Microsoft). There are other services too, or you can host IPAs on your own website (using the mechanism designed for enterprise apps) but generally doing this means you miss out on other features you get when using the more integrated solutions.
Short answer: no. It is not safe to add testers with technical role.
Long answer:
According to iTunes Connect, the user must have Admin or Tech.
After reading the comments, I will complete my answer with this.
There are Internal Testers and External Testers.
External Testers are not available as of yet (see https://developer.apple.com/app-store/Testflight/).
Only Internal Testers are allowed by now (which means, your testers WILL be able to change your apps).
Since you need the user to have minimum rights, you should add the user as Technical (the less risky, but still dangerous).
I see that there is a checkbox in iTC that lets you enable the Internal Tester role:
What permissions will the users have? Theoretically, they will only have access to the beta versions (but that is a guess, since I have not tried it yet). You could create an account for a fake internal tester and check that you can't modify apps with that role.
A technical users will have access to the 'My Apps' section of iTunes Connect. This means that they can change the description of an app in the app store, update prices and even remove an app from sale.
There is no way to have a user with just an 'internal tester' role. That's what external testers are for.
It is possible to grant someone access to test as an internal tester, but not have them be able to log into iTunes Connect.
Create an iTunes Connect User with the "Technical" role with an email address that they can receive. Then have them accept it with a different Apple ID.
As long as they cannot log into iTunes Connect with the email address you added as the "Technical" user, they cannot misbehave.

What affect on our applications will changing the Heroku API Key have?

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.

Resources