Ruby on Rails Security Guide

Ruby on Rails does a decent job in handling security concerns in the background. You will have to configure your application to avoid few security attacks while plugins would be required for many security concerns which are not at all or poorly managed by rails.

In this article I have described the security issues related to a ruby on rails web application. I have followed DRY by linking to articles with good explanation and solutions to security concerns wherever required. This guide can also be used as a quick security check for your current web application.

Table of Contents

  1. Authentication
  2. Model
    1. SQL Injection
    2. Activerecord Validation
    3. Creating records directly from parameters
  3. Controller
    1. Exposing methods
    2. Authorize parameters
    3. Filter sensitive logs
    4. Cross Site Reference(or Request) Forgery (CSRF)
    5. Minimize session attacks
    6. Stop spam on your website from DNS Blacklist
    7. Caching authenticated pages
  4. View
    1. Cross site scripting(XSS) attack
    2. Anti-spam form protection
    3. Hide mailto links
    4. Use password strength evaluators
  5. Miscellaneous
    1. Transmission of Sensitive information
    2. File upload
    3. Secure your setup / environment
    4. Mysql configuration
    5. Use good passwords
  6. Security plugins directory


Authentication is the foremost requirement of most of the web applications to authenticate and give privileges to their users. Apart from normal authentication mechanism rails have plugins for OpenID, CAS and Access Control. Build your own authentication system only if your requirements are very unique or you do not trust other implementations.

Plugin - Restful Authentication (recommended) - easy to use and you can tweak it according to your requirements. Build your own authentication. You should rarely need to do this ... Restful Authentication is quite flexible. OpenID - a universal authentication system to avoid use of multiple username and password on the Internet. OpenID is getting quite famous now-a-days. Access Control : To easily proivde different priviliges to your users. There are a lot of cool plugins available for access control. Centralized Authentication Server - is used to implement single login/password for your users across multiple application. It can also be used for a single sign-on system. For example, Gmail and Google Reader have a single sign-on between them. Use Google Authentication API to let your users login using their google username and password. More Plugins :

- Model -

SQL Injection

The problem arises when metacharacters are injected into your queries to database. Rails has a very good support to avoid SQL injection if you follow conventions in issuing queries to your database.

Description : Alternate Solution - use hash for specifying conditions in #find

Activerecord Validation

To validate the contents of model object before records are created/modified in the database. Activerecord validations are very useful over database data-type constraints to ensure values entered into the database follow your rules. You might have javascript validations for forms but javascript can easily be switched off. Use javascript validations only for better user experience.

Description : Conditional validation using :on and :if options. Checkout this cool video Be careful using validates_uniqueness_of, it has problems when used with :scope option. Open bug tickets : Use :allow_blank to pass validations if value is nil or empty string Testing Validations - do read the comments in this article Useful Tips
  • Its easy to manage 'nil' values using :allow_nil, its quite handy. For ex: set :allow_nil => true in validates_uniqueness_of to check uniqueness of non-nil values and ignore nil values
  • validates_presence_of is not required if you are using validates_format_of, unless regular expression accepts empty string.

Creating records directly from parameters

While creating database records directly from form params, a malicious user can add extra fields into the params and manually submit the web page which will set values of fields which you do not want user to set.

Description : Alternate Solution - Trim the parameters to keep the required keys and remove the others.

- Controller -

Exposing methods

Use private and protected in controller for methods which should not be actions. Actions are pubic methods and can be invoked from the browser.

hide_action : If non-action controller methods must be public, hide them using hide_action. Be careful of bypassing private and protected using meta-programming

Authorize parameters

Always authorize user request. By tweaking form parameters or url a user can send request to view/modify other users information if there is no proper authorization of parameters.

For example :

## To find information of an order which belongs to a particular user.

#Incorrect :
@order = Order.find(order_id)

#Correct :
@order = @user.orders.find(order_id)
Do not ignore hidden fields - a user can easily modify their value, so suspect them similar to params[:id]

Filter sensitive logs

Prevent logs of sensitive unencrypted data using #filter_parameter_logging in controller. The default behavior is to log request parameters in production as well as development environment, and you would not like logging of password, credit card number, etc.

Video Tutorial

Cross Site Reference(or Request) Forgery (CSRF)

In a CSRF attack, the attacker makes victim click on a link of his choice which would contain a GET/POST request and causes web application to take malicious action. The link could be embedded in a iframe or an img tag. Its recommended to use secret token while communicating with user to avoid this attack.

