I have an xctestplan in a library that I'm building that contains all the tests for the library. The tests need to access sensitive data. I would like to store this data in the environment variables for a scheme, but the tests don't seem to have access to these variables when I run them using a test plan. They only have access to the environment variables defined in the configuration for the test plan.
Is it possible for an xctestplan to inherit/access the environment variables from a scheme?
The reason I want to do this is because this library is publicly available on github. I want the xctestplan file to be tracked by git so that users can run the unit tests themselves if they want to. This file is stored in JSON format. If I add environment variables to the test plan, then they show up in this file. Therefore, I cannot store any sensitive information in this file. The temporary solution I have implemented is a separate, untracked, copy of the test plan that contains the sensitive data in the environment variables. This is not ideal because I need to keep these copies in sync with each other.
Storing the environment variables in a scheme is a better solution because I don't need to change it whenever I make changes to the test plan. It's also simpler to exclude schemes from git by unchecking the shared option.
I am creating a Spotify web API library. The sensitive information is the client id and client secret that Spotify uses for authentication requests.
With all of that said, if their is a better method of injecting sensitive data at runtime, I'm all ears.
Related
my question starts from this article here. I followed it along, but this passage:
Security Considerations
Since these files will potentially contain secure information, such as
API_KEY, I’d recommend not checking them into version control and
instead using a secure file storage system like 1Password to contain
copies of Development.xcconfig, Staging.xcconfig and
Production.xcconfig.
makes me wonder what writer is talking about. Configs file are needed be in the app to work, I don't think I could put them aside. if someone could help I need to understand
how to handle those files in safety
how should use this config files, should I put them different (id present) endpoint based on environment? could I put there different things such images names, default values for variables etch?
I also wonder how this could be handled, putting them in some 1Password storage.
If you feel unsafe by checking in those files (why would you? Anyone who accesses the source code needs to somehow access some API using some key), you could
Handle this by .gitignore
Create a softlink from your repositiory to some outside "safe" area in your file system, protected by file system access rights
Handle those secrets by means of the keychain / secure enclave, see here
Anyhow, the biggest / only security risk I see is if you plan to publish your repository and dont't want your secrets to go public. In that case, you would replace those API keys by some text like "[enter your api key here]", which could easily be done by some awk/sed scripting.
For our Web api project we use the following url versioning system:
https://{fqdn}/{apiVersion}/{apiResourceName}/{resourcePath}?{parameters}
for instance we can have something like the following:
https://myapi.mysite.com/v1/customer/2
Now considering above, let say you want to release two versions (live,test) to the customer. One live version (working with live data) and the other one is the test (working with test data for customer development test).
For live one I could easily use the one I mentioned : https://myapi.mysite.com/v1/customer/2 .
How do you name the test version of the above api? what is the test version of a api url version v1? Can specify the test api url?
Also what are best practices for fully qualified domain name of the API {fqdn} when using url versioning?
There are really several ways to do this.
One way, for instance, is to simply use attribute routing to give it a different path. Create a separate method, give it a path of /vtest/customer/2 for example and if users access this /vtest/ version (or v2 or 3 or whatever) then return the test data/new version. See an example in this question
Another way is to host your "test data" API in a different application in your server and have your web.config point to test versions of your database/source data. Using IIS, you'd configure two different applications (one for test, other for live) and the base URL would differ e.g.: https://myapi.mysite.com/appname1/v1/customer/2 vs https://myapi.mysite.com/appname2/v1/customer/2 and your appname could be something like live vs test. Have a look at this simple example
You could also just host them in different servers altogether, which would result in your {fqdn} changing between test and live versions (e.g. server.com/v1/customer/2 vs testserver.com/v1/customer/2) - this is what I do at my current job, and I find it very effective as it isolates live/test data (and API versions) avoiding confusion between them.
I also found this blog post detailing how to do this with namespaces
In other words there isn't just one best/correct way to do what you want, it all boils down to how you (or your company/boss/team) wants to structure and control test vs live data in your APIs. Take a look at these options to see which one is best in your case, hope I was able to help.
I think the title of your question is misleading. The problem you are trying to solve is not versioning (because your client is connecting to the same version of your application: v1). It is about having multiple environments: one for live data and one (or more) for test data.
At my company we solve this issue through the host name. At https://live.mysite.com/api/v1 we host v1 of the API connected to live data. At https://nodex.mysite.com/api/v1 we host v1 of the API connected to test data. Our clients can request new nodes as necessary (e.g. client1-devnode.mysite.com/api/v1 to develop against, and client1-testnode.mysite.com/api/v1 to test against. Each node get it's own set of test data.
Most of the live projects different server for different environments.
Instead of using different version of API endpoints, You should use different servers for different environment like this :
For Prod/live : https://myapi.mysite.com/v1/customer/2
For Test : https://myapi.mysitetest.com/v1/customer/2
For Dev : https://myapi.mysitedev.com/v1/customer/2
You need to configure environment specific properties for different backend endpoints you are hitting. Like : test.properties/dev.properties/live.properties
With my experience in API developing i found that there are 2 way of making server (test/developer)/live
I will show an example with your link type
https://{fqdn}/{apiVersion}/{apiResourceName}/{resourcePath}?{parameters}
In your case you can use or settings based and Link based testing type
What is settings based?
Settings based is that your server for example https://rest.mysite.com/v1/customer/2
will acting as test if you or your customer will set in he's settings server status to test and if as live - status to live.
This method is good in some cases but in order to test and to have live in same time,- this type not recommended.
What is link|URL|URI based?
This method have 2 types of identifying request is test or live
One way is to set test as a parameter https://api.mysite.com/test/v1/customer/2 and without test it goes to live
Second way is to set api to testApi or apiTest for example https://testapi.mysite.com/v1/customer/2 or https://apitest.mysite.com/v1/customer/2 . This way customer have both test and live and he can do testing and having live project too.
And don`t forget for security always check customer and verify before giving live api access.
As an option you may use custom defined header. If request contains custom header -> redirect request to test version of API.
I am working on an open source project that needs to authorize to a service using oAuth 1.0a. To do this the client app needs to obtain a "key" and a "secret" that is used as part of the authorization handshake.
Question: Is it safe to check these tokens into my SCM? If not, how should I handle this?
Update: The keys I'm referring to here are application specific and the service they are for is copy
It really depends on how secret the keys are.
If they're tied to a user account like for AWS, then I would say to absolutely not include them in the SCM. In that case, the app should check the environment variables to load a key file from the user's directory.
If they're more designed to be per app, then it would reasonable to include the key in the source tree.
Now, if you're developing a library. It would reasonable to include your key in the source tree under the tests but not to include it the binary distributions.
One thing I will suggest, is that you put the key under different copyright terms than the rest of the library. That way, if someone forks your code, you can force them to get their own key.
I have severals configuration settings that I need to be able to access throughout my application. These settings can't and won't be editable by the user. I'm coming from a web application background and I don't know what approach is recommended.
If my application was for the web, I would create a file config file config.py or config.php then set everything I need to set then load it where I need it. For iOS, I came across NSUserDefaults where it is use mainly for user preferences (at least that what I see people using it for). However the data I wish to store are not preferences at all.
Should I create a class and store my values in it or use NSUserDefaults ?
It is perfectly fine to use NSUserDefaults to store application configuration information that is not a user-visible configuration option. That said, my recommendation would be to create a class on top of NSUserDefault so that 1.) it is easier to change the underlying implementation if necessary and 2.) you have the strings representing the variable names only in one place (to avoid accidental spelling differences) and you can refer to individual variables by specific getter functions.
I've just inherited a CF app from a customer who uses a shared CF hosting provider. I'd like to introduce better processes including the ability to stage app changes that I make for their review. (In the past, they would upload changes and cross their fingers.)
Their app lives in a folder under the webroot. Let's call it "/app". I'd like to create a sibling directory named "/appstaging" where I would publish the latest code. The obstacle is that the hosting provider lets you set paths for custom tags and mappings but not per CF app. The existing settings all point into the /app directory so if I need to make changes to tags, CFCs, etc., I can't test these without affecting the live app. What I want is CF to let me set per-app tag paths and mappings. From what I've read, CF8 lets me do this but the customer is using CF7 (I'm pushing for them to upgrade asap). In the meantime, is there anyway to workaround this or does a smooth way of staging changes have to wait?
(I am currently experimenting with ways to detect which app I am based on using GetCurrentTemplatePath() in application.cfm. The idea is that any code that refers to other files using mappings would use a different mapping. I haven't done enough work there though to know if this will all work out.)
Any ideas or input are welcome. I should point out that the app and its dev env is not very "modern." There are no frameworks involved and no things like ant used for build/deployment. The customer's budget is extremely limited so I'm not looking to convert the app whole-sale but I do need to find cheap ways to get some process in there to keep things sane.
This is a serious, but wacky, suggestion: use a second hosted account.
Write up a cost-benefit analysis of having live and staging servers, and compare that to the cost of a second hosted account. The second account doesn't need massive data allowances, etc, and ought not cost as much as the live account.
Additionally, calcuate the cost of revising the code base to allow live and staging on the one account and compare that to the cost of a second hosting account.
Remember that you wont need the second account once your real upgrade is complete.
I expect you'll need to do something like defining the custom tag paths in a config file that gets loaded into the application scope. But that'll require some serious code refitting.