Ticket query string in the URL, required?

[matthew.hi...@gmail.com]

Hi all,

One more for you, if you don't mind.

I am authenticating my application against an instance of RubyCAS-server. After successful authentication, RubyCAS goes ahead and redirects me back to my main application. It also happens to append a query string that looks like the following:

?ticket=ST-1377360049rPJQKYi8YyM0CVHm6bD

Is this proper behavior? Is it the job of my main application to remove that from the URL if I don't want it filtering it? What do I do with this ticket if it is the right behavior because I do not see anything in the documentation discussing it. I figured all of the relevant information is stored in a session cookie or what not. Is it required to pollute my application URL with this ticket parameter? My application is built on top of Ruby on Rails 4, if that matters at all.

Thank you,

Matthew. 

[de Herdt Arne]

Hey matthew,

That's indeed the intended behavior of the application.

Your application should now consume the ticket and make a callback to the same CAS instance using the /serviceValidate operation, provide the ticket and service parameter.

If the ticket validation succeeds you get a basic user object back from this CAS that allows you to fire up the session on your side.

If you want to filter out the ticket from the URL, this is indeed something you have to do yourself.

--
You received this message because you are subscribed to the Google Groups "RubyCAS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubycas-serve...@googlegroups.com.
To post to this group, send email to rubycas...@googlegroups.com.
Visit this group at http://groups.google.com/group/rubycas-server.
For more options, visit https://groups.google.com/groups/opt_out.

[Matt Zukowski]

The ticket is how RubyCAS server tells your app that it has been authenticated. RubyCAS client (and any other CAS client) expects this query parameter to be there. There is no other way of the CAS server to indicate to the client service that you have been authenticated. Keep in mind that the CAS server only has access to the cookies on its own domain. It cannot reliably set cookies on the client service's domain. 

When you're redirected back from the CAS server to your client service, the CAS client takes this ticket value and sends it back to RubyCAS server for validation. The server replies back saying "yes this ticket is the one I just dished out", or it rejects it. If the ticket is valid, your CAS client sets a session cookie for the user indicating that they have been authenticated.

Hope that explains it. Here's a diagram I made a few years ago that tries to explain how CAS works: http://rubycas.github.io/images/basic_cas_single_signon_mechanism_diagram.png

--