Since I couldn’t find an easy method using the built-in tools, I thought I’d learn a few things and write the plugin myself. Creating a Cordova plugin is actually pretty simple, it’s a single class and a single JS file. I went a couple of steps further and made/modified a couple of build scripts to make the process easier. If you’re interested you can find that code in my Cordova Plugin Template Github repo.
The Intent Chooser plugin can also be found on Github. So let’s see a quick example of how this thing integrates into an application.
That simple code will pop up a native dialog, limited to apps with the name ‘twitter’ in them, and send the text ‘This is my content’. Since it calls a new Android Activity, there’s not much else to it. There are no callbacks, just fire and forget. In the near future I’d like to add support for sending binary data types like images as well, but I didn’t need them for my immediate use case.
If you find any issues, or have feature requests just file issues on Github.
]]>I was drawn to Appcelerator because of the idea of being able to write straightforward JS and get native widgets. This would allow me to focus on the logic of my application, and not making sure I hadn’t forgot to track the retain/release counts on my objects correctly. Initially I was able to make tremendous progress in mocking up the UI. Sure I don’t get the great Interface Builder, but with minor tweaks I can deploy to Android! What had taken me weeks to sketch out in Obj-c was taking me hours or days instead. Multi-level navigation heirarchies with back buttons? Easy! But shortly after I reached the end of mocking up my UI flow, I began running into trouble. The documentation for the platform was sparse, but seemed to be improving. If you got really stuck, you could look at the “KitchenSink” sample app to see how various components worked. This isn’t too bad, but progress is slowing…
So the first clear sign of troubl was that I had to use a separate application (Titanium Developer) to build/launch/monitor my applications. There wasn’t (and still isn’t) a visible method to run an app from the command line, or even to just generate code to run from within XCode. Sure, Titanium Developer is a bit slow, a little clumsy, and not terribly stable, but the code is going so much faster it’s bound to be worth it. Surely it is. I was wrong. Titanium Developer rapidly became the bane of my existence. It’s only syntax/static checking is done via JSLint with a pretty arcane set of rules. Want to write one line if statements? That’s a warning. A for loop without checking for property existence? That’s a warning. Appcelerator’s own sample app generates hundreds of JSLint warnings. What use are warnings if they are too verbose to find real problems? Get used to missing a comma, or a semi-colon, and it going unnoticed in the sea of other warnings.
Once I settled into the fact that the Titanium Developer app itself is pretty brutal to work with, I moved onto the next set of troubles. The documentation is terrible. It’s a simple API doc, with almost no supporting code, and nearly useless descriptions for many properties. If you really want to know how a particular API or widget reacts, you have to look at the KitchenSink and hope your use case is covered. If it is covered, then you have to figure out how to work with the spaghetti nature of the sample app, and shoe-horn it into your app. If it’s not, then you’re off to the next giant pain, the community forum.
The idea behind the community forum is great, a place for users to ask and hopefully answer each others questions. Instead what you find are questions that are 6 or 7 months old, unanswered, full of “any update?” responses. The most common official responses are “please provide Titanium and platform SDK versions”, with no follow up. When there are solutions, or work arounds, they may no longer be applicable to the newer versions.
Minor platform versions routinely caused regressions in functionality (like grouped table views scrolling whenever the keyboard is present) while adding more ways for Appcelerator to make a dime (paid Modules), but without fixing persistent, core problems. Don’t get me wrong, they deserve to make some money off of their product, but leaving broken functionality in place for months with no expected resolution dates just doesn’t cut it. Some recent examples of major platform bugs: ‘swipe’ gestures not being handled correctly or consistently including in their own custom horizontal scrolling view, platform specific overrides not working on devices (but working fine in the simulator) on iOS. And more that I’ve probably blocked out for my own sanity.
I managed to suffer through all of this, I’d put too much time and effort into the app to give up yet. I’m too close to the finish line. I’d become used to the undocumented idiosyncracies (like event propogation failing if you add subviews after the parent view has been added, or image views that cannot be scaled in a logical fashion, strange positiong issues if setting both lef/right or top/bottom). It was time for some last minute bug squashing, and pushing the data off to beta testers! Thanks to the fantastic TestFlight we were able to gather a group of testers, and get our permissioning setup to be able to send them an ad-hoc build. Now all I have to do is get a clean, release build ready.
Great, Titanium Developer crashes everytime I try and create a release package. The builds take 5 or 6 minutes, have no stop button, and often hang the Titanium Developer UI. The only way to kill a build that’s already begun is to `killall xcodebuild`, which is certainly not documented. After waiting for the full rebuild (it doesn’t appear to cache ANY compilation steps), I am greeted with a large build log error. Usually about a failure to copy some file. The good news is that at this point Titanium Developer has generated a functional(ish) XCode project. Open it in XCode to find…it hasn’t set my distribution profile at all, it doesn’t seem to be targetting the correct platform, and in fact seems to be defaulting to a debug build. In fact some of the generated code seems to still be set to debug mode, must be a custom script that runs outside of XCode to fix that…
An hour of learning what isn’t set correctly in the generated XCode project and I’m finally building again. Replace a few missing files (default icon, and Default.png don’t seem to copy correctly), fight with provisioning profiles some more, and a build is finally made. Now I load the fresh beta release onto my device, and immediately find a bug that didn’t seem to appear in the simulator, curse loudly, and call it a night.
Middleware platforms are a great idea, in theory. In practice it means working through a vendor who is struggling to keep up with the underlying platforms, stuggling to support their paid customers (speculating here), and completely failing to support their free user base. There is practically no external community for the Appcelerator platform, no solid bare bones starter applications, gotcha lists, or much of anything else. It’s a community of people all fighting to get their project done, and get the hell out of the way. I’m sure they mean well, but things don’t look good.
I’m monumentally disappointed in the current state of the Appcelerator platform, community, and toolset, and have no plans on doing further development on the platform after completing my current project. I’m just going to cut my losses and either go back to direct native development, or forget native development alltogether and get with "PhoneGap"http://phonegap.com/
]]>After playing a bit with the API I decided that I desperately needed a lowbrow application on my iPod Touch, and I needed it immediately. So I gave myself a 48 hour deadline to design and write an iOS app. And unlike all of the OTHER times I’ve set arbitrary deadlines for side projects, I actually completed this one. I’d do a full write-up on the application itself, but it’s pretty unremarkable. It makes an XML based API call using the built in XML parsing, has a single button, and formats HTML content via a web view. It’s quick, simple, and to the point. If you’re interested in my app (and if you’re reading my blog, you should be), you can check it out on iTunes.
The bummer was that I sent the app to the App Store for review on February 25th, and waited until March 3rd for the actual review itself to begin. And now, March 7th, it’s been approved! All told it was just over a week from idea, through development, and to approval. Not bad, not bad at all.
]]>I got a PDA (A Sharp Zaurus, running Linux to be exact) in 2001. By 2003, I was on my third PDA, my cell-phone could act as a bluetooth modem, and it had a camera. Skip forward a few years, and there’s Palm’s, Blackberry’s, and Android devices. In 10 years I’ve gone through a dozen PDAs and cell-phones, each with more features and capabilities than the last. But in 2011, I’m moving backwards, I traded my Android phone in for a $20 nearly-disposable flip phone.
This wasn’t a spur of the moment decision, I’ve been plotting, and thinking, and planning this for months. I started telling folks in December that I would ditch my smartphone in 2011. They almost uniformly had the same response, disbelief. How was I going to go back to not having internet access with me all the time. I wouldn’t have automatic syncing with my google calendar, or contacts. No email, no web sites, no camera, nothing, just phone calls and sms.
That’s the question everyone wants to know. Why on earth would I give up all the benefits of a smartphone? I don’t know. Part of me says this is crazy, stupid, and I’ll be clamoring for a new phone within a month. The other part of me says this is a valid personal study, and might provide worthwhile insight. I’m listening to the latter part, and trying to answer two questions in the process:
I’m hoping that at bare minimum this experience provides me with better knowledge about what features I actually need in a smartphone, so my next purchase can be more about function than form.
I took the plunge right before New Years. I went to Wal-Mart and bought the absolute cheapest T-Mobile compatible phone I could find, it was a $19.99 Samsung flip-phone of some sort. It’s small, light, and absolutely mediocre at all of it’s basic functions. Which makes it pretty prime for this kind of experiment.
I’m now a couple of weeks into my little experiment, and I can tell you that I’m a bit twitchy everytime I open my email. Did i get 5 emails or 500 since I last checked? Did I miss an email from the boss? There is some noticable apprehension when I open my email. But it does seem to be subsiding.
I’ve also become hyper-aware of other people using smartphones. Sitting at a restaurant I noticed an entire table playing with iPhones, and completely ignoring each other. I hope I wasn’t one of those oblivious people when I was using mine, but I probably was.
As to how I’m progressing on answering my two big questions? Well, I can’t say that I’ve really missed having a smart phone with me all the time. If anything, the week-long (yes, I charge this thing once a week) battery life of my phone, means that I’m even less aware that I even have a phone with me.
The second question is probably harder for me to answer directly, but I have noticed some small things. I have no idea what the weather is supposed to be like today, or tomorrow, or a week from now. None. I think I’m actually organizing my email better. Since I’m not skimming a lot of email on my phone, I’m actually doing a better job of sorting and filing email as I see it come in. I need a small camera I can actually stick in a bag and have with me most of the time.
I’ll post another follow up to this later, once this change has really sunk in. In the meantime, wish me luck, I feel like I’m going to need it.
]]>This blog now lives, and is hosted, directly from GitHub. Thanks to their excellent Pages, I don’t have to manage a deploy process at all. I just push into my blog repository and a few minutes later everything is updated. This was an easy process to move to, given that I was already using Jekyll, it was just a matter of renaming my repository, a couple of quick DNS changes and I’m all set.
]]>It turned out to require a BIT more code than I had expected, so I’ve documented my setup, and hopefully some of my reasoning here. I’m probably wrong in some of this, but there’s no easier way to know than to share it with the world.
After making a few requests, I noticed some repeated code which seemed ripe for abstraction. I started my abstraction by create a simple subclass of httpriot’s main class, HRRestModel, named RestRequest. From what I gathered, this is the recommended way of using httpriot to begin with.
What this allows me to do is specify some basic authorization parameters that I want to use for most every request. The other thing I found is that my actual View Controllers didn’t end up needing to use all of the different failure and success cases that the HRResponseDelegate provides. So I went ahead and created my own delegate protocol, RestRequestDelegate. This protocol requires only two methods one for success, and one for failure.
This is the class that shows the real duplication of effort required to use httpriot. Notice that we have to implement five different methods to handle all of the success/failure cases. Using this subclass method, we only have to implement two per request.
Some notes on the actual implementation of the RestRequest: You’ll want to set your own BaseURL. You can do this per request class, or as I do here, in the main base class. At a glance right now, the processResult and processFailure methods may seem superfluous, and as of right now, they are. But their purpose is that they can be overridden in subclasses to be used in any data processing or reorganization. Also note that I go ahead and enable/disable the network activity indicator in this base class. I made the decision that I wanted the indicator to show for all HTTP requests, so I just went ahead and handled it here.
Now on to a sample class that subclasses our new, simpler, RestRequest class. There’s not really much to explain here, so I’ll skip on down to the implementation class.
The fetch method just takes in an object (which is our view controller in this case), and then calls the correct URL. It could also take in any HTTP parameters you need to pass, but for this example I’m not using any.
We then have a simple processResult and processFailure. Again, this is a simple example, so we don’t have any data processing to do, so we just call the delegate method, restRequestSuccess and pass it our result. Simple as can be.
Now here is where we can finally see the real fruits of our labor. All of those subclasses, and delegates, and protocols, for…this. Simple, clean View controller code. Note that we call the fetch method of the GetWhateverRequest class, and pass in self as the acting delegate.
In our success method we take the results, look up a specific value based on a key, and set it into a label. On failure we’d probably want to show an alert or something.
By this point you’re probably thinking that this is a lot of work for a single http request, and you’re right. Where I found this set of abstractions to make sense is when you have a handful of requests, that may be called from several View Controllers, so it make sense to push as much of the setup as possible into the request subclasses. Obviously if your app has a different usage patter, this may not apply. Either way, using this particular set of abstractions my View Controllers are almost entirely free of boiler-plate code and my requests are highly re-usable and portable.
Hopefully this serves as a nice, albeit brief, tutorial into httpriot.
]]>Every app you’ve ever used on an iOS device, uses very little of the default graphical resources. I fully expected things like, custom backgrounds, icons and non-standard buttons. What I hadn’t realized is that the default buttons are hideous, so hideous in fact that they just aren’t used. At all. People have either written their own UIButton subclasses or used lots of custom button background images. It’s still surprising that Apple doesn’t provide more common styles by default. Minor problem, but certainly a big surprise when you first get going.
The network activity spinner in the status bar is not triggered by network activity. Each application must trigger the activity spinner as necessary. Apple’s HIG recommends that you only use it for long network requests. This is a great recommendation, but thanks to the mobile nature of iOS devices, there is no practical way to know how long any request is going to take. This means the only safe thing to do is assume that all network requests are potentially long, and manage the spinner for all your requests. It’s all of one line of code to start, or stop the spinner, so it’s not a major investment, just something to be taken care of.
Coming from a background in web development, I’m very used to the idea that everything is synchronous unless I go to great lengths to make it otherwise. Objective-C and the iOS SDK are built around delegation, which looks and feels a lot like asynchronous operation. It’s really easy to forget with all of the async method calling that you are still sharing a single thread with the UI. Luckily, it’s not incredibly hard problem to solve when necessary thanks to the pervasive use of delegation.
It’s only a few extra lines of code to turn a blocking delegate call, into a non-blocking async operation (look into NSOperation and NSOperationQueue). The more difficult part is handling this sort of thing in the UI. Should I have a modal popup with a spinner? A progress bar? Leave the UI reactive, and just update the UI as necessary? Apple leaves this entirely up to you to handle, which is probably the best, but still leaves some work on your plate.
This one is HUGE. So you want to write an application that allows users to upload photos via the camera, or photo gallery. Excellent, me too! You want to collect some interesting usage statistics, or add an EXIF comment to the image for tracking purposes? Great idea! Too bad you can’t (easily). The only supported method for accessing a user’s photos UIImagePickerController returns a UIImage object that is completely devoid of meta data. Yes, that means all of the nice EXIF data, time, GPS location, flash, shutter settings, all of it are gone. The best you could do is get an EXIF library and insert a few relevant headers yourself. This is NOT a technical problem, as there is code out there that can get the raw file itself, EXIF data and all. The problem is that it uses private APIs and is therefore verboten and will keep you out of the App Store. This has already caused me a ton of heartache and I foresee a lot of extra code and workarounds to get similar functionality as what would already be provided in the EXIF headers. So it goes.
In modern web applications there is an an alphabet soup of acronyms to keep in mind when writing your code, SQL injection, XSS, XSRF, SSL, just to name the common ones. SQL injection attacks tend to make big news , but due to their publicity are also the most commonly secured vulnerabilities. There is tons of documentation on preventing sql injection but significantly less on properly handling XSRF and XSS attacks. While these kinds of vulnerabilities can be seen by an experienced developer looking carefully over the code, there are very few automated tools for the job. Tools like Nikto and Nessus are great at scanning the underlying web server platform (IIS, Apache, etc), and in some cases identify some commonly known exploits. But they aren’t designed to scan a running web application for unique attack vectors.
According to OWASP XSS is defined as
Cross-site Scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.
In otherwords, XSS attacks happen whenever a site displays un-sanitized data directly. This is without a question the most common type of attack on the internet. Any application which takes data from the user is potentially vulnerable to this class of vulnerabilities. Most major sites have suffered from at least a limited XSS vulnerability at some point. While they are extremely common, they aren’t easy to predict, or find. Even finding solid tools for auditing your own applications has been difficult until recently.
The other class of attacks I want to look at are the even less well known, XSRF (sometimes listed as CSRF) vulnerabilities. Again to OWASP for a definition:
CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email/chat), an attacker may force the users of a web application to execute actions of the attacker’s choosing. A successful CSRF exploit can compromise end user data and operation in case of normal user. If the targeted end user is the administrator account, this can compromise the entire web application.
Again, simplified, the idea is to pick a fictional link like: http://yourapp.com/site/delete?confirm=yes, and get a user who you suspect is already logged into yourapp.com as an administrator. Take that link and find a method of getting a user to click this link. There are numerous methods for accomplishing this, which I won’t even begin to cover here. If done correctly this will cause a user to execute an action, with valid credentials, that they are not aware they are performing.
As you can see these types of attacks are not specific to any particular web platform and therefore potentially possible in all web applications. So now that you’ve heard the bad news, it’s time to get to some good news! A new tool has been developed that makes identifying these kinds of vulnerabilities easier. That tool is called skipfish. I’ll let you read the description yourself, but in summary skipfish is a tool capable of doing filename fuzzing attacks, analyzing your application and altering it’s dictionary based on keywords from your site, handling authentication cookies, and filling out and validating form data. That’s cool.
Here’s more good news, skipfish is entirely open source. Here’s the bad news, there are not (yet) pre-compiled binaries or official Windows support. It should be possible to compile skipfish under cygwin on Windows. But for the sake of this article we’re going to assume you have access to some sort of Debian based distro (Ubuntu, Knoppix, Backtrack, etc). Now, let’s get to it!
wget http://skipfish.googlecode.com/files/skipfish-1.32b.tgz
tar zxvf skipfish-1.32b.tgz
sudo apt-get install libidn11-dev
cd skipfish
make
cp dictionaries/default.wl skipfish.wl
./skipfish
That should download skipfish, it’s dependency (libidn) and then compile and run skipfish. Obviously we haven’t asked it to do much yet so you shouldn’t really see a lot of useful output at the end of this. Now it’s time to get to work! I’m using skipfish to test an application I’m currently developing. I recommend you have a local application to test against as it’s significantly (almost an order of magnitude) faster to test locally than against an internet based site. All error reports posted from here on out relate to my application, yours will obviously show different data.
We’ve got skipfish downloaded, installed, we’ve picked the application to test, now it’s time to actually hit it and see what happens! My test application is available at http://localhost, substitute your URL where necessary. For starters let’s just hit the public facing portion of our app. It’s possible to provide skipfish cookie data for an authorized session and have it look at the internal pages of your app, which we’ll look at later.
./skipfish -o output -U -b i http://localhostNow skipfish is off and running. Let’s look at the arguments. -o output tells skipfish to put the results into a directory named output, -U tells it to log any external URL’s and emails found (these might be targets for further auditing). -b i tells it to use a valid MSIE User Agent string when making requests.
Depending on the speed of your test machine, the performance and size of your application, and probably a dozen other factors, it might take a few seconds, or several hours. Watch the dialog for a few minutes, gauge the amount of time you have, and then go get a soda, watch some TV, or whatever it is you do while waiting for things to finish. We’ll move on to the next step once this has finished.
My scan finished, and in record time (about half an hour, there’s a lot of pages!). Now, skipfish has generated us an awesome report on what it’s found, and how it ranks the severity of those findings. To open it, browse to the output directory we specified, and open the index.html file in either Firefox or IE (there is a known issue in WebKit browsers that makes opening heavily scripted local files difficult).
In my case it found nothing severe, but found no shortage of interesting things to look it. Under each category it provides a link to the URL it found the issue on, as well as a “show trace” button that will provide the HTTP request/response for that request. I’m not going to get into an analysis of the results in this article as there are a large variety of potential outputs and they will vary greatly with the application being scanned. I’ll leave it as an exercise for the reader to analyze their individual results.
There is though, a secret and amazingly powerful bit of data provided with each scan’s output. One of the most interesting aspects of skipfish is that it runs in a non-deterministic manner. This means that each unique run of skipfish can lead to a unique set of results. While this is great from an initial testing perspective, it makes it difficult to perform follow-up tests to confirm that issues have been fixed. Now, that secret bit of data? In the top right of each output page is a field labelled Random Seed. You can feed this back into skipfish via the -q parameter to perform the exact same run again.
Now let’s take a look giving it an authenticated session. For starters I’m going to login to my local app in FireFox, and look at the cookies. Your application’s login cookies will most likely look vastly different than my own, but I’ve simulated those from my application below.
./skipfish -o authed -U -b i -C authed=true -C userid=12 -X action=logout -N http://localhost/adminThis time we specify a new output directory and -o authed, two cookies -C authed=true & -C userid=12, these need to be replaced with the cookies from your application. There can be as many of these as necessary. We also specify a path to exclude, -X action=logout, this tells skipfish to ignore any URL that contains action=logout which in this case prevents skipfish from automatically being logged out. Just to be double sure, we also specify -N which tells skipfish to ignore any attempts to delete cookies.
Just like before, once this scan completes we need to open our output directory in FireFox to review the results. Lucky for me there are again no high impact vulnerabilities to worry about, just some warnings and medium issues.
So there we have it, a brief run-through of a few of the stickier web app vulnerabilities, and an overview of a brand new tool to look for them! I haven’t used skipfish extensively yet, but it’s definitely a tool I plan to keep in my belt for application testing from here on out.
]]>For starters I took an existing published setup, and used it as my base instead of a vanilla Jekyll install. The particular setup I used was iruel.net, by Bruno Antunes. You can check out his repo for the list of changes over vanilla Jekyll, but they’re fairly basic. The majority of his enhancements revolve around Rakefile tasks to fit his deployment system. I wanted a different setup, so I ended up removing most of it.
The next step was to remove the files and posts that were already there (ignore the adds for now). After that, it’s time to get to work. I didn’t want to just start from scratch, I wanted to import my existing blog posts first. So I went into the Jekyll repo to look at the converter options. Jekyll currently supports importing from CSV, Mephisto, MT, Textpattern, Typo and WordPress. That’s quite a few options, and certainly should cover a ton of folks, but not me. As previously mentioned though I need to be able to import from Google Blogger, which means I need to get busy. Blogger luckily provides an XML based export file of an entire blog. I just needed to import posts, I ignored all of the stored settings and comments. I spent a couple of hours reading through the export file, and hacking up some really simple code to handle the import.
Currently the code supports importing all blog posts, their published date, permalink (which is stripped to just the path), and the posts tags. All of this is able to be imported cleanly into Jekyll, which is awesome. Next I decided to make a few tweaks to my workflow.
I’m a slow writer. Really slow. I’ve rewritten this post at least twice by the time you read it. If you look into my repo, you’ll probably see that it’s been in a draft status for longer than I’d care to know. Because of that I need to be able to easily manage draft posts. I decided that the easiest way to handle this would be through a few simple Rake tasks. I went on and modified the existing Rakefile, to add two tasks (drafts and publish), and modify the ‘post’ task. First I modified the ‘post’ task to create the post with ‘published’ set to ‘false’ which prevents Jekyll from generating an HTML file for that particular textile file. Next the ‘publish’ task goes in, removes this flag, and changes the file name to be the current date. This way the post’s date is current. The ‘drafts’ task is really simple, it just lists all the posts that are still un-published.
The last, but to me most important, part of my customization is my deployment process. To deploy my blog, I simply have to push into my github repository, nothing more. In github I setup a post-receive hook, that calls a script on my site, that has permission to run a ruby deployment script serverside. That script uses my deployment script dsl, to move the current site to a backup folder (just in case), create a new directory, clone the github repository, and then run jekyll. This seems complicated but with the deployscript dsl, it’s only a few lines of code.
This means in one evening I was able to setup Jekyll, customize it, write an importer for my previous blog, and import it, and deploy it all to my server. Not bad, not bad at all.
]]>Being a geek of epic proportions, I couldn’t just use Wordpress or something similar. No, I needed to find something esoteric, complex, hackerish. And I found exactly what I was looking for in Jekyll. It’s a Ruby based static blog engine with a strong preference for being under version control. This means that the same tools I use to code, are the same ones I use to blog. Kick. Ass.
Coming up next will be a post detailing how I’ve got this setup (hint, checkout my github projects)!
]]>
127.0.0.1 sample.test.dev
Oh, my email icon (on a mac) has a red badge on it, I need to check my email. My voicemail light is blinking, better drop what I’m doing and listen. My cellphone is blinking (or vibrating), I must have a text message, personal email, or voicemail, or just another copy of that email I read less than five minutes ago. Ohh, 10 new stories in my feed reader, I can at least skim them real quick.