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.
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 want to store some keychain information (credentials and one or two details), and ACSimpleKeychain was recommended to me as a simple implementation that would be easy to use.
Furthermore, I would like several apps in a family to be able to use the same credentials: it's a nice-to-have and not a necessity, but I would like to store keychain information securely and have several almost-isomorphic apps aware of the same information.
I see that the .plist file includes com.foo.${PRODUCT_NAME:rfc1034identifier}, and was wondering two things:
First, if I set all apps' bundle identifier to com.foo.common, will this put them on the same page as far as keychain credentials?
Second, is such a replacement, meaning non-unique bundle identifiers, risky territory or bad engineering?
Storing credentials securely is what I most need and I believe that ACSimpleKeychain will do what I want.
The nice-to-have I am looking forward is having all the com.foo.* be able to opt-in (or be automatically assigned) to share credentials so users only have to enter data once.
Any advice would be appreciated.
The bundle identifier is the only item in a bundle that uniquely identifies the application and it's likely that problems may occur if it is not unique.
Also, your applications will not be allowed to go in the App Store without unique bundle identifiers as mentioned here.
It is generally recommended not to store credentials in a repository. The question is, where should they be stored then, so all developers have access to the same configuration?
The question is subjective - different practices may be applied. For me, the approach that worked best is utilisation of some form of "Single Sign-On" where possible and provision of personal logins to every system to developers. This also has an advantage of being able to find out who was responsible for a destructive action (which sometimes happens).
You can also take the approach as described here: store the credentials in the SCM, but in encrypted form. This will allow to maintain versioning, yet not allow access "for everyone". I'd say, best option is to combine these two approaches (and store only developer-environment "service" credentials - encrypted - in the SCM)
I stored the config files in a private S3 bucket and manage access via IAM. The configuration updates and revisions are handled by a small script using the AWS gem. That way anybody with sufficient privileges can access them, and we also can issue access credentials for each developer separately.
Can someone please point me to the right direction.
I need to be able to host my GWT application in a way that it allows multiple clients to use the same application which could be separated by url's but internally using the same application.
the different sites would probably be seperated by different configurations. eg. different database, different log path etc, etc,
any ideas.?
You could use the following way to arrange your projects :
- my.application.core.project : it holds all the business logic and views for the application except for the entry point
-my.application.customerX.project : it holds only the entry point and the property files used for having the connection to the db, probably customerX specific theme
-my.application.customerY.project : it holds only the entry point and the property files used for having the connection to the db, probably customerY specific theme
Such an organization of the projects would allow you to have a common core that is distributed to each of the customers and also the ability to build on top of the core customer-specific impelementations.
The url's per client can be done with URL rewriting. Be it with an apache server in front of your application and/or in combination with a Filter in your web application.
As for the configuration, logging, and/or database per client you want a solution that doesn't store a file per client on the file system next to your application. Preferable you store client specific settings in one database and have an admin interface to manage it. For the client's data you also don't want a separate database per client, because it doesn't scale well, and would be a maintenance mess if you need to upgrade your application and databases to a newer version. Look for a multitenant architecture.
I admit this is a vague answer, but without specific system and software descriptions it's kind of hard to give a concrete answer. Nevertheless I hope this answer does give you some direction.
I have successfully achieved this by setting up separate directories in tomcat for different clients and then creating soft-links to the main application within that folder. when it comes to database connection properties and other configuration properties, instead of pointing them to the main application I just created them separately.