biola / rack-cas Goto Github PK

In rails 4 I am throwing 401 when a user tries to access a protected resource, and it redirects me to login as I expect. I already have a valid session with the server open in the browser I'm using, and the server is backed by CASino. The server is responding with a ticket before the deadlock.

In the rails server log I see this bit of relevant information along with this stack trace which shows after about 2 minutes:

Completed 401 Unauthorized in 54ms (ActiveRecord: 2.2ms)
rack-cas: Intercepting 401 access denied response. Redirecting to CAS login.  CACHE (0.0ms)  SELECT "sessions".* FROM "sessions" WHERE "sessions"."session_id" = '6648cc0dfeedcf5c36f1d93465e10886' ORDER BY "sessions"."id" ASC LIMIT 1
   (0.1ms)  begin transaction
   (0.1ms)  commit transaction
rack-cas: Intercepting ticket validation request.[2013-11-15 07:51:54] ERROR Net::ReadTimeout: Net::ReadTimeout
    /Users/jtregunna/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/net/protocol.rb:158:in `rescue in rbuf_fill'
    /Users/jtregunna/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/net/protocol.rb:152:in `rbuf_fill'
    /Users/jtregunna/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/net/protocol.rb:134:in `readuntil'
    /Users/jtregunna/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/net/protocol.rb:144:in `readline'
    /Users/jtregunna/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/2rack-cas: Intercepting ticket validation request..0.0/net/http/response.rb:39:in `read_status_line'
    /Users/jtregunna/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/net/http/response.rb:28:in `read_new'
    /Users/jtregunna/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/net/http.rb:1406:in `block in transport_request'
    /Users/jtregunna/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/net/http.rb:1403:in `catch'
    /Users/jtregunna/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/net/http.rb:1403:in `transport_request'
    /Users/jtregunna/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/net/http.rb:1376:in `request'
    /Users/jtregunna/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/net/http.rb:1126:in `get'
    /Users/jtregunna/.rvm/gems/ruby-2.0.0-p195@teamapp/gems/rack-cas-0.8.1/lib/rack-cas/service_validation_response.rb:89:in `block in response'
    /Users/jtregunna/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/net/http.rb:852:in `start'
    /Users/jtregunna/.rvm/gems/ruby-2.0.0-p195@teamapp/gems/rack-cas-0.8.1/lib/rack-cas/service_validation_response.rb:88:in `response'
    /Users/jtregunna/.rvm/gems/ruby-2.0.0-p195@teamapp/gems/rack-cas-0.8.1/lib/rack-cas/service_validation_response.rb:98:in `xml'
    /Users/jtregunna/.rvm/gems/ruby-2.0.0-p195@teamapp/gems/rack-cas-0.8.1/lib/rack-cas/service_validation_response.rb:62:in `success?'
    /Users/jtregunna/.rvm/gems/ruby-2.0.0-p195@teamapp/gems/rack-cas-0.8.1/lib/rack-cas/service_validation_response.rb:15:in `user'
    /Users/jtregunna/.rvm/gems/ruby-2.0.0-p195@teamapp/gems/rack-cas-0.8.1/lib/rack-cas/server.rb:24:in `validate_service'
    /Users/jtregunna/.rvm/gems/ruby-2.0.0-p195@teamapp/gems/rack-cas-0.8.1/lib/rack/cas.rb:76:in `get_user'
    /Users/jtregunna/.rvm/gems/ruby-2.0.0-p195@teamapp/gems/rack-cas-0.8.1/lib/rack/cas.rb:33:in `call'
    /Users/jtregunna/.rvm/gems/ruby-2.0.0-p195@teamapp/gems/rack-1.5.2/lib/rack/lock.rb:17:in `call'
    /Users/jtregunna/.rvm/gems/ruby-2.0.0-p195@teamapp/gems/rack-1.5.2/lib/rack/content_length.rb:14:in `call'
    /Users/jtregunna/.rvm/gems/ruby-2.0.0-p195@teamapp/gems/rack-1.5.2/lib/rack/handler/webrick.rb:60:in `service'
    /Users/jtregunna/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/webrick/httpserver.rb:138:in `service'
    /Users/jtregunna/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/webrick/httpserver.rb:94:in `run'
    /Users/jtregunna/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/webrick/server.rb:295:in `block in start_thread'

Additionally, if I log out on the CAS server, and then repeat this process in my app using rac-cas, I get this:

rack-cas: Intercepting 401 access denied response. Redirecting to CAS login.  CACHE (0.0ms)  SELECT "sessions".* FROM "sessions" WHERE "sessions"."session_id" = '6648cc0dfeedcf5c36f1d93465e10886' ORDER BY "sessions"."id" ASC LIMIT 1
   (0.1ms)  begin transaction
   (0.1ms)  commit transaction
