One minute read

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
CASClient::Frameworks::Rails::Filter.configure(
  :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')
CASClient::Frameworks::Rails::Filter.configure(cas_options[RAILS_ENV])

Now make a simple YAML file, cas.yml:

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


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



production:
    :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