{"action":"closed","issue":{"url":"https://api.github.com/repos/BYU-ODH/BYU-CAS-npm/issues/2","repository_url":"https://api.github.com/repos/BYU-ODH/BYU-CAS-npm","labels_url":"https://api.github.com/repos/BYU-ODH/BYU-CAS-npm/issues/2/labels{/name}","comments_url":"https://api.github.com/repos/BYU-ODH/BYU-CAS-npm/issues/2/comments","events_url":"https://api.github.com/repos/BYU-ODH/BYU-CAS-npm/issues/2/events","html_url":"https://github.com/BYU-ODH/BYU-CAS-npm/issues/2","id":147802968,"number":2,"title":"getTicket is an anti-pattern","user":{"login":"agrasley","id":11893990,"avatar_url":"https://avatars.githubusercontent.com/u/11893990?v=3","gravatar_id":"","url":"https://api.github.com/users/agrasley","html_url":"https://github.com/agrasley","followers_url":"https://api.github.com/users/agrasley/followers","following_url":"https://api.github.com/users/agrasley/following{/other_user}","gists_url":"https://api.github.com/users/agrasley/gists{/gist_id}","starred_url":"https://api.github.com/users/agrasley/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/agrasley/subscriptions","organizations_url":"https://api.github.com/users/agrasley/orgs","repos_url":"https://api.github.com/users/agrasley/repos","events_url":"https://api.github.com/users/agrasley/events{/privacy}","received_events_url":"https://api.github.com/users/agrasley/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2016-04-12T16:20:24Z","updated_at":"2016-04-13T00:53:10Z","closed_at":"2016-04-13T00:53:10Z","body":"The `getTicket` method seems like an anti-pattern to me. The whole point of using third party authentication like CAS is that your app never has to deal with sensitive user information, i.e., passwords. The `getTicket` method breaks that by requiring you to receive a user's username and password before passing it on to CAS. This makes the CAS authentication process fundamentally more insecure, and essentially requires all servers that use this package to implement SSL. Otherwise, your server exposes user passwords to man-in-the-middle attacks over a plain HTTP connection. While it's generally a good thing in principle to implement SSL on all of your sites, I'm unsure if it's wise for a library like byu-cas to assume that it will always be used in an SSL-enabled environment.\r\n\r\nThe `getTicket` method just seems fundamentally at odds with my understanding of the CAS authentication process. The way I understand it, an application should only be concerned with validating a user ticket. The only part an application should play in obtaining that ticket is redirecting a user to the proper login endpoint on the CAS server. Adding a layer in between the user and the CAS login not only brings with it a lot of security concerns as I outlined above, but it's also just unnecessarily complex. Why use your node process on something that is much better done by the client browser? You can do the exact same thing as `getTicket` with a simple link element to BYU's CAS server and then a quick read of the `ticket` query parameter when the user gets redirected back to your site. It's easier on your server resources, far more secure since you never handle a user password, and it provides a lot fewer potential points of failure if something goes wrong.\r\n\r\nMy recommendation is to deprecate the `getTicket` method, only keeping it for legacy projects that rely on it. The documentation should make it clear that `getTicket` is a security risk if you use it in a non-SSL environment. The `validate` method is great, since it fits the general pattern established by CAS that a third-party application should only be concerned with validating user tickets. If our servers are doing something more than that, we're probably doing something very wrong."}}