Skip to content

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.

License

Notifications You must be signed in to change notification settings

metasoarous/read_only_rubycas_server

 
 

Repository files navigation

RORubyCAS-Server

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 http://code.google.com/p/rubycas-server

Installation

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 => "https://github.com/metasoarous/read_only_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"
end

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 config.ru directory

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

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)-

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
  log:
    level: DEBUG
  authenticator:
    class: CASServer::Authenticators::SQL
    database: inherit
    user_table: users
    username_column: email
    password_column: password
production:
  <<: *all
development:
  <<: *all
  database:
    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

development:
  adapter: sqlite3
  database: /home/cts/code/dem_cas_server/db/development.sqlite3
test:
  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.

Boring…

Copyright

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.

Authors

See http://github.com/gunark/rubycas-server/commits/
Also Christopher Small (ThoughtNode Software)

License

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.

About

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.

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • Ruby 99.3%
  • Shell 0.7%