Its little complex to understand this attack. So, only those readers who are very enthusiastic to know about it, please read the Description below. Rest can directly move ahead to use the plugin.

Description : Use Get and Post appropiately (note : Both get and post are vulnerable to CSRF) Example - Gmail CSRF security flaw Plugin - CSRF Killer (recommended) - it requires edge rails

Minimize session attacks

If an attacker has session-id of your user, he can create HTTP requests to access user account. An attacker can get session-id by direct access to user machine or is able to successfully run malicious scripts at user machine. In this section we will talk about how to avoid or minimize the risk if attacker has user session-id. Following steps are helpful:

  1. Store IP Address, but creates problem if user moves from one network to another.
  2. Create a new session everytime someone logs in.
  3. Expire session on user logout, user is idle for a time period or on closing of browser/tab. For maximum security expire sessions on all the three conditions.

Code for session expiry on timeout

## Timeout after inactivity of one hour.

before_filter :session_expiry

def session_expiry
   reset_session if session[:expiry_time] and session[:expiry_time] <

   session[:expiry_time] = MAX_SESSION_PERIOD.seconds.from_now
   return true
Plugin - Session Expiration for session expiry on timeout Do not put expiry time in the cookie unless your cookie information is properly encrypted. If not, use server side session expiry. Persistent session / login in rails - global setting in enviornment.rb

ActionController::Base.session_options[:session_expires] = <i>say after two years</i>
Persistent session / login in rails - to give your users a feature - remember me

Stop spam on your website from DNS Blacklist

Avoid access to your website from IP addresses which are present in DNS Blacklist(DNSBL).

Plugin - DNSBL check

Caching authenticated pages

Page caching does bypass any security filters in your application. So avoid caching authenticated pages and use action or fragment caching instead.

- View -

Cross site scripting(XSS) attack

Cross Site Scripting is a technique found in web applications which allow code injection by malicious web users into the web pages viewed by other users. An attacker can steal login of your user by stealing his cookie. The most common method of attack is to place javascript code on a website that can receive the session cookie. To avoid the attack, escape HTML meta characters which will avoid execution of malicious Javascript code. Ruby on Rails has inbuilt methods like escape_html() (h()), url_encode(), sanatize(), etc to escape HTML meta characters.

Description Can we avoid tedious use of h() in views? Sanitize() is used to escape script tags and other malicious content other than html tags. Avoid using it ... its unsecure. Use white_list instead. White_list plugin

Anti-spam form protection

Use Captcha or Javascript based form protection techniques to ensure only human can submit forms successfully.

When using Captcha do ensure the following :

  1. Images are rendered on webpage using send_data and are not stored at the server, because its not required to store images and are redundant.
  2. Avoid using algorithm used by standard Catpcha plugins as they can easily be hacked, instead tweak an existing algorithm or write your own.
  3. Use a Captcha which does not store secret code or images in filesystem, as you will have trouble using Captcha with multiple servers.

Tutorial - a nice article on concepts of captcha Plugin - ReCaptcha (recommended) Plugin - BrainBuster - a logic captcha based on simple puzzles, math and word problems. By default, it has limited set of problems and you would have to come up with large set of your own problems. Plugin - Simple Captcha (not recommended) as it breaks all the must have features of a good Captcha implementation. For less critical systems like blogs, a more user-friendly option can be use of CSS based technique or JavaScript based plugin unlike Captcha. Both JavaScript and CSS based techniques can only avoid spam from dumb or general bots. If an hacker specifically targets your site or bot is smart enough, you are dead, so be careful. Captcha with Multiple Servers

Hide mailto links

Mailto links in a webpage can be attacked by e-mail harvesting bots. Use the plugin CipherMail to generate a 1024 bit random key and obfuscate the mailto link.

Plugin - CipherMail

Use password strength evaluators

A lot of people have used password strength evaluators simply because its used by google in their registration form. You can use it to help your users register with strong password. But I don't think its a must have security addon. Uptill now I have not found a good algorithm to assess strength of a password, but some of them are reasonable.

Also, if there is an open source tool or algorithm for evaluating password strength, it can easily be broken. So, you might consider tweaking the algorithm or building one from scratch.


- Miscellaneous -

Transmission of Sensitive information

Use SSL to encrypt sensitive data between transfer from client to server. SSL hits server performace, so you might consider using SSL only for few pages which transfer sensitive data to and fro.

