How can I add a configuration to my application after build? - electron

I have built an app with Electron and Electron Builder.
My app requires an API key to work, which should be generated when users download my app. My application somehow needs to know this API key in order to recognise the user.
However, I can't put the key statically into my codebase, because it will be generated for every user, which would require me to compile the app for every user with the appropriate API key.
Is there an easy way to create a configuration file in a second step after building my application or how would I solve this problem?

Related

Google OAuth App re-verification on scope addition

We have an Google client App which we are using in production currently and now we need to add a new scope(https://www.googleapis.com/auth/gmail.send) to it which is a sensitive one. For this we need to apply for verification and I am confused with the steps to do it.
The documentation says:
Show that the OAuth Consent Screen correctly displays the App Name.
Show that the URL bar of the OAuth Consent Screen correctly includes your app’s Client ID.
If my App is currently in production how can I add a sensitive scope to it and create a video?
Is there any way to create a video without taking my App off production in this scenario?
I went through this and this but didn't get the proper info for this scenario. But I feel this is very generic case and most of the organisations would have faced this.
If my App is currently in production how can I add a sensitive scope to it and create a video? Is there any way to create a video without taking my App off production in this scenario?
Your going to have to add the new scope to your project on Google cloud console, and then create the video showing your application using the sensitive scope as instructed.
make sure your browser window is sent to english
run your application and show the consent screen where it displays the scopes
and make sure to get a shot of the URL bar where your client id is displayed in the url.
Unfortunately this will probably knock your project out of verification and impact the fact that your application is currently running in production. As far as i know Google does not have any guidelines to existing verified in production applications requesting additional scopes.
If your issue is with development google recommends having a second project that you can use in the testing stage to develop on your application and then move to the new client when you are ready to go to production. This does not however answer how to request additional scopes without breaking your production client.
I am going to contact Google directly for some advice. I will let you know if i hear anything.

Enterprise distribution of iOS app with customer-specific web service url

I have an iOS app that communicates with a web service, this product will be licensed to customers for their employees. Each customer will have to install the web service on their own server and provide an IP/URL for the iOS app to communicate with. Right now, the web service URL is coded in the app. I won't know the customer's web service URL before giving them the compiled app.
I don't know enough about enterprise distribution to know how to do this. Do if I need to compile the app for each new customer with their specific web service URL, then give them the app? Or is there is another way this should be done? I was thinking a plist file or manifest that can be configured with the URL but I'm not sure. How do they update that and get the app to use that? I had a developer make this app for me and they said the URLs shouldn't be in manifest/plist files.
I can't find any information about this on the apple developer site or on this site.
You can just add text field in your app settings or at the start where user can define its server URL like www.abc.com For all your customer rest of your path (webservices/yuorservice or what ever you use)will be same . Then you get this url and save in your user defaults to use it for the future for that user.
Using this approach you only need to compile app one time for all the customers.
App has no knowledge of manifest file
Your developer is right--you should not include any app-configuration information in the manifest file, since the app has no knowledge of the manifest file or web page that it was downloaded from. Here is a link to an answer I gave regarding this topic.
Enterprise deployment rules
Apple only allows enterprise deployment internally within a company. So, distributing an App through your enterprise license to multiple companies is prohibited.
Approach
I can think of one option that might work for you, given that you have a URL that should change for different customers.
This assumes that you will employ a login.
Devices
Your login web service response to the device can include the URL that is configured for that customer. This URL can be one piece of data inside a configuration file in JSON format.
Web Server Admin Page
You can optionally employ an Admin page, also accessible through login, where your customer can set the URL, and any other settings. The advantage of including an admin page for your customers is that they are able to manage the product on their own, without the need for additional product support.

iOS: Upload multiple files using Dropbox

All that I have researched integrating Dropbox iOS SDK requires logging in to authenticate/authenticate a user.
But this is what I want to accomplish
Use only one user account. (Without authorization)
Create a random public folder(in same account) and upload files to that folder.
Get the folder link.
It's basically sending generated files from the app to an account.
How can I possibly do this?
The API was designed with the intention that each user would link their own Dropbox account, in order to interact with their own files. However, it is technically possible to connect to just one account. The SDKs don't offer explicit support for it and we don't recommend doing so, for various technical and security reasons.
For example, any user who extracts the access token from your app will be able to read every file in the Dropbox account, delete everything, replace it, etc.
However if you did want to go this route, instead of kicking off the authorization flow, you would manually use an existing access token for your app. (Just be careful not to revoke it, e.g. via https://www.dropbox.com/account/applications.)

Can't make "Identity" sample app work with my own client_id

I'm trying to understand how to wrap up the process of developing a package app that has access to users google drive data.
I started examining the "gdocs" sample but soon reverted to the "identity" because I just can't manage to make authorization mechanism work with my own client_id.
I'm currently using chrome canary and I can load the unpacked extension to chrome and make it work. (both identity and gdocs samples)
I am trying to change the client_id in the manifest to my own client_id but I just can't figure out how to make it work. I always get a "bad client id" response.
I could authorize web apps using "gapi.client.setApiKey(apiKey)" but not these packaged apps sample using "chrome.identity.getAuthToken"
I tried all possible combinations but the correct one it seems.
What is the correct way to authorize a packaged app while in development stage?
Do I need to upload it to Chrome Developer Dashboard first?
Can someone help?
Thanks.
Following the updated documentation for Identity API you will need to upload your application to the Developer Dashboard, in order to obtain the application key, and then copy it to manifest.json. That is how you ensure your extension ID is fixed.
Next in Google API Console you will select Installed application and Chrome application, specifying your extension ID (that is your application ID). That will generate a proper client ID that will be matching your application.
Please follow the first link for details.

How to secure iOS enterprise distribution using oauth on a public facing website?

We have an enterprise distribution of an app that we would like to distribute only within our organisation.
We've built the ipa file and the plist which points to the right places, and created the html page with the url: itms-services://?action=download&url={link to our plist}.
Our problem however is securing the distribution process. We want our employees with company owned iPads to be able to download the app while on the move (they're highly mobile). So we want to place the plist and the app on a public website which requires login via an oauth service.
Our problem is that if we require authentication on the URLs for the app and the plist, the itms-services:// url no longer works. What happens is that the user clicks the itms-services link, and we see an un-authenticated request for the plist (which is redirected to login) followed by a "Cannot connect to {hostname}" on the device.
At the moment, the only way I can see this working is if the ipa and the plist files are not checked for authentication. This means (I believe) that someone guessing our URLs to our plist file could create their own itms-services link and download the app without authorisation and effectively cause us to violate our agreement with Apple to only distribute to our employees.
My question therefore is - how can I create an itms-services link that does not expose the ipa and plist files to the public? If it's relevant, the website is built using nodejs and the app is a PhoneGap app.
I've figured out a solution to this.
We can't use the oauth authentication because the iOS install process doesn't present the opportunity to enter credentials.
Instead, when the user requests the page which we display the itms-services:// link on, we create a unique string to that user and encrypt it using AES-256, then store it in the database.
Our URL then becomes: itms-services://{url to plist}/{encryptedString}. We tried using a query string, but it appears the iOS install tool doesn't pass that on.
When the install tool requests the Plist, we verify the encrypted string against the database, open the plist and rewrite the url to the ipa file to {url to ipa}/{encryptedString}.
This seems to work quite well. The only issue I can think of at the moment is that the URL could be shared publicly be a legitimate user with someone who shouldn't have access. I think we could get around this by ensuring the url is time sensitive (e.g. only available for 5 minutes).
Finally, any requests to the plist or the ipa without a correct encrypted string get rejected.
I hope that's useful for someone!

Resources