-
Notifications
You must be signed in to change notification settings - Fork 217
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to programmatically authenticate #42
Comments
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? |
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. |
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. |
…turned 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. |
Fix bug #42 where we are unable to programmatically authenticate
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:
This is only because the server returns a 303. The user is correctly authenticated. In the server logs I see:
Doing a little more digging, the response is a
#<Net::HTTPSeeOther 303 See Other readbody=true>
In theLoginResponse
class, we are doing this to check for successful authentication: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.
The text was updated successfully, but these errors were encountered: