Make cookies more secure in Ruby On Rails
This subject is really not very often highlighted in rails security docs, even in the official guide.
We’re often happy with the basic cookie store options :
Anyway, secure websites (like e-commerce sites) must include some more secure options. Cookies have two attributes people usually don’t use :
- Secure : “A server can specify thesecure flag while setting a cookie; the browser will then send it only over a secure channel, such as an SSL connection.”
- Expires : “Cookies expire, and are therefore not sent by the browser to the server, under any of these conditions: […] An expiration date has been specified, and has passed.”
(Definition taken from Wikipedia)
The last means the session AND the cookie will expire after the given date. It’s generally a good idea to set this option, unless you’re running facebook.com, people won’t spend more than 1 hour on you site per day.
To enable these 2 options, you can use the configuration in config/environment.rb :
You should set the secure option per environment, otherwise your dev environment will fail. To do so, you can add a line in each secure environment :
So you’re trying to write that awesome new feature you’ve been chomping at the bit for, right? Your gonna get it done and it’s gonna have so many bells and whistles! Let’s say you give yourself two weeks to get it done, but at the end of one week you realize you just can’t finish it in one more…
Nous sommes heureux et fiers d’accueillir dans nos rangs Olivier Gonzalez. Olivier a une formation d’ingénieur en génie informatique à l’UTC (Université de Compiègne), et une curiosité et une ténacité qui lui permettent de travailler sur tous nos projets. Il a notamment passé ces derniers mois à travailler sur le site http://woopets.com.
Au passage, nous sommes toujours à la recherche d’un designer / intégrateur web pour renforcer notre équipe.
[FR] Tech-Angels recherche un designer web
Tech-Angels recherche un(e) designer web avec ou sans expérience, mais avec beaucoup de curiosité et d’autonomie. Vous êtes un expert en (x)html, css, javascript (en particulier jQuery), et souhaitez collaborer sur des prototypes de projets innovants ? Rejoignez notre équipe d’ingénieurs.
Le poste est à pourvoir dès aujourd’hui sur Chantilly, au nord de Paris, avec possibilité de travail à distance. Rémunération fonction de votre expérience.
Envoyez votre canditature à philippe|@|tech-angels.biz
“Du développement aux ventes dans l’AppStore, on vous dit tout”
Un retour d’expérience complet et argumenté, à lire absolument.
Don’t complicate your billing
Recently we have been working on adding billing support to tweet hopper, and we had all types of debates on how to handle each little nuisance. After much discussion and research, I have found the right answer: don’t make it complicated!
There is a saying, “no code is faster than no code”. Very smart coding proverb, which can be easily restated as “no functionality is less buggy than no functionality”. What I am trying to say is, adding complex billing functions just adds unneeded complexity to an already tough problem.
Once a month or 30 days?
This decision doesn’t have deep ramifications, but it is an important question to decide on. Do you bill every 30 days or the same day every month? Services like github charge on the same day every month, or be more like 37signals and charge every 30 days. The biggest difference is that going every 30 days means you get an extra payment every 10 years… Yes, 10 years, shrug.
There is also one other issue to consider if you charge on the same day every month, heard of February? What if someone signs up on the 31st? You have to start accounting for month end dates and make sure you get a monthly charge in on shorter and longer months, leading to more code complexity.
To prorate or not to prorate
Wait? Someone wants to upgrade in the middle of the month! There are two different schools of thoughts; prorate or just bill the higher amount on the next billing date. Linode, our hosting provider, charges on the 1st of every month and then charges prorated amounts if you need to upgrade or add services. On the other hand, github and 37signals both wait and charge you the upgraded amount on your next billing date, but you get immediate access to upgraded plans.
The prorating method has another down side that can lead to extra code complexity if you aren’t careful. What happens if you charge a customer $30 a month and they signup on November 29th? If you prorate and charge them, you will charge them $1, which will be almost nothing after credit card processing fees - depending on who you use to process transactions. Linode handles this by charging prorated amounts plus the next month if it is after the 20th, but that adds to complexity.
For tweet hopper, we decided to avoid complication and skip prorating and just go with the higher billing amount on the next billing date. Why write code that has to do complicated math? The side benefit of it all? Credit card billing can be completely separated from the app and run via cron scripts, there is no need to do on the spot prorate charging.
Refunds? We don’t need no stinkin’ refunds!
This one is pretty straight forward for me, don’t offer refunds. Don’t write any code in your app to push refunds - your gateway should have the tools you need for the few instances that you need it. It is the customer’s responsibility to cancel their account, and if they don’t it in time it isn’t your fault.
This is a clear cut “no code” win!
Freemium vs Trials
Free and paid plans versus 30 day trials with paid plans, it is less of a clear cut choice. The choice really depends on your product and the resources each plan uses.
With tweet hopper we have a lot of expense that goes into even just one twitter account. Due to that expense we decided to offer a free 30 day trial instead of a completely free account. We collect the credit card up front, mark the 30 day billing date, and charge your card once that date hits unless you cancel. By offering only paid plans, the plan changing and card collecting is pretty straight forward.
37signals offers both options in their products, either free plans or paid plans, taking credit cards up front. When you upgrade from a free plan to a paid plan, they have a bit of extra logic they need to handle to setup billing dates and get the charging going.
Keep it simple…
In the end, do whatever feels right when you are collecting payments. Keep it secure and keep it simple. The most important thing to understand is that no code is less complex than no code!
About software and standards
Lately, BinaryLogic has posted a note (a great post!) explaining why he’s discontinuing his plugin Resourcelogic. One of the most interesting reason is :
“Deviating from standards makes it harder to work with other programmers”
We can’t agree more with this.
While it’s often tempting to use bleeding edge libraries or create your own library, remember that your code must be kept readable and maintainable.
All software providers must understand this : the more your software is standard, the more developers will adopt it. Developers also have to build their professional project, and including a very specific technology on their resume costs a lot of time / money. If this very specific technology is discontinued, their skills will worth nothing.
TIP-1 : Make sure the developers (your customers ?) will want to use your products, and not only for fun.
Don’t build “Concorde” products, build useful and perennial products instead. While your project might be awesome on a technical point of view, if nobody wants it, it’s worth nothing.
Another good example is this note about spreading your apps :
“If they are familiar with your software and it will solve a problem for their clients, you might get a recommendation — maybe even a big one.”
TIP-2 : Make sure early adopters get the product for free.
They are likely to blog about it, or spread the word in their company.
