Unable to programmatically authenticate #42

bradseefeld opened this Issue Jul 10, 2012 · 7 comments

2 participants


Programmatic authentication fails because RubyCAS server returns a 303 instead of a 302. I am not sure if a 303 is a valid response per the CAS protocol. Some sample code to repro:

username = "me"
password = "secret"
service_url = "http://myservice.example.com"
response = client.login_to_service({:username => username, :password => password}, service_url)
response.is_success? # false

This is only because the server returns a 303. The user is correctly authenticated. In the server logs I see:

I, [2012-07-10T22:58:30.053325 #18113]  INFO -- : Login ticket 'LT-1341961109r33014B38A614C87BEA' successfully validated
I, [2012-07-10T22:58:30.069214 #18113]  INFO -- : Credentials for username 'me' successfully validated using CASServer::Authenticators::DeviseWithLegacy.
I, [2012-07-10T22:58:30.108557 #18113]  INFO -- : Redirecting authenticated user 'me' at '' to service 'http://localhost:3030/resource'

Doing a little more digging, the response is a #<Net::HTTPSeeOther 303 See Other readbody=true> In the LoginResponse class, we are doing this to check for successful authentication:

if not ((http_response.kind_of?(Net::HTTPSuccess) || http_response.kind_of?(Net::HTTPFound)) && @ticket.present?)

From some brief research, it would appear that a 303 is a satisfactory response from the server, so that is why I have filed the ticket here instead of with rubycas-server.

RubyCAS member

Feel free to submit a pull request with a fix. This feature is going to get marked as deprecated in 2.4, so I'm not inclined to spend a lot of time on it.


Why is it being deprecated?

RubyCAS member

It's really a hack to work around the CAS protocol and defeats much of the security it provides. It seems people use this feature either because they can't get the cas client working correctly, which should be much easier before the feature is removed, or because they want to host the login page in their application. If they want the app to host the login page and handle taking the users credentials, then CAS is the wrong choice for Single Sign On. It's not designed for that. With the new design I'm working on, it will be easy for someone to write a gem to implement this feature, but it will eventually leave the core distribution.


This feature is used to programmatically authenticate and should remain a supported feature of rubycas-client. At the very least, it is part of the CAS spec. A completely valid use case of using such a feature is in rake tasks. I have a rake task that must interact with an API that requires authentication. In order to do this, the rake task makes a programmatic request to the CAS server for an authentication token and passes that along to the API (using the whole PGT workflow). Not all requests originate in the browser or from a user. It would be silly to deprecate this feature only to keep poor developers from abusing it.


Thoughts? I will submit a pull request so long as the feature is not going to be deprecated.

RubyCAS member

As I stated before, I'll gladly accept the pull request. The CAS protocol does recommend the use of 303 for the redirect (see Appendix B), which is why it was changed on the rubycas-server.

@bradseefeld bradseefeld pushed a commit to bradseefeld/rubycas-client that referenced this issue Aug 23, 2012
Brad Seefeld #42: HTTPSeeOther is the only valid response that should be returned …
…from the server on successful login

Well, looks like i screwed up the pull request because it is not linked to this issue... A new issue #50 was created. Sorry about that.

@bradseefeld bradseefeld pushed a commit to bradseefeld/rubycas-client that referenced this issue Sep 7, 2012
Brad Seefeld #42: Support legacy checks b7de9ec
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment