How to Add Some Security with a Self-Signed SSL Certificate to Your Rails App Served by Nginx

At Firmhouse, we are working on a new web service and we’re releasing an in-development demo to everyone who is interested. Normally, in demo apps security is less the case and there is always some disclaimer that says you shouldn’t use real production data like passwords and API keys. In my opinion, this sucks because you allways want to use your real-life data to test a demo and see if it’s useful for you specifically. That’s why, the best way to have some security in your demo app is by using a self-signed SSL certificate to secure passwords and other sensitive account information your demo users will be adding.

For our web app, we use Ruby on Rails running on Phusion Passenger, served by Nginx.

This blog post will guide you trough the process of adding a self-signed SSL certificate to your Rails app, running on Phusion Passenger and Nginx by following these steps:

  1. Generating the required SSL key and certificate files for use with nginx.
  2. Recompiling the nginx server through the passenger-install-nginx-module command.
  3. Configuring your web app in nginx to redirect non-secure connections to the secure address of the app with https:// and make sure www. will get redirected on both versions as well.

    I use a few other blog posts in this article, so I would like to thank the authors for providing the information publicly and freely.

    Ok, now let’s start:

    Read more…

    Back from the holidays, handy announcement in a few weeks

    I just got back from the holidays. Ski-ing was great btw. I actually know my parallels know. It was a fun week and I’m going back as soon as I can. But more important, this is wat’s on the schedule the following weeks (and maybe some 2010 resolutions):

    • Get all client projects up and running again and start working.
    • Write and launch a web app that let’s you monitor your cloud computing instances, organize them into projects and get you some financial insight in your costs and profits you get from cloud computing. This is especially handy if you have clients on your cloud servers, so you know what you can invoice them.
    • Get a lot of posts out on shapingclouds.com

    Rational emotions

    I know how you are, world
    I know how you need to be.

    That’s why I can’t get mad at you,
    When you are sometimes so cruel to me.

    I just liked this poem :)

    Use AWS to boot from EBS to start testing your web app

    Last week, Amazon Web Services released a great killer new feature in their virtual computing cloud EC2. You can now launch AWS instances (virtual servers) from an EBS (Elastic Block Storage). An Elastic Block Storage is like a USB hard drive you can plug in and out of your virtual server to expand space or back-up data. Now, you can boot your instances from an EBS which is great for testing your web apps and lowering costs. Here’s why this new feature rocks:

    Previously when you would terminate/shut down your instance, all data would be lost and you would need to boot up a new instance from a default or self-configured AMI (instance images). The default AMI’s are quite great, Amazon and all kind of community people have set up a lot of AMI’s you can use with Windows, Fedora, Ubuntu, you name it. However, when launching an instance from a template, you will have to install your own software (like nginx, Apache or Ruby on Rails) over and over again. You can create your own AMI’s, but the process is technical and quite hard so I actually never had the chance to build my own one. With the new boot-from-EBS feature, in the AWS Console you can now create an AMI on the fly from a currently running instance and save it on an EBS to boot from. This saves you a lot of time on setting up your AMI and updating the software on it. The only downside is that you will pay for all the EBS storage, which is probably bigger than storing an AMI on S3.

    But, this gives us a great opening for easily testing our web applications. You can now just create a bootable EBS with your self-configured AMI on it and run the instance when you would like to test your app or show it to a customer in a real-life server environment, and not locally on your laptop or development server you still have in a dusty corner of your office. Because you can now Stop the instance in stead of Terminating it. All data will be preserved without having to attach other EBSes with all your files and databases and such.

    In the end you will have your testing instance up faster and maintaining the required software on it is a much simpler task, you just create new bootable EBS disks from your instance and launch them. Also, because you can now Stop the instance in stead of terminating, you only pay for storing the EBS image and not running your test server all the time.

    You could provide a great service for your customers that they can push a button on your admin panel and the server with the app could go live when they requested it, without you even knowing they are testing or having to set up the instance of your web app manually. I see great time and cost-saving service opportunities here :)

    How to add SearchManager Quick Search to your Android application

    Quick Search is a great thing on the Android platform. Especially since Android 1.6 will have a global suggestions list for you to add in. This means all apps that have global search enabled will show the search suggestions your app is providing. Quick Search is the little search UI that pops over your Activity when you press the looking glass search-key on your Android device. However, tapping into it with your application for the first time just sucks hard. Follow this blogpost and you’ll have search in your app in no time.

    Implementing basic Android search with SearchManager in your app involves these steps:

    1. Creating a search activity. This activity will display all the results for the keyword provided by the user via de Quick Search bar.
    2. Adding the required elements to your AndroidManifest.xml as well as configuring a searchable.xml meta-data file.
    3. Displaying results in your search activity.

    Creating the search activity

    I use Eclipse to develop my apps, so if you are too, create a ListActivity by creating a new Java Class in your application package. Called it something like MySearchActivity and make sure the Superclass is ListActivity.

    Press Command – Shift – O to load in the required imports and add the following onCreate function:

    	@Override
    	protected void onCreate(Bundle savedInstanceState) {
    		super.onCreate(savedInstanceState);
    
    		final Intent queryIntent = getIntent();
    		final String queryAction = queryIntent.getAction();
    		if (Intent.ACTION_SEARCH.equals(queryAction)) {
    			String searchKeywords = queryIntent.getStringExtra(SearchManager.QUERY);
    		}
    	}

    You’re basically all done here. This onCreate function gets the Intent which your Activity has been called with. It contains the name of the action (ACTION_SEARCH) and the actual search keywords. You can now use the searchKeywords string to actually search your application. For example, get a web search out using a GET request or search your application’s internal sqlite database.

    Adding the required elements to your AndroidManifest.xml

    This part was the most tricky for me. The Android SearchManager documentation just had a jungle of information on it but it’s just too much to handle and hard to distill the actual information from. So save yourself some time and let me tell you what you need to add.

    For the activity that actually displays the search results – the activity we created in the previous step – add the following:

    <activity android:name="MySearchActivity"
                      android:label="Search">
                <intent-filter>
                    <action android:name="android.intent.action.SEARCH" />
                    <category android:name="android.intent.category.DEFAULT" />
                </intent-filter>
                <meta-data android:name="android.app.searchable"
                           android:resource="@xml/searchable" />
            </activity>

    This activity element tells your application that the MySearchActivity is an Activity that can be used to invoke the search. It contains a meta-data element which is a pointer to an xml file that contains meta information for the search UI and behavior, such as labels and wether to include global search suggestions. This is the bit where I went wrong so pay close attention.

    Now, right-click your res/ folder and create a new Android XML file called searchable.xml. Select Searchable from the options of file types. Eclipse should now create the res/xml/searchable.xml file. It will create the xml/ directory if it didn’t exist yet. In this file, add the following:

     <searchable xmlns:android="http://schemas.android.com/apk/res/android"
         android:label="@string/search_label"
         android:hint="@string/search_hint" >
     </searchable>

    The contents of this file configures how the search field is displayed and you can set a lot of options for the behavior. Read about all the options in the SearchManager#SearchabilityMetadata section of the Android Developer documentation. Your own search barĀ won’t work if you don’t use @string resources for the configuration keys in this file. So don’t use static strings because they won’t work and you’ll loose precious hours of development time to debugging, like I did.

    So, add the search_label and search_hint strings to res/values/strings.xml and put in something nice.

    Displaying results in your search activity

    So we have the initial onCreate function with the search keyword, and we’ve configured the search UI to pop up when the user presses the search key. Now it’s time for displaying the actual results. I will not get into technical details here because you can implement this in a lot of ways. Maybe I’ll dedicate the next blog post to this part. For now, do the the following:

    • Based on the searchKeywords string you have, fire up your search in your local sqlite database or do some HTTP requests to fetch a list of search results from.
    • Add them into an ArrayAdapter<MyClass> with nice formatting.
    • Bind the ArrayAdapter<MyClass> with the SearchActivity by calling setListAdapter(myListAdapter) in the onCreate function.
    • You’re ready to go!

    Take a look at ListActivity on the Android Developer site.

    Conclusion

    If you know the right – and actually simple – steps, implementing search in your application is easy. It’s the actual researching of the docs that suck. Please feel free to leave a comment or reply me on Twitter at @michiels.