et/http.rb:1376:in `request'
    /Users/jtregunna/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/net/http.rb:1126:in `get'
    /Users/jtregunna/.rvm/gems/ruby-2.0.0-p195@teamapp/gems/rack-cas-0.8.1/lib/rack-cas/service_validation_response.rb:89:in `block in response'
    /Users/jtregunna/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/net/http.rb:852:in `start'
    /Users/jtregunna/.rvm/gems/ruby-2.0.0-p195@teamapp/gems/rack-cas-0.8.1/lib/rack-cas/service_validation_response.rb:88:in `response'
    /Users/jtregunna/.rvm/gems/ruby-2.0.0-p195@teamapp/gems/rack-cas-0.8.1/lib/rack-cas/service_validation_response.rb:98:in `xml'
    /Users/jtregunna/.rvm/gems/ruby-2.0.0-p195@teamapp/gems/rack-cas-0.8.1/lib/rack-cas/service_validation_response.rb:62:in `success?'
    /Users/jtregunna/.rvm/gems/ruby-2.0.0-p195@teamapp/gems/rack-cas-0.8.1/lib/rack-cas/service_validation_response.rb:15:in `user'
    /Users/jtregunna/.rvm/gems/ruby-2.0.0-p195@teamapp/gems/rack-cas-0.8.1/lib/rack-cas/server.rb:24:in `validate_service'
    /Users/jtregunna/.rvm/gems/ruby-2.rack-cas: Intercepting ticket validation request.0.0-p195@teamapp/gems/rack-cas-0.8.1/lib/rack/cas.rb:76:in `get_user'
    /Users/jtregunna/.rvm/gems/ruby-2.0.0-p195@teamapp/gems/rack-cas-0.8.1/lib/rack/cas.rb:33:in `call'
    /Users/jtregunna/.rvm/gems/ruby-2.0.0-p195@teamapp/gems/rack-1.5.2/lib/rack/lock.rb:17:in `call'
    /Users/jtregunna/.rvm/gems/ruby-2.0.0-p195@teamapp/gems/rack-1.5.2/lib/rack/content_length.rb:14:in `call'
    /Users/jtregunna/.rvm/gems/ruby-2.0.0-p195@teamapp/gems/rack-1.5.2/lib/rack/handler/webrick.rb:60:in `service'
    /Users/jtregunna/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/webrick/httpserver.rb:138:in `service'
    /Users/jtregunna/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/webrick/httpserver.rb:94:in `run'
    /Users/jtregunna/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/webrick/server.rb:295:in `block in start_thread'

We call our staging environment 'test' and run it as close to production. Since fake cas is enabled by default on the test environment, we're trying to turn it off by explicitly overriding it in the environment/test.rb

# config/environments/test.rb
config.rack_cas.fake = false

This brings an argument error when precompiling the assets

$ RAILS_ENV=test bin/rake assets:precompile --trace
** Invoke assets:precompile (first_time)
** Invoke assets:environment (first_time)
** Execute assets:environment
** Invoke environment (first_time)
** Execute environment
rake aborted!
ArgumentError: invalid setting: fake
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rack-cas-0.10.1/lib/rack-cas/configuration.rb:24:in `block in update'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rack-cas-0.10.1/lib/rack-cas/configuration.rb:22:in `each'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rack-cas-0.10.1/lib/rack-cas/configuration.rb:22:in `update'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rack-cas-0.10.1/lib/rack/cas.rb:12:in `initialize'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/actionpack-4.0.2/lib/action_dispatch/middleware/stack.rb:43:in `new'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/actionpack-4.0.2/lib/action_dispatch/middleware/stack.rb:43:in `build'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/actionpack-4.0.2/lib/action_dispatch/middleware/stack.rb:118:in `block in build'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/actionpack-4.0.2/lib/action_dispatch/middleware/stack.rb:118:in `each'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/actionpack-4.0.2/lib/action_dispatch/middleware/stack.rb:118:in `inject'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/actionpack-4.0.2/lib/action_dispatch/middleware/stack.rb:118:in `build'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/railties-4.0.2/lib/rails/engine.rb:495:in `app'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/railties-4.0.2/lib/rails/application/finisher.rb:34:in `block in <module:Finisher>'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/railties-4.0.2/lib/rails/initializable.rb:30:in `instance_exec'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/railties-4.0.2/lib/rails/initializable.rb:30:in `run'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/railties-4.0.2/lib/rails/initializable.rb:55:in `block in run_initializers'
/usr/local/rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/tsort.rb:150:in `block in tsort_each'
/usr/local/rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/tsort.rb:183:in `block (2 levels) in each_strongly_connected_component'
/usr/local/rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/tsort.rb:219:in `each_strongly_connected_component_from'
/usr/local/rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/tsort.rb:182:in `block in each_strongly_connected_component'
/usr/local/rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/tsort.rb:180:in `each'
/usr/local/rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/tsort.rb:180:in `each_strongly_connected_component'
/usr/local/rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/tsort.rb:148:in `tsort_each'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/railties-4.0.2/lib/rails/initializable.rb:54:in `run_initializers'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/railties-4.0.2/lib/rails/application.rb:215:in `initialize!'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/railties-4.0.2/lib/rails/railtie/configurable.rb:30:in `method_missing'
/vagrant/fenrir/config/environment.rb:5:in `<top (required)>'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/railties-4.0.2/lib/rails/application.rb:189:in `require'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/railties-4.0.2/lib/rails/application.rb:189:in `require_environment!'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/railties-4.0.2/lib/rails/application.rb:250:in `block in run_tasks_blocks'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rake-10.4.2/lib/rake/task.rb:240:in `call'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rake-10.4.2/lib/rake/task.rb:240:in `block in execute'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rake-10.4.2/lib/rake/task.rb:235:in `each'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rake-10.4.2/lib/rake/task.rb:235:in `execute'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rake-10.4.2/lib/rake/task.rb:179:in `block in invoke_with_call_chain'
/usr/local/rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/monitor.rb:211:in `mon_synchronize'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rake-10.4.2/lib/rake/task.rb:172:in `invoke_with_call_chain'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rake-10.4.2/lib/rake/task.rb:165:in `invoke'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/sprockets-rails-2.0.1/lib/sprockets/rails/task.rb:54:in `block (2 levels) in define'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rake-10.4.2/lib/rake/task.rb:240:in `call'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rake-10.4.2/lib/rake/task.rb:240:in `block in execute'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rake-10.4.2/lib/rake/task.rb:235:in `each'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rake-10.4.2/lib/rake/task.rb:235:in `execute'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rake-10.4.2/lib/rake/task.rb:179:in `block in invoke_with_call_chain'
/usr/local/rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/monitor.rb:211:in `mon_synchronize'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rake-10.4.2/lib/rake/task.rb:172:in `invoke_with_call_chain'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rake-10.4.2/lib/rake/task.rb:201:in `block in invoke_prerequisites'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rake-10.4.2/lib/rake/task.rb:199:in `each'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rake-10.4.2/lib/rake/task.rb:199:in `invoke_prerequisites'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rake-10.4.2/lib/rake/task.rb:178:in `block in invoke_with_call_chain'
/usr/local/rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/monitor.rb:211:in `mon_synchronize'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rake-10.4.2/lib/rake/task.rb:172:in `invoke_with_call_chain'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rake-10.4.2/lib/rake/task.rb:165:in `invoke'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rake-10.4.2/lib/rake/application.rb:150:in `invoke_task'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rake-10.4.2/lib/rake/application.rb:106:in `block (2 levels) in top_level'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rake-10.4.2/lib/rake/application.rb:106:in `each'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rake-10.4.2/lib/rake/application.rb:106:in `block in top_level'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rake-10.4.2/lib/rake/application.rb:115:in `run_with_threads'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rake-10.4.2/lib/rake/application.rb:100:in `top_level'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rake-10.4.2/lib/rake/application.rb:78:in `block in run'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rake-10.4.2/lib/rake/application.rb:176:in `standard_exception_handling'
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/rake-10.4.2/lib/rake/application.rb:75:in `run'
bin/rake:4:in `<main>'
Tasks: TOP => environment

