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,
# 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!