Plugin ssl_requirement Mongrel, rails, apache and SSL Controller in SSL subdomain Sample SSL code in rails

File upload

Be very careful when you allow your users to upload files and make them available for other users to download.

Description Must read - Section 26.7 of Agile web development with rails - 2nd edition In place file upload 3 plugins for file upload reviewed at :

Secure your setup / environment

Proper Mysql configuration

Use good passwords

Security plugins directory

Note : I will keep this security guide updated. Any additions/improvements are welcome.
Tagged as  
Posted on 20 September
85 comment Bookmark   AddThis Social Bookmark Button Updated on 23 February

Leave a response

  1. shallwelinSeptember 21, 2007 @ 09:11 AM

    great article which totally save my time while I am buliding campus on rails and heading for deployment soon….. thanks!


  2. Eivind UggedalSeptember 21, 2007 @ 11:09 AM

    For the security minded I recently modified restful_authentication to use bcrypt instead of sha1 (among some other changes):

  3. terozSeptember 21, 2007 @ 02:01 PM

    Your a star my good chap

  4. Frédéric de VillamilSeptember 21, 2007 @ 02:05 PM

    Great, gonna translate it in .fr

  5. Cameron SingeSeptember 21, 2007 @ 11:44 PM

    Great write up, the more info on security the better.

  6. ngethaSeptember 22, 2007 @ 08:32 AM

    Great article man, thanks a whole lot.

  7. Jeffro2pt0September 22, 2007 @ 09:18 AM

    Just wanted to swing by and thank you for linking to me. Never thought I’d be linked on a site like this :)

  8. Xavier NoriaSeptember 22, 2007 @ 09:28 AM

    SSL Requeriment redirects, which means a login action can in fact travel without encryption. I think Secure Actions ( provides a better solution. I explained a couple of tricks for this plugin here (

  9. Sven FuchsSeptember 22, 2007 @ 08:32 PM

    Talking about captchas to prevent automated form submissions: here’s an Inverse Captcha plugin for Mephisto comments. Relies only on CSS (no JS, no user action) and therefor will only work for not-so-critical things like blog comments etc., but does a really good job for these.

  10. Heiko WebersSeptember 22, 2007 @ 10:04 PM

    Thanks for writing up a short version of my blog articles

  11. joost baaijSeptember 23, 2007 @ 12:02 AM

    Thanks for mentioning my plugin, I appreciate it. I’ve delicious’d this page and I am sure I’ll come back often since I’ve seen great tips already. Thanks!

  12. QuarksSeptember 23, 2007 @ 06:35 AM

    @sven fuchs

    Thanks for the pointer … using CSS to avoid spam is an interesting technique. It should be good enough for less critical systems until dumb bots adapt to it.

    I have updated the guide!

  13. David SidlingerSeptember 23, 2007 @ 01:34 PM

    Aren’t attr_protected and attr_accessible designed to prevent form injection?

    The tip linked in your “Creating records directly from parameters” section advises to remove the unwanted keys from the params hash in the controller. Using the protected/accessible methods in the model definition seems to solve the problem much closer to where it is actually happening.

  14. Raphaël ValyiSeptember 23, 2007 @ 05:15 PM is flagged ‘alpha status’, so does anyone know how stable and secure it is? Anyone using in production?

  15. RichSeptember 23, 2007 @ 07:14 PM

    This is a great checklist. Thanks!

  16. Sven FuchsSeptember 23, 2007 @ 11:02 PM

    Thanks, Quarks! Appreciate that :)

  17. jonSeptember 23, 2007 @ 11:22 PM


    I am using Simple Captcha, as explained a good choice here and at many more places too, in many of my projects and I found it really useful and simplest to implement. Are there specific reasons/flaws that we should not use it ?

  18. QuarksSeptember 24, 2007 @ 03:52 AM


    In one of my projects I used Simple Captcha because everyone said its awesome. I do agree its very simple to use, but I faced following problems using Simple Captcha :

    1. It stores images which is not required, send_file or send_data should have been used instead. Also, unused captcha images are not deleted until a next user request for captcha is made. Moreover, it stores images in {RAILS_ROOT}/public/simple_captcha with directory permission 777.

    2. It stores secret code in {RAILS_ROOT}/tmp/data. Why filesystem? I ran into trouble while moving my development to production having multiple servers. The only option I was left with was to modify code of Simple Captcha to store secret code in db or memcached, which was impossible as the plugin is not properly written.

    3. The images it generates would be simple for any good attacker to break. If Captcha is required in less critical system, better to use user-friendly options like CSS or Javascript based form protection techniques. If your system is critical I would recommend using ReCaptcha.

    4. At any time only image is valid per session. It breaks when user opens the form from multiple tabs. Its a small and rare thing but gives a bad user experience.

    After a lot of trouble with Simple Captcha, I find it much better to spend a little more time in using ReCaptcha.

    The rule is, when you want to secure your site, you use the most powerful option rather than using the most simplest to use.

  19. QuarkSeptember 24, 2007 @ 11:45 AM

    @david sidlinger

    “Removing the unwanted keys from the params hash in the controller” is marked as an alternate solution incase you are more comfortable with this approach. Its quite natural … this was the first solution I thought of.

    Using attr_protected and attr_accessible is the best technique.

    Surprisingly, ur comment was marked as spam by Akismet (comment spam protection tool).

  20. QuarkSeptember 25, 2007 @ 05:18 AM

    @xavier noria :

    The sole benefit of using secure action is “If a link is generated to a secure action (using url_for, link_to, etc) that link will be an https:// link.”, which would avoid redirection to an extent.

    As far as login action is considered, I think its a good practice to make both login_page and login_submit as secure actions. If your login_page is https, then user submitted login information would travel in encrypted format.

    Also, your users would be more confident if the login page is https. I hardly find any good purpose on why ‘secure actions’ plugin was made.

    @raphael :

    acts_as_google_account is not stable and secure. A good opportunity to write a plugin for rails enthusiasts.

  21. AdamSeptember 25, 2007 @ 06:12 AM

    Great guide guys keep up the good work.

  22. Dave SmylieSeptember 25, 2007 @ 09:51 PM

    An excellent article – I’m sure I’m going to get a lot of use out of this. Was a few things I’d not seen/thought of before, particularly the Authorize parameters issue. Thanks for putting this all together =)


  23. Scott StubbsSeptember 27, 2007 @ 05:58 PM

    This is a fantastic article. Thanks for putting it together.

  24. Tim HarperSeptember 28, 2007 @ 08:00 AM

    Great article! This is an excellent primer to rails security.

  25. jonSeptember 29, 2007 @ 06:41 AM


    Your explanation is not justified, even the google’s captcha doesn’t work on two tabs of the browser sharing the session. Moreover your statement that “the plugin is not properly written” just for the reason that you were not able to modify it is not making much sense… the only problem that people are facing is I think the dependency on RMagick as some people finds it hard to install and get working, rest everything seems quite fine.

    Anybody else here can suggest any good reason for moving from SimpleCaptcha to anything else ? probably as this site is suggesting ReCaptcha.

  26. Felipe GiottoOctober 01, 2007 @ 10:58 PM

    This is the best rails security post I’ve ever seen! With your permission, I’ll store in my computer for reference!


    Felipe Giotto

  27. QuarkOctober 02, 2007 @ 04:10 PM


    sure not a problem, but I would recommend to visit this post once in a while as I keep updating this guide.

  28. Xavier NoriaOctober 07, 2007 @ 07:53 PM


    That’s fine, and in that case you generate a secure link to your login page with a regular link_to. The point is that you declare secure actions at the controller level, and the regular idioms for link generation get the protocol right.

    I think that approach is better than having a redirection. Why would we prefer to have an insecure link and declare a redirection when we can have the right link directly and with the same effort?

  29. davidOctober 29, 2007 @ 10:07 PM

    Agreed, this is top of the list in security posts for rails!

    I’d shout you a beer if you had a link.

  30. frank meyerNovember 13, 2007 @ 06:47 PM

    SSL Requeriment redirects, which means a login action can in fact travel without encryption. I think Secure Actions ( provides a better solution. I explained a couple of tricks for this plugin here (

  31. forumNovember 21, 2007 @ 07:22 PM

    Thanks for very interesting article. I really enjoyed reading all of your posts. It?s interesting to read ideas, and observations from someone else?s point of view? makes you think more. So please keep up the great work.

    All the best

  32. John BlackNovember 21, 2007 @ 07:23 PM

    This guide is pretty cool and will save a lot of my time.Thanks : )

  33. StefanNovember 29, 2007 @ 06:45 AM

    Is there a way to counter CSRF by checking where the POST came from? Meaning: is there a way to check the host referrer of the POST/GET to make sure it came from the same domain, and if not, then don’t process the request? That seems like the best logical option, if available.

  34. James BurtDecember 05, 2007 @ 06:41 AM

    This is an excellent security guide – Thanks.

  35. glittleDecember 05, 2007 @ 07:12 PM

    Those of you using attr_accessible and attr_protected to control mass assignment, one note. Things like “find_or_initialize_by_blah” will be subject to that as well, even though “blah” does not intuitively imply “mass” assignment.

    The tricky part is that if attribute “blah” is not in your attr_protected list and at some point you do find_or_initialize_by_blah and no matching object is found (i.e. you hit the “initialize” case), you will happily be handed your new initialized model object, but the “blah” field will silently be set to nil instead of what you expect.

    We ended up writing our own mass-setter model methods instead.

  36. videolarDecember 08, 2007 @ 10:54 PM

    Cool article , thank you so much.

  37. felsefeDecember 12, 2007 @ 06:57 PM

    thanks for article. looks very interesting.

  38. serchanDecember 14, 2007 @ 04:44 PM

    Thanks for the great article!

    I am developing an ROR application where I would like session information to be removed when the browser window is closed (multiple users, same computer). Are there any secure suggestions for doing this?

    Thank you!

  39. QuarkDecember 15, 2007 @ 05:09 AM

    hi @serchan,

    I have explained about deleting session information at :

    Every browsers maintains its own cookies, which means different session for different browsers. So, even when firefox is closed user logged in from IE will not be affected.

  40. ForexDecember 27, 2007 @ 11:12 PM

    This is what i was looking for a long time. a security guide on ruby. we all know the security problem with php and we have to take special care on security in ruby as well. Thank for the hard work

  41. MusikvideosDecember 30, 2007 @ 11:06 PM

    Will there be a possibility to collect the cookies from all the well known browsers and put them together in one folder to use them together. is the cookie sotrage the same in IE and in Firefox?

    Thanks for the nice article as well from my side. helped me much in understanding! Thomas

  42. Mark SomervilleDecember 31, 2007 @ 03:39 PM

    I’ve written a Ruby binding to cracklib, which you may find useful for password strength checking:

  43. Mark SomervilleDecember 31, 2007 @ 03:39 PM

    I’ve written a Ruby binding to cracklib, which you may find useful for password strength checking:

  44. MetekoJanuary 01, 2008 @ 04:59 PM

    Thanks for this guide, i found it very handy and useful. I am going to writing an article on your your on my blog. Great work!

    Regards, Meteko

  45. Film indirJanuary 04, 2008 @ 03:34 PM

    Thanks.. Nice article

  46. bedava oyunlarJanuary 04, 2008 @ 03:35 PM

    Thanks for this good article..

    Best Regards

  47. Xprove DanJanuary 06, 2008 @ 09:54 PM

    Excellent stuff, Nakul!

    Keep it coming! :-)


  48. LiteraturJanuary 10, 2008 @ 04:18 PM

    nice. keep the great work up. thx

  49. AlfredJanuary 22, 2008 @ 01:43 PM

    Hammm… Nice article… Interesting.

  50. MandyJanuary 23, 2008 @ 08:08 AM

    Great tutorial, they are very easy to understand. Thanks!

  51. Simão RioJanuary 29, 2008 @ 10:45 PM

    Brilliant tutorial! I think CSRF protection is now included in rails (version 2.2). Does anyone know something about this?

  52. QuarkJanuary 30, 2008 @ 04:59 AM

    Hi Simao,

    Yes it is a part of rails 2.0 and above.

    Soon I will come up with security updates from rails 1.2 to 2.0.

  53. BILIM ADAMLARIMarch 09, 2008 @ 10:11 AM

    Thanks for the useful article. Best regards…

  54. kevinMarch 10, 2008 @ 11:06 AM

    you expect that the user will be redirected to the main action, preserving all the parameters. But if an attacker adds & to the URL, it will redirect the victim to that host.

  55. gokhanMarch 26, 2008 @ 02:47 AM
    1. To find information of an order which belongs to a particular user.

    Incorrect :

    @order = Order.find(order_id)

    Correct :

    @order = @user.orders.find(order_id)

  56. laptop reviewsMarch 26, 2008 @ 01:49 PM

    i can’t download super simple authentication plugin and generator

  57. QuarkMarch 27, 2008 @ 11:05 AM

    The svn repository seems to be down for now.

  58. OponyMarch 28, 2008 @ 02:28 PM

    I have the same problem. How I can download the plugin and generator? Please help. I must get this.

  59. ilköğretimMarch 29, 2008 @ 12:16 PM

    I can’t download the plugin. Can aynone help me? Thanks in advance. Regards…

  60. simsicak.netMarch 31, 2008 @ 08:28 AM

    I’ve written a Ruby binding to cracklib, which you may find useful for password strength

  61. inQApril 09, 2008 @ 09:24 PM

    Wondering if there are any opinions with regard to a choice between Ruby on Rails versus Cake PHP with regard to security.

  62. bielefeldApril 10, 2008 @ 04:08 AM

    Excellent security guide – I did not know about this security risks in ruby.

  63. NJ-NYApril 12, 2008 @ 05:13 PM

    Good article.

    Thanks Quark for useful comment.

    NJ - NY

  64. clarkApril 16, 2008 @ 11:04 AM

    There are alot of issues that affect the overall security of a web applications. This has been guide has been very helpful. Thanks Quark.

  65. Alex FreaxApril 23, 2008 @ 10:22 AM

    What about server-side code obfuscation (like zend) ? // im nob in ruby

  66. lingerieMay 01, 2008 @ 02:50 PM

    Biggest problem with security is bad passwords, people using the same password, one gets comprmised then they all do.

  67. WebdesignerMay 08, 2008 @ 02:46 PM

    Excellent article, thanks. I made a couple of apps in Ruby on Rails and implemented a range of security features similar to the ones outlined above. Please check out our portfolio to find out more. Cheers!

  68. TEmizlikMay 16, 2008 @ 12:59 AM

    Thanks for this guide, i found it very handy and useful.

  69. lingerieMay 28, 2008 @ 02:35 PM

    Its easy to manage ‘nil’ values using :allow_nil, its quite handy. For ex: set :allow_nil => true in validates_uniqueness_of to check uniqueness of non-nil values and ignore nil values

  70. ArtikelverzeichnisJune 01, 2008 @ 04:54 AM

    This guide is pretty cool and will save a lot of my time.Thanks : ) Thanks for writing up a super article here! Greetings hamann

  71. billJune 01, 2008 @ 08:13 PM

    Brilliat information thank you

  72. LoveJune 01, 2008 @ 08:19 PM

    Yes i also like Ruby on Rails. it has a good potential. so security issue should be added.

    Thanks for providing this info

  73. MagentoJune 02, 2008 @ 01:57 PM

    Hi Guys, this article is a blast and saves us a lot of time for research. Thanks for the great work!

  74. netnetJune 03, 2008 @ 11:49 PM

    Very useful (guide) information thank you

  75. salopeJune 04, 2008 @ 01:32 PM

    This is the best rails security post I’ve ever seen!


  76. cyprus propertyJune 04, 2008 @ 04:25 PM

    Ruby security is an important issue, thanks for the great article

  77. voyance gratuiteJune 04, 2008 @ 04:42 PM

    Security is very important in the work we do0, so thanks for that !

  78. alanaJune 08, 2008 @ 11:32 AM

    Marvelous thank you

  79. etixetJune 28, 2008 @ 01:36 AM

    Ruby security is an important issue, thanks for the great article

  80. clear poresJuly 21, 2008 @ 03:50 AM

    This is one of the best rails security articles I have seen to date. Good Job.

  81. <a href="">tanzanite</a>August 20, 2008 @ 01:58 PM

    I enjoyed the article – found it to be enlightening on many counts as security has become such a huge issue wuth websites these days. Much of what you articulated is not widely known as the many in depth links to further reading you provide are very useful.

  82. TanzaniteAugust 21, 2008 @ 08:23 PM

    Excellent guide. I have often wondered how well ROR stacks up in terms of security.

    You might want to look at removing the spammy comments above.

  83. FTA KeysSeptember 16, 2008 @ 10:23 PM

    A little over my head as far as coding level – but the logistics are notable!

  84. HerbalifeSeptember 22, 2008 @ 07:07 PM

    Very good but to complicated for me :(

  85. Carlos MaldonadoFebruary 08, 2009 @ 09:33 PM


    1. Authentication

    I think you are missing an LDAP reference

    here’s what I found that could be useful for that section

    I hope it’s considered



  86. packagingFebruary 15, 2009 @ 01:20 PM

    great is too complicated for me .I only need one part of. but very thanks.