Is there a way to turn off fake cas in the test environment?

What needs to be done to get this working? I'd love to contribute.

In my application I'm not getting extra attributes as they are only retrieved when you call samlValidate. However, from debug I found that this is not happening. Is there any configuration or instruction I'm missing for that to happen?

Running in Sinatra as written in the instructions, the CAS ticket doesn't seem to be accepted by rack-cas:

I, [2013-11-25T18:09:12.172067 #17165]  INFO -- : rack-cas: Intercepting 401 access denied response. Redirecting to CAS login.
127.0.0.1 - - [25/Nov/2013 18:09:12] "GET / HTTP/1.1" 302 - 0.0130
rack-cas: Intercepting ticket validation request.127.0.0.1 - - [25/Nov/2013 18:09:20] "GET /?ticket=ST-1385428074rWdVgUq9GQUN3f4u-jD HTTP/1.1" 302 - 0.9295
I, [2013-11-25T18:09:21.001796 #17165]  INFO -- : rack-cas: Intercepting 401 access denied response. Redirecting to CAS login.
127.0.0.1 - - [25/Nov/2013 18:09:21] "GET / HTTP/1.1" 302 - 0.0015
rack-cas: Intercepting ticket validation request.127.0.0.1 - - [25/Nov/2013 18:09:21] "GET /?ticket=ST-1385428075rNsq0nKw9feZ3EU8rOJ HTTP/1.1" 302 - 0.5048

This is after I have been redirected to the CAS server and have logged in. It loops around for a bit before getting an error. I've done everything as described, using this as my implementation in my app.rb:

before do
  halt 401 unless request.session['cas'] and request.session['cas']['user']
end

Any ideas?

Hi,

I'm using Sinatra and I have a route that just do this:
halt 401, 'Unauthorized!'
As I expect, rack-cas redirects me to my CAS server but the response has a 302 status, and does an infinite redirect loop, causing an error in my browser. I checked the source and it seems to be the default behaviour, right?
The log of my applications shows me this: INFO -- : rack-cas: Intercepting 401 access denied response. Redirecting to CAS login.

Do you have an idea of what I am missing? How can I avoid this loop?

Thanks for help.

Just wanted to open an issue to track changes for making the gem compatible with Rails 5 and Rack 2.

I have at least one issue right now with the ActiveRecord Session store.

I get the following error when receiving the ticket (in store_session):
RuntimeError (#find_session not implemented.)
This seems to be related to the following change to Rack::Session::Abstract::ID: rack/rack@4224c02

When using the cookie store everything seems to be working at the moment.

Hi All

I need to redirect the user to the page they requested upon successful authentication. I'm reasonably sure this is possible - but I can't find details on how to set this up.

For example - say a user is not logged into my site that uses rack-cas. They click on a link in an email which points to a page that requires authentication. CAS authentication 'kicks in' and once the user logs in - currently they're not taken to the page they requested - but rather the sites homepage.

I'm sure this is a well known issue / feature request. So - is this possible and what's changes need to be made to achieve this result ?

Thanks
Dave

The title says much of what I can gather on the error. In my limited understanding, I am receiving an error from my application after the user has successfully logged into the CASino App with their active directory credentials.

Here is the log output after I click a link that requires authentication. After I log in I am redirected back, but instead of the page I am expecting I end up seeing an error page telling me the certificate verify failed.

Any guidance would be appreciated. Thanks

Started GET "/lazaretto/logs/new" for 127.0.0.1 at 2017-06-19 11:49:09 -0500
Processing by LogsController#new as HTML
Rendered text template (0.0ms)
Filter chain halted as :authenticate! rendered or redirected
Completed 401 Unauthorized in 10ms (Views: 7.8ms | ActiveRecord: 0.0ms)
rack-cas: Intercepting 401 access denied response. Redirecting to CAS login.

Started GET "/lazaretto/logs/new?ticket=ST-14978909498450-YQyTf3Exc2pFHMmgkI209iDRA1iFDuIKYdcA1Xg2" for 127.0.0.1 at 2017-06-19 11:49:09 -0500
rack-cas: Intercepting ticket validation request.
OpenSSL::SSL::SSLError (SSL_connect returned=1 errno=0 state=error: certificate verify failed):
/home/brent/.rbenv/versions/2.3.3/lib/ruby/2.3.0/net/http.rb:933:in connect_nonblock' /home/brent/.rbenv/versions/2.3.3/lib/ruby/2.3.0/net/http.rb:933:in connect'
/home/brent/.rbenv/versions/2.3.3/lib/ruby/2.3.0/net/http.rb:863:in do_start' /home/brent/.rbenv/versions/2.3.3/lib/ruby/2.3.0/net/http.rb:852:in start'
rack-cas (0.9.2) lib/rack-cas/service_validation_response.rb:88:in response' rack-cas (0.9.2) lib/rack-cas/service_validation_response.rb:98:in xml'
rack-cas (0.9.2) lib/rack-cas/service_validation_response.rb:62:in success?' rack-cas (0.9.2) lib/rack-cas/service_validation_response.rb:15:in user'
rack-cas (0.9.2) lib/rack-cas/server.rb:24:in validate_service' rack-cas (0.9.2) lib/rack/cas.rb:76:in get_user'
rack-cas (0.9.2) lib/rack/cas.rb:33:in call' rack (1.6.8) lib/rack/etag.rb:24:in call'
rack (1.6.8) lib/rack/conditionalget.rb:25:in call' rack (1.6.8) lib/rack/head.rb:13:in call'
actionpack (4.2.5) lib/action_dispatch/middleware/params_parser.rb:27:in call' actionpack (4.2.5) lib/action_dispatch/middleware/flash.rb:260:in call'
rack (1.6.8) lib/rack/session/abstract/id.rb:225:in context' rack (1.6.8) lib/rack/session/abstract/id.rb:220:in call'
actionpack (4.2.5) lib/action_dispatch/middleware/cookies.rb:560:in call' activerecord (4.2.5) lib/active_record/query_cache.rb:36:in call'
activerecord (4.2.5) lib/active_record/connection_adapters/abstract/connection_pool.rb:653:in call' activerecord (4.2.5) lib/active_record/migration.rb:377:in call'
actionpack (4.2.5) lib/action_dispatch/middleware/callbacks.rb:29:in block in call' activesupport (4.2.5) lib/active_support/callbacks.rb:88:in run_callbacks'
activesupport (4.2.5) lib/active_support/callbacks.rb:778:in _run_call_callbacks' activesupport (4.2.5) lib/active_support/callbacks.rb:81:in run_callbacks'
actionpack (4.2.5) lib/action_dispatch/middleware/callbacks.rb:27:in call' actionpack (4.2.5) lib/action_dispatch/middleware/reloader.rb:73:in call'
actionpack (4.2.5) lib/action_dispatch/middleware/remote_ip.rb:78:in call' actionpack (4.2.5) lib/action_dispatch/middleware/debug_exceptions.rb:17:in call'
web-console (2.3.0) lib/web_console/middleware.rb:28:in block in call' web-console (2.3.0) lib/web_console/middleware.rb:18:in catch'
web-console (2.3.0) lib/web_console/middleware.rb:18:in call' actionpack (4.2.5) lib/action_dispatch/middleware/show_exceptions.rb:30:in call'
railties (4.2.5) lib/rails/rack/logger.rb:38:in call_app' railties (4.2.5) lib/rails/rack/logger.rb:20:in block in call'
activesupport (4.2.5) lib/active_support/tagged_logging.rb:68:in block in tagged' activesupport (4.2.5) lib/active_support/tagged_logging.rb:26:in tagged'
activesupport (4.2.5) lib/active_support/tagged_logging.rb:68:in tagged' railties (4.2.5) lib/rails/rack/logger.rb:20:in call'
actionpack (4.2.5) lib/action_dispatch/middleware/request_id.rb:21:in call' rack (1.6.8) lib/rack/methodoverride.rb:22:in call'
rack (1.6.8) lib/rack/runtime.rb:18:in call' activesupport (4.2.5) lib/active_support/cache/strategy/local_cache_middleware.rb:28:in call'
rack (1.6.8) lib/rack/lock.rb:17:in call' actionpack (4.2.5) lib/action_dispatch/middleware/static.rb:116:in call'
rack (1.6.8) lib/rack/sendfile.rb:113:in call' railties (4.2.5) lib/rails/engine.rb:518:in call'
railties (4.2.5) lib/rails/application.rb:165:in call' rack (1.6.8) lib/rack/lock.rb:17:in call'
rack (1.6.8) lib/rack/content_length.rb:15:in call' rack (1.6.8) lib/rack/handler/webrick.rb:88:in service'
/home/brent/.rbenv/versions/2.3.3/lib/ruby/2.3.0/webrick/httpserver.rb:140:in service' /home/brent/.rbenv/versions/2.3.3/lib/ruby/2.3.0/webrick/httpserver.rb:96:in run'
/home/brent/.rbenv/versions/2.3.3/lib/ruby/2.3.0/webrick/server.rb:296:in `block in start_thread'

Rendered /home/brent/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/actionpack-4.2.5/lib/action_dispatch/middleware/templates/rescues/_source.erb (3.4ms)
Rendered /home/brent/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/actionpack-4.2.5/lib/action_dispatch/middleware/templates/rescues/_trace.html.erb (7.7ms)
Rendered /home/brent/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/actionpack-4.2.5/lib/action_dispatch/middleware/templates/rescues/_request_and_response.html.erb (1.6ms)
Rendered /home/brent/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/actionpack-4.2.5/lib/action_dispatch/middleware/templates/rescues/diagnostics.html.erb within rescues/layout (30.5ms)
Rendered /home/brent/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/web-console-2.3.0/lib/web_console/templates/_markup.html.erb (0.4ms)
Rendered /home/brent/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/web-console-2.3.0/lib/web_console/templates/_inner_console_markup.html.erb within layouts/inlined_string (0.5ms)
Rendered /home/brent/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/web-console-2.3.0/lib/web_console/templates/_prompt_box_markup.html.erb within layouts/inlined_string (0.3ms)
Rendered /home/brent/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/web-console-2.3.0/lib/web_console/templates/style.css.erb within layouts/inlined_string (0.3ms)
Rendered /home/brent/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/web-console-2.3.0/lib/web_console/templates/console.js.erb within layouts/javascript (30.6ms)
Rendered /home/brent/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/web-console-2.3.0/lib/web_console/templates/main.js.erb within layouts/javascript (0.3ms)
Rendered /home/brent/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/web-console-2.3.0/lib/web_console/templates/error_page.js.erb within layouts/javascript (0.4ms)
Rendered /home/brent/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/web-console-2.3.0/lib/web_console/templates/index.html.erb (55.3ms)

Hi!
I'm trying to include Rack-CAS in a sinatra application. We were using RubyCAS-Client but we want to change it.
I include Rack-CAS to a simple sinatra application before doing it in my real app and it works just fine.
The difference between the real app and the simple one or the examples in other issues is that we are using Sequel and the request.session hash is no loaded.
When I print request.session in the console I get:
#<Rack::Session::Abstract::SessionHash:0x155980927f40 not yet loaded>
Because of that I'm getting a redirection loop because my app could not read it. Is there any chance to have a solution similar to the one for Rails and ActiveRecord? Sequel implements the same pattern.

Other difference we have is that we're also using Shield::Middleware and Shield work with the 401 Unauthorized.

I don't be able to establish wich gem is causing trouble (or both)

Any ideas?

Thanks for all

Best Regards,
Lucas

Is it possible to make it work with a CAS server working as a 'subapplication' ?
I've set it up as:
http://client/ - client using rack-cas
http://client/auth - server (CASinoApp)
http://otherclient/ - another client using rack-cas

The config in the client's is set to:
config.rack_cas.server_url = 'http://client/auth/'

Everything works ok until...
On some logins the auth server authenticates, send's the ticket to client (/?ticket=ST-xxxx)
Then the client redirects to his main url (/?).
And at this point sometimes I can see an 'Aborted' state in Firebug's network tab and the browser is sent to /login?service=xxx (instead of /auth/login?service=xxx which is correct for me).
This way the request hits client app with path /login instead of hitting the server app.

The aborted action is visible much less often on the http://client/ than on http://otherclient/ (guess this is dependent on the 'distance' of the servers).

Is there anything that can be done to make it work as I expect it ?

Regards,
Piotr

Hello,

I am currently working on a project where we are allowing our users (students) to connect themself from their educational platform.
A lot of them platform expose a CAS Server and we are using them to implement SSO.

Our POC was using rack-cas but now we need to allow users to login from different CAS servers.

Does rack-cas can handle multiple servers, based on request URL or is it planned in your roadmap ?
Do i need to dig for another solution instead of this gem to handle my case ?

Thanks,
Jules

Nokogiri::XML::XPath::SyntaxError
Undefined namespace prefix: /cas:serviceResponse/cas:authenticationSuccess

I am getting these when redirecting to client after authentication from client

server console log:

method=POST path=/login format=html controller=casino/sessions action=create status=303 duration=184.19 view=0.00 db=45.24 location=http://localhost:3000/?ticket=ST-14382625833483-xJuAH6G9SXSShNaqGObC8ZpshPFT4vVR6PQzlPFu params={"utf8"=>"✓", "authenticity_token"=>"EqmB55XUTUghYxsemXP3nZPadkaQCcnSqxxdhJyblfPrDsnMw4S17As+axDJoFX0XaC4aJIq36+atYSLFvt6IQ==", "lt"=>"LT-14382625688311-0ymCWT6EkVrHlFww8qfdY3m4aZOIiiDsWiUtLqdY", "service"=>"http://localhost:3000/", "username"=>"[email protected]", "password"=>"[FILTERED]", "button"=>""}
DEBUG: Chewy strategies stack: [2] -> atomic @ /home/.rvm/gems/ruby-2.1.5@vakilsearch/gems/chewy-0.8.1/lib/chewy/railtie.rb:16
DEBUG: Chewy strategies stack: [2] <- atomic @ /home/.rvm/gems/ruby-2.1.5@vakilsearch/gems/chewy-0.8.1/lib/chewy/railtie.rb:16
method=GET path=/serviceValidate format=*/* controller=casino/service_tickets action=service_validate status=302 duration=0.69 view=0.00 db=0.00 location=http://localhost:3001/login params={"service"=>"http://localhost:3000/", "ticket"=>"ST-14382625833483-xJuAH6G9SXSShNaqGObC8ZpshPFT4vVR6PQzlPFu"}

I think I'm getting this error because of fake cas. The URI and routes work on the local application, it works when testing the routes themselves, and I get 302 redirects in request tests. However the way to test in a feature test which is depicted in the documentation is not working.

  1) Admins requires to be signed in as an admin
     Failure/Error: visit '/login'

     URI::InvalidURIError:
       bad URI(is not URI?):
     # /usr/local/bundle/gems/capybara-3.4.1/lib/capybara/rack_test/browser.rb:59:in `process'
     # /usr/local/bundle/gems/capybara-3.4.1/lib/capybara/rack_test/browser.rb:51:in `block in process_and_follow_redirects'
     # /usr/local/bundle/gems/capybara-3.4.1/lib/capybara/rack_test/browser.rb:46:in `times'
     # /usr/local/bundle/gems/capybara-3.4.1/lib/capybara/rack_test/browser.rb:46:in `process_and_follow_redirects'
     # /usr/local/bundle/gems/capybara-3.4.1/lib/capybara/rack_test/browser.rb:23:in `visit'
     # /usr/local/bundle/gems/capybara-3.4.1/lib/capybara/rack_test/driver.rb:45:in `visit'
     # /usr/local/bundle/gems/capybara-3.4.1/lib/capybara/session.rb:269:in `visit'
     # /usr/local/bundle/gems/capybara-3.4.1/lib/capybara/dsl.rb:51:in `block (2 levels) in <module:DSL>'
     # ./spec/features/admins_spec.rb:6:in `block (2 levels) in <top (required)>'
     # ------------------
     # --- Caused by: ---
     # NoMethodError:
     #   undefined method `to_str' for nil:NilClass
     #   /usr/local/bundle/gems/capybara-3.4.1/lib/capybara/rack_test/browser.rb:59:in `process'

    @cas_server_url = "https://subdomain.college.edu/cas/login"
    config.rack_cas.server_url = @cas_server_url
    # config.rack_cas.protocol = 'p3'
    # config.rack_cas.session_store = RackCAS::ActiveRecordStore

So I've followed the documentation, and there is a good change I'm just doing something wrong. However, the URL produced in rails doesn't seem to point to the right place.

The URL it sends me to from the above example would be
https://subdomain.college.edu/login?service=http://localhost:3010/ and I need it to be like this
https://subdomain.college.edu/cas/login?service=http://localhost:3010/

Are there more configurations I can try or is this a bug that needs modified?

Hello,
Is there any chance that the nokogiri version in the gemspec can be updated?
My bundler-audit had suggested nokogiri be upgraded to >= 1.7.1, see:
https://github.com/rubysec/ruby-advisory-db/blob/master/gems/nokogiri/CVE-2016-4658.yml
Great gem, thanks!

Not so much an issue, as a documentation request. I'm confused with what rack_cas:sessions:prune:active_record is doing? Is it just removing sessions from the table that were never logged out?

What's a good approach to running this in production? Just a cron job? Something else?

Hi,

Someone is using this gem with Rails API? it's possibile to return 403 instead of a redirect to cas login page if not logged in?

Sorry if this is not a Rack-Cas issue, but I don't know what to do more to solve it ...

We have a CAS Server using rubycas-server, all of our Rails 3.x apps are using the rubycas-client and rubycas-client-rails.

We are upgrading our Apps from Rails 3.x to 4.x, and switching from rubycas-client-rails to Rack-Cas.

We think that we have setup all correctly.

Once we go to our App, the page is redirected to our CAS Server, we enter the correct user&password, and in the Rails app that uses Rack-Cas we get:

I, [2014-09-26T18:14:52.781275 #18267]  INFO -- : Started GET "/?ticket=ST-1411769692rt8JqxgI9Qv-NErjrkZ" for 80.30.75.89 at 2014-09-26 18:14:52 -0400
F, [2014-09-26T18:14:53.081949 #18267] FATAL -- : 
Nokogiri::XML::XPath::SyntaxError (Undefined namespace prefix: /cas:serviceResponse/cas:authenticationSuccess):
  nokogiri (1.6.3.1) lib/nokogiri/xml/node.rb:159:in `evaluate'
  nokogiri (1.6.3.1) lib/nokogiri/xml/node.rb:159:in `block in xpath'
  nokogiri (1.6.3.1) lib/nokogiri/xml/node.rb:150:in `map'
  nokogiri (1.6.3.1) lib/nokogiri/xml/node.rb:150:in `xpath'
  nokogiri (1.6.3.1) lib/nokogiri/xml/node.rb:104:in `search'
  nokogiri (1.6.3.1) lib/nokogiri/xml/node.rb:229:in `at'
  rack-cas (0.9.2) lib/rack-cas/service_validation_response.rb:62:in `success?'
  rack-cas (0.9.2) lib/rack-cas/service_validation_response.rb:15:in `user'

The log from our CAS server using rubycas has:

Proceeding with CAS login for service "https://stage-xxxxxxxx.xxxxxxxxxxx.com".

Login ticket 'LT-1411769650r5K23cW5stYDwCflk-t' successfully validated
CASServer::Authenticators::ActiveDirectoryLDAP: Did not read any extra_attributes for user "xxxxxxxx" even though an :extra_attributes option was provided.
Credentials for username 'xxxxxxxx' successfully validated using CASServer::Authenticators::ActiveDirectoryLDAP.
Redirecting authenticated user 'raimon' at 'xx.xx.xx.xx' to service 'https://stage-xxxxxxx.xxxxxxx.com'

We are using the same CAS server that we have in production, and this CAS server is working fine with our current Apps using rubycas-client-rails. We have the problem only when we authenticate from app that is using Rack-Cas

Can be that ruby-cas-server is not sending the correct xml details in the response?

This is with a new Rails app created for this specific test.

thanks for all,

regards,

Just a question here.

I have a force_login method that I'm using as a before filter on the actions that need it, I usually just put it over the entire app in my application controller. It looks something like this:

unless (session['cas'] and session['cas']['user'])
  render status: :unauthorized, text: 'Redirecting to CAS sign in...'
end

If I'm using the exclude_path or exclude_paths options, rack-cas kicks back requests that are excluded and I'm left with just a page saying "Redirecting to CAS sign in...". To get around that I can add logic in my app that replicates this:

I.e., it only checks for a valid session if the path is not excluded. But that seems redundant, since rack-cas is doing it anyway. Is there a better way to go about this? Say, catch what rack-cas kicks back and render the original request rather than the 401?

I'm guessing not, and that I have to replicate the logic in my app, as rack-cas needs the 401 to be passed the request in the first place.

Hello,
I have a problem with RackCAS when the session has expired and the transmission is of type TURBO_STREAM because the action understands that the session has expired, deletes the expired session, creates a new one, redirects to the new portal for login but does it via TURBO_STREAM and not forcing the entire application to be reedirected via HTML and obviously does not display anything within the turbo-frame that generated the activity.

Any ideas to solve the problem?
Thank you
Francesco

According to the docs

Your app should return a 401 status whenever a request is made that requires authentication. Rack-CAS will catch these responses and attempt to authenticate via your CAS server.

Using the following configuration on my development server:

{
  :server_url => "http://localhost:3001/",
  :session_store => RackCAS::ActiveRecordStore,
  :verify_ssl_cert => false,
  :renew => true
}

I have a CASino server running on port 3001. Here's my log files when I hit a 401 status while trying to access an ActiveAdmin page require authorization:

Started GET "/admin/referrals/new" for 127.0.0.1 at 2015-11-30 18:27:33 -0600
Processing by Admin::ReferralsController#new as HTML
Completed 401 Unauthorized in 2ms (ActiveRecord: 0.0ms)

Started GET "/admin/login" for 127.0.0.1 at 2015-11-30 18:27:33 -0600
Processing by ActiveAdmin::Devise::SessionsController#new as HTML
Rendered /home/cyle/.rvm/gems/ruby-2.2.2/bundler/gems/activeadmin-5a2b7b5bc683/app/views/active_admin/devise/shared/_links.erb (0.3ms)
Rendered /home/cyle/.rvm/gems/ruby-2.2.2/bundler/gems/activeadmin-5a2b7b5bc683/app/views/active_admin/devise/sessions/new.html.erb within layouts/active_admin_logged_out (19.8ms)
Completed 200 OK in 41ms (Views: 37.9ms | ActiveRecord: 0.0ms)

I'm not really seeing anything to indicate that rack-cas is indeed intercepting the 401 response. I noticed ActiveAdmin wasn't setting the status correctly in the response header, so to discern if this was an ActiveAdmin issue I also tried to manually return a 401 status in one of my controller actions with the correct header and met similar results. Is there some way I can go about debugging this further?

In configurations for session_store.rb we have to do something lile:

require 'rack-cas/session_store/rails/active_record'
YourApp::Application.config.session_store :rack_cas_active_record_store

but then it threw NameError in rails 4.0.2:

gems/railties-4.1.10/lib/rails/application/configuration.rb:151:in `const_get': uninitialized constant ActionDispatch::Session::RackCASActiveRecordStore (NameError)

Rails takes hash (https://github.com/rails/rails/blob/4-0-stable/railties/lib/rails/application/configuration.rb#L144) and uses camelize method to get RackCASActiveRecordStore but it defined as RackCasActiveRecordStore in file:
https://github.com/biola/rack-cas/blob/master/lib/rack-cas/session_store/rails/active_record.rb#L6

So 'rack_cas_active_record_store'.camelize gives:
Rails 4.0.2: "RackCasActiveRecordStore"
Rails 4.1.10: "RackCASActiveRecordStore"

To fix it I used:
YourApp::Application.config.session_store ActionDispatch::Session::RackCasActiveRecordStore in my session_store file.

So maybe we can just update README file and we are good? :)

Code inside controller method:
render :nothing => true, :status => :unauthorized

Code inside application.rb:
config.rack_cas.server_url = 'https://login.umd.edu/cas/login' # UMD CAS System Integration

Is there any way to get around this? Also doesn't work on Heroku when I try opening the app.

The CAS protocol specification says that services must accept service tickets of up to 32 characters in length, and should accept tickets up to 256 characters long. My CAS server returns tickets which are shorter than 32 characters, and the current code treats them as invalid.

Hello, I recently learned about this ActionDispatch::Integration::Session which is the object that you find yourself inside of (I guess?) when you are running an Integration test in Test::Unit. From the rails console executed as a standalone process you can access this object as 'app' – neat!

So I wanted to try and use this with my app, to do some interactive debugging in a way without starting up a full server. The first hurdle I found of course is that CAS wants me to log in unless I disable it... I thought there might be a way to manipulate the session interactively so that I wouldn't need to disable it, but I found nothing like that.

What I wound up doing is enable FakeCAS, to get around the need to use an actual CAS server, but still putting the right things in my session so that helpers and controllers that expect to have a proper user session set up before they run, don't choke. I figured I can send a POST to '/login' like the FakeCAS login prompt does....

I tried having a conversation to establish a session like this, and this is what the result is like:

2.3.0 :001 > app.get '/'


Started GET "/" for 127.0.0.1 at 2017-07-18 15:48:08 -0400
  ActiveRecord::SchemaMigration Load (30.6ms)  SELECT "schema_migrations".* FROM "schema_migrations"
Processing by IndexController#index as HTML
  Rendered text template (0.0ms)
Filter chain halted as :authenticate rendered or redirected
Completed 401 Unauthorized in 23ms (Views: 11.9ms | ActiveRecord: 0.0ms)
 => 200
2.3.0 :002 > puts app.response.body
<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8"/>
    <title>Fake CAS</title>
  </head>
  <body>
    <form action="/login" method="post">
      <input type="hidden" name="service" value="http://www.example.com/"/>
      <label for="username">Username</label>
      <input id="username" name="username" type="text"/>
      <label for="password">Password</label>
      <input id="password" name="password" type="password"/>
      <input type="submit" value="Login"/>
    </form>
  </body>
</html>
 => nil
2.3.0 :003 > app.post '/login', params: {username: 'KINGDON', password: 'aosidfj', service: 'http://localhost:3000'}


Started POST "/login" for 127.0.0.1 at 2017-07-18 15:48:37 -0400
 => 302
2.3.0 :004 > app.response.redirect_url
 => nil
2.3.0 :005 > app.response.body
 => "Redirecting you..."
2.3.0 :006 > app.session['cas']
 => {"user"=>nil, "extra_attributes"=>{}}

I'm sure I'm not exactly meant to use rack-cas in this way, but is this a bug?

Look at that redirect in particular. I looked at the response.headers and it looks like Location is unset. What kind of redirect is that?

When I do this exchange with a browser, I get redirected properly (and I don't know why, if you can answer that one thing for me it might be all I need to know...) When I do the exchange with a rails console, I just seem to be missing something. I tried setting app.session['cas']={'user' => 'KINGDON'} here but it does not seem to be effective, I think it is just discarded information when the next request is handled.

I could set the cookie I think, but it's encrypted and that seems even more cumbersome.

So, the next thing I tried was adding a pry statement to the user_login method, the second of the before_actions that I call after authenticate in my ApplicationController. This is the method that makes sure I got back a valid user who is actually authorized and setup their session.

2.3.0 :007 > app.get '/'


Started GET "/" for 127.0.0.1 at 2017-07-18 15:51:30 -0400
Processing by IndexController#index as HTML

From: /Users/kingdonb/Desktop/devel/pa/pa_phase2/app/controllers/application_controller.rb @ line 19 ApplicationController#user_login:

    18: def user_login
 => 19:   binding.pry
    20:   if session['cas']['user'].nil?
    21:     login_err("Your single sign on authentication could not be verified.")
    22:     return false
...

> session['cas']['user'] = 'KINGDON'
> ^D
...

> app.get '/'


Started GET "/" for 127.0.0.1 at 2017-07-18 15:51:30 -0400
Processing by IndexController#index as HTML

From: /Users/kingdonb/Desktop/devel/pa/pa_phase2/app/controllers/application_controller.rb @ line 19 ApplicationController#user_login:

    18: def user_login
 => 19:   binding.pry
...
> ^D

2.3.0 :014 > app.session['cas']
 => {"user"=>"KINGDON", "extra_attributes"=>{}}

That looks like it worked, now I can have an interactive session and issue all of the app.get calls I want, the session will be persisted. It just seemed like there should be an easier way to get there.

Do you have any ideas for me about how to handle this better? Is there a better way to bootstrap a request and get a response context from inside of Rails Console? I apologize that this issue is a little outside of what's probably a supported use of rack-cas, but I was hoping maybe you could answer some of that, or at least help me understand how I'm getting a session with user set to nil?

I am using rails 5.1.5 in my service. I would like to log out a user from a controller method after some user action in the service. It shouldn't be a action on view like a redirect to a logout page. I tried to insert a separate line into the controller,
request.session.send (request.session.respond_to?(:destroy) ? :destroy : :clear)
and request.session[:cas ] was destroyed, but after, as I understood, there was a call to the CAS, and a new request.session[:cas ] one returned to the service with a new service ticket. Is it possible to refer to the gem to completely interrupt the user's session.Thanks in advance

If I understand correctly this code below means, that rack cas will intercept logout action only on a fixed route. What if I do not want Rack-cas to handle logout, or to handle using another path?

class CASRequest
...
def logout?
    @request.path_info == '/logout'
end

class Rack::CAS
...
if cas_request.logout?
      log env, 'rack-cas: Intercepting logout request.'

      request.session.clear
      return redirect_to server.logout_url(request.params).to_s
end

I would like to build a plugin for Redmine using Rack-CAS. Redmine however uses Basic Auth for it's API and I don't want to brake that. Can I tell Rack-CAS to ignore certain 401s?

In some testing environments a valid SSL certificate isn't available for the CAS server. It would be nice to optionally not validate the cert.

Hey guys,

I am using CASino app as server and rack-cas as client i followed the documentation correctly. Everything was setup in config/application.rb, after starting client its pointing to server correctly and after authenticating i am getting "redirecting loop in chrome and page is not redirectimg properly in firefox"

Steps i followed

1. started both Sever n Client in local
2. In client i added devise and devise_cas_authenticatable

I'm on rails 4.2.1, and am I'm able to login fine using CAS. However, I'm getting an empty hash when trying to view extra_attributes.

I've already whitelisted the attributes in config/application.rb like so:
config.rack_cas.extra_attributes_filter = %w(groupMembership mail)

I'm using Jasig CAS 3.5.3, and defining the attributes that the service can see in the Services Management Console as decribed in https://wiki.jasig.org/display/CASUM/Services+Management

At this point, I'm using pretty much the same same controller and view code as the demo.

Any ideas?

require 'sinatra'
require 'rack/cas'

use Rack::CAS, server_url: 'cas.myurl.com/'

# Databases
database_urls = {
  :development => 'sqlite3:///flutterbase.sqlite3',
  :production => 'postgres://fskqaptoxqypzi:mNMoH-q9gQCinz3NNsD2ZwkFTV@ec2-54-225-102-116.compute-1.amazonaws.com:5432/d150tscrj7b80s'
}

set :database, database_urls[settings.environment]

# Routes
get '/' do
  erb :home
end

The above code seems to react if it's not input correctly (i.e. trying to run the code without a server_url sends back a proper error), but it doesn't redirect to the CAS login page when it is input correctly. Is Rack::CAS only functional with modular Sinatra?

Hi, i've found this plugin very usefull, but in the logout procedure i like to have redirection on my page, not the login server page. I've used this plugin with rubycas-server gem, and it support redirection on logout when specified service and gateway query parameters. So i've updated the rack/cas.rb and the rack-cas/server.rb files: i show here my contribute

• file cas.rb
  line n. 42
  return redirect_to server.logout_url(request.url).to_s

• file server.rb
  lines n. 15..17 update function logout_url

  def logout_url(service_url)
  query = URL.parse(service_url).query_values
  if query['service']
  @url.dup.append_path('logout').add_params(gateway: '1', service: query['service'])
  else
  @url.dup.append_path('logout')
  end
  end

i Hope this will be usefull to make it better
Giorgio

In a previous conversation, I was telling @adamcrown to implement a route, available when rack-cas is on the test mode, to access the login form provided by the FakeCAS.

Today this login form is only accessible when the controller returns a 401 unauthorized response, and I wish to have a route like /fake_cas_login which calls a FakeCAS controller to serve this login form.

Generally, when I use rack-cas, the rescue strategy for unauthorized access is to redirect the user to the CAS server's login page.

This is what should happen in production, but for the development and test environments we don't expect that, since the CAS server serves only the production environment.

Is there any way to achieve the opposite of exclude_path feature, I only want to protect some part of my routes ? I was planning to add an include_path feature but maybe there is no need for such feature.

The link pointing to http://jasig.github.io/ on the ReadMe is currently broken/missing(multiple different repos seem to be referencing this domain).

More than happy to fix these if the domain has just moved/changed, just need to know where :)

Hi!

I am currently trying to configure rack-cas with a project, with single logout. I have followed the readme instructions, using the rack-cas-generated migration to update my db schema, and have edited my session store initializer to point to the RackCas ActiveRecord session store.

When logging in, rack-cas successfully intercepts the ticket validation request, and creates a session as intended. However, for some reason the cas_ticket data doesn't get saved to the session record, which means that on logout, I am unable to delete the session from the session store.

I can confirm from logs and local debugging that the request from my CAS server does send the TGT correctly, and that the store_session method from lib/cas.rb does receive that TGT and saves it to request.session

Any ideas about what might be preventing the session record to be created without the tgt filled?

I have an application that is running on http://foo.example.com/app. Is there an easy way to tell rack-cas that my service URL lives at http://foo.example.com/app/service, rather than http://foo.example.com/service?

Thanks!

The README states that rack-cas requires Ruby 1.9.2 or greater. However, the Redis.rb file uses hash arguments in the self.write method. Not sure if the Readme or the method itself should be updated but I thought this was worth pointing out for folks running legacy ruby version apps (like myself 😆).

There hasn't been a release in quite a while, and the new Redis session store, for example, is missing from any gem release. Is there one planned for the near future? What are the obstacles to getting one if not?

Hello,

I would like to know if this gem supports client proxy, if not is there anything else out there for rails applications that implements this?

Thanks!

I'm trying to use the RackCAS on my client , with casino as my server cas.
I followed the instructions in the readme, but I can not get the session my client and also do not see any attempt to access api my cas server, is there any example using is gem with rails?

Currently rack-cas sends the user's request path as 'service_url'. The service_url however is used as the unique identifier for the service on the authenticating server side.

So if the request is with service_url mysite.com/users/profile, the ticket that is issued is not going to be considered a valid ticket for mysite.com/history or any other path on the site other than /users/profile.

As far as I can tell, this issue is masked by the fact that a lot of people (myself included) load the user info from session, and consider the user authorized as long as session['cas'] is set, without actually validating the user ticket. I don't see any automatic call to 'validation' in rack-cas gem.

I don't see anything in the CAS specification that describes decoupling service_url from return url that user should be redirected to - I think this is a failure in the spec. I submitted patches to rubycas-server and rack-cas-client to use an additional 'from' parameter that would hold the service path that would be combined with the service_url to generate the user return url for redirection.

I can submit a similar patch to your project if you agree that this is a good solution to the problem.