- Better support for textarea (good to have for scenarios where JavaScript is unavailable). Ace has a special build for it but it isn't compatible with the regular API yet.
- Smaller in size (34k vs. ~185k) and comes with a very handy compression helper.
Much faster and deals with huge documents way better than Ace because it only puts the visible content in the DOM tree. As pointed out by Fabian Jakobs, the author of Ace, in a comment and by Marijn Haverbeke, the author of CodeMirror on Twitter, both CodeMirror and Ace use the same technique and in fact Ace actually pioneered it.- Better documentation compared to Ace.
- Marijn Haverbeke.
Tuesday, May 31, 2011
CodeMirror vs. Ace
Saturday, May 28, 2011
Ask for what you want
I've noticed that in most situations my assumption that what I want won't be feasible (for my employer, family and friends, service providers, business partners) is exaggerated and just plain wrong.
Have the clarity to know what you want and the courage to ask for it and more often than not you will get it.
Have the clarity to know what you want and the courage to ask for it and more often than not you will get it.
Starting up
Starting Jan 1, 2011, I switched to consulting part-time (3 days a week) at my regular gig Directi (which IMO, is one of the best companies to work for in India) to spend some quality time with my then pregnant wife and focus on building products that scratched my own itch.
So far, I've become a dad (it's a girl!), shipped Owe.to, shipped OboxApps, almost shipped Rewritepad and saw bombay evolve in the process.
Along the way I also stumbled upon what looks like an interesting problem to solve, with a sizable market that I'm very excited about.
Overall, its been a great year so far and I'm looking forward to the rest of it.
So far, I've become a dad (it's a girl!), shipped Owe.to, shipped OboxApps, almost shipped Rewritepad and saw bombay evolve in the process.
Along the way I also stumbled upon what looks like an interesting problem to solve, with a sizable market that I'm very excited about.
Overall, its been a great year so far and I'm looking forward to the rest of it.
Sunday, May 01, 2011
Business 101
- Find a pressing problem faced by enough (depending on how much money you want to make) customers* .
- Come up with a solution to the problem and offer it to customers. The price is a part of the solution.
- If enough customers are not willing to pay for your solution, then either the problem was not pressing enough (go to step 1) or faced by enough customers (go to step 1) or you don't have the right solution yet (go to step 2).
- Rinse and repeat till you have enough paying customers.
* Customers are people with a problem that they are willing to pay to solve. Your users are not always your customers. For example, users of a site/product might just be people that your customers can advertise to.
Monday, April 25, 2011
Secure (transient) storage of passwords for external APIs that don't support OAuth
My latest project, OboxApps.com, a mobile app suite for LogicBoxes (LB) and Resellerclub (RClub) users, has to deal with the the awkward situation of storing the users credentials to make API calls on their behalf.
Searching turned up some great answers by ircmaxell on how to deal with situations like this:
For increased security, I wanted the storage to be transient (duration of the session) and did not want to store the password on the server. So this is what I came up with:
Searching turned up some great answers by ircmaxell on how to deal with situations like this:
- PHP 2-way encryption: I need to store passwords that can be retrieved
- Encoding cookies so they cannot be spoofed or read etc
For increased security, I wanted the storage to be transient (duration of the session) and did not want to store the password on the server. So this is what I came up with:
- I ask the user for the API credentials over HTTPS.
- Verify that the creds works by making an API call.
- Generate a 128 character random salt.
- Encrypt the password using the random salt with the method used in the Encryption class from answer 1 above.
- Store the random salt and API username in the session.
- Send the encrypted password to the client in a secure (HTTPS), httponly cookie.
The API credentials and the encrypted password cookie are transmitted over HTTPS to protect against any kind of sniffing and the httponly property of the encrypted password cookie ensures that client side JavaScript cannot access it through XSS attacks (although it is not supported by all browsers).
Additionally (as suggested by ircmaxell in a private conversation), I could also look at implementing the Secure Cookie Protocol (pdf) for the encrypted password cookie and ensure the salt is sufficiently strong by using a derivation function such as KDF3 on the random salt to prevent or at least curb brute force attacks against the key generator, but I think this is good enough for now.
Additionally (as suggested by ircmaxell in a private conversation), I could also look at implementing the Secure Cookie Protocol (pdf) for the encrypted password cookie and ensure the salt is sufficiently strong by using a derivation function such as KDF3 on the random salt to prevent or at least curb brute force attacks against the key generator, but I think this is good enough for now.
Tuesday, March 08, 2011
Owe.to Facebook Application
I created the Owe.to Facebook Application over the weekend to skip the email address verification step (that was required to prevent others from pretending to be you). I can skip it in the Facebook application because Facebook has already verified your email address.
Go to App or check out the Application Profile Page.
You will be asked for the send me email permission when you access the app for the first time. Owe.to requires this permission to access your Facebook verified email address.
Would love to get feedback form you. Please leave a comment below or visit http://oweto.uservoice.com/
Subscribe to:
Posts (Atom)