If you’ve done any enterprise work with Rails, and your shop is using CAS for authentication, chances are you’ve seen rubycas-client. Chances are you’ve also loved how easy it was to get working. There’s usually only one hitch — you’ve got to change the config based on which environment you’re deploying into.

Here’s the standard advice you get from the RDoc:

# in your config/environment.rb
  :cas_base_url => "https://cas.example.foo/",
  :proxy_retrieval_url => "https://cas-proxy-callback.example.foo/cas_proxy_callback/retrieve_pgt",
  :proxy_callback_url => "https://cas-proxy-callback.example.foo/cas_proxy_callback/receive_pgt",
  :logger => cas_logger

But with a tiny change, you can give your CAS setup all the flexibility and auto-magical environmental savvy of database.yml. Goodbye last minute edits for a production deployment. Check this out:

# in your config/environment.rb
cas_options = YAML::load_file(RAILS_ROOT+'/config/cas.yml')

Now make a simple YAML file, cas.yml:

# config/cas.yml
    :cas_base_url: https://cas.qaexample.tld/cas/
    :validate_url: https://cas.qaexample.tld/cas/validate
    :logout_url: https://cas.qaexample.tld/cas/logout

    :cas_base_url: https://cas.qaexample.tld/cas/
    :validate_url: https://cas.qaexample.tld/cas/validate
    :logout_url: https://cas.qaexample.tld/cas/logout

    :cas_base_url: https://cas.example.tld/cas/
    :validate_url: https://cas.example.tld/cas/validate
    :logout_url: https://cas.example.tld/cas/logout

It’s worth noting that the colons in front of the YAML keys indicate that those keys are Ruby symbols, not strings. All the rubycas-client docs use symbols in their examples, so I’d follow their lead if I were you.

Got an opinion about using CAS with Rails? Leave a comment and let us hear it!

comments powered by Disqus