Provides a single sign-on solution for web applications, implementing the server-end of JA-SIG's CAS protocol. Forked from the gunark branch in roder to provide read only filesystem compatibility.
Ruby Shell
Switch branches/tags
Nothing to show
Pull request Compare This branch is 4 commits ahead, 10 commits behind boontdustie:master.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.



This is the Read Only Ruby CAS Server gem (not Rails on Ruby or anything silly like that — in fact, this application is a Sinatra app).

This gem picks up from the RubyCAS-Server gem in order to make that system more flexible, particularly with respect to setting up on read-only filesystems (particularly Heroku).

Towards this end, this gem has made itself more modular. It is no longer required to be in the actual directory of the sinatra application, as it used to be with earlier versions. Instead, it can be included as a gem in the Gemfile (just like any other gem for a Rails app (for example)).

For info the older non-read-only system (much of which is still pertinent) please see


Getting started

  • Because of the decoupling introduced by this gem, You will need to create the application structure yourself, since this gem has lost a lot of the files that used to make it work.
    • In the future it would be nice for this gem to havea generator which stamps out a default application structure which can be modified to fit one’s needs.
    • Before the above happens, it’s likely that I will upload an example app whcih you can customize
    • In the mean time, you can start with one of the default application structures from the original gem (see link above) and make the modifications that follow

Development environment

You have to require the development requirements of the rubycas gem while you are developing the application which uses it. I’m hoping someone can share with me a slick bundler shortcut for doing this sort of thing (requiring not just a gem’s dependencies, but also a gem’s development dependencies (and only while in development mode on the application)), but in the mean time, you can include the following in your Gemfile.

gem "rubycas-server", :git => "", :ref => "6d7b8d2"
# gem "rubycas-server", :path => "/path/to/rubycas-server" # If you want to work off of a local version
gem "thin", "1.2.10"
group :development, :test do
	# These are all development dependencies for the rubycas-server gem 
	gem "rack-test"
  gem "capybara"
  gem "rspec"
  gem "rspec-core"
  gem "sqlite3", "~> 1.3.1"
  # for authenticator specs
  gem "net-ldap", "~> 0.1.1"

Hopefully I will either soon have rubycas-server set up as a gem on gemcutter or this project will get folded into the main project. In the mean time, you can point to the github repo as shown above.

Environment variables

You must add the following configuration variables in your directory

ENV['CONFIG_FILE'] = "#{File.dirname(__FILE__)}/config/config.yml" #or wherever you want this to go to
ENV["APP_ROOT"] = File.dirname(__FILE__)

This is so that the configurations work on a system that may not have root access (and lets config live in app directory, required for systems like heroku).

It also lets the gem point to the app direcotry root for db/migrations to run when the server is started. (At the moment, we still need to get the manual migrations working properly)

Actually, the datbase migrations loading isn’t working yet with the above ENV configuration lines. I think the path needs to be exapnded for the gem to be able to work with it. For now, you can load a console (at least in heroku) and then run ActiveRecord::Migrator.migrate( "./db/migrate"). This worked for me. Sorry about this. Still a WIP…

Configuration files

Wherever you decide to put your config.yml, you need to change the nesting a bit from how things work in the old version. Everything is now nested within environment keys. You can set something like this

all: &all
  server: thin
  port: 4000
  ssl_cert: /path/to/your/ssl.pem
  theme: simple
  # Make sure to put this in with no file setting -- this should turn off file logging
    level: DEBUG
    class: CASServer::Authenticators::SQL
    database: inherit
    user_table: users
    username_column: email
    password_column: password
  <<: *all
  <<: *all
    adapter: sqlite3
    database: /home/cts/code/dem_cas_server/db/development.sqlite3

Inheriting from the all settings (or whatever you want to call them (default?)) will make it easier to stay DRY.

Notice that the value of options[:authenticator][:database] has been set to inherit here. This lets the application know that the database which is storing CAS specific stuff is alsa the database where the user data is going to be stored. This is helpful with heroku since it lets you just set the user database to the same database as that which comes with the heroku account without having to muck around a bunch. If you need to specify this manually, just use the same syntax as for specifying the database in general.

On that note, Heroku gives you a config/database.yml file with all of the database configurations you need to run your app. So, this gem has been set up to check to se if that file exists, and if it does, it overwrites whatever was in the config.yml file. IF you want to specify database setting in that file for local development, you can use this nesting structure

  adapter: sqlite3
  database: /home/cts/code/dem_cas_server/db/development.sqlite3
  adapter: sqlite3
  database: /home/cts/code/dem_cas_server/db/test.sqlite3

Removing stuff in the way

If you copy things over from an old style server app direcotry, you will have to remove the lib directory so that all of the rubycas-server code will be loaded from the new gem and not from the outdated code.

Other stuff?…

I very well may have missed stuff. If anything doesn’t work the way it seems it should, let me know and I’ll try to help you debug.

TODO (Development)

I would love to see this version of the gem gain greater adoption and development from others, and perhaps even be folded back into the original project. There is certianly some work to do still in this direction.

  • Get specs working again
    • These are going to have to be rewritten a bit due to the way that I’ve changed things around. In particular, I changed the default_config.yml file a bunch so that it would work for my options hash specs. Probably should copy that config file into some new config file and restore the old config files to how they were before, only using the new nesting structure.
    • (Note however that there are specs for the options loading, which is the bulk of what I changed)
    • Going to be some legwork involved in getting the tests set to run in such a fashion that the gem is not required live in the same place as the application. Don’t have time for this just yet, and would love help with it.

Uhh.. I guess that’s all I can think of for right now. But I’ll keep this up to date.



Portions contributed by Christopher Small are copywrite © 2011 ThoughtNode Software.
Portions contributed by Matt Zukowski are copyright © 2010 Urbacon Ltd.
Other portions are copyright of their respective authors.


Also Christopher Small (ThoughtNode Software)


RubyCAS-Server is licensed for use under the terms of the MIT License.
See the LICENSE file bundled with the official RubyCAS-Server distribution for details.