Thanks Ray, much appreciated! On Friday, December 13, 2019 at 1:31:26 PM UTC-8, rbon wrote: > > Bobby, > > One option might be to store the secured destination url in the session. > In the login page, retrieve that url and redirect. > It might be too presumptuous for spring security to do the redirect in > case you wanted to interrupt the post log in flow. > > Ray > > On Fri, 2019-12-13 at 12:20 -0800, Bobby Esfandiari wrote: > > Ray, > > Thanks for those steps. They look about the same as what I see until the > last one, where the ticket is not being removed. > > Just to clarify, you're using custom code to strip out the ticket and its > value in those apps? Right now I'm manually stripping out the ticket using > Angular in the front end, but that's not an ideal solution. It'd be really > nice if spring-security-cas would do it out of the box and I'm trying to > understand why that's not happening. > > > On Friday, December 13, 2019 at 10:41:21 AM UTC-8, rbon wrote: > > Bobby, > > I looked at an odd bit of code that I have (not spring security) and it > does the work that you are seeking. I also logged into one of our > applications that does use spring security and it moves through a login > page. > > localhost/app/protected/a > localhost/cas?service=localhost/app/login > localhost/app/login?ticket=ST... > localhost/app/protected/a > > The login 'page' can be strictly server side. > > Ray > > On Fri, 2019-12-13 at 09:35 -0800, Bobby Esfandiari wrote: > > Hi Ray, > > That's the outcome I was hoping for given the docs. I just wasn't sure if > spring-security-cas works the same way since, I didn't see where it would > strip out the ticket in that package's source code. > > I did notice that the response is coming back with a 200 instead of a 302, > which is different than what's outlined in the CAS protocol. Not sure why > this would be though, I don't see anything in the current config that would > do this. > > The GET request's Request URL: > https: > //localhost/?ticket=ST-3-R9wC28zg5JOm-2y0LsP1ELdlu7lSPqXBa6nYgp3fGdmUIkhpowR53vYq-j--oWHMgcad2CBbqEYpsCrE-localhost > And that's where I'm sent to after, with the ticket parameter + value > still present. > > On Thursday, December 12, 2019 at 4:59:34 PM UTC-8, rbon wrote: > > Bobby, > > The ST parameter should be removed by your service (or spring security > cas) when it performs a redirect after validation. The target url should be > the one the user was trying to get to originally. > > Is the request with the ST a 302? > What is the URI of the secured page that you are trying to access? > > Ray > > On Thu, 2019-12-12 at 15:58 -0800, Bobby Esfandiari wrote: > > Hello All, > > As the subject shows, I'm trying to figure out a way to strip the Service > Ticket out of the browser URL after a user has been authenticated and > allowed to access a resource. > Everything seems to be working properly in terms of functionality for the > user, but the Service Ticket is still present. The CAS Protocol Diagram > <https://apereo.github.io/cas/5.2.x/protocol/CAS-Protocol.html> indicates > that it should be stripped off after the protected service validates the > ST, but that's not happening in my case. > > My service is using Spring Boot with *spring-security-cas*, so please let > me know if I'm in the wrong place. I'm not sure how much interplay exists > between Spring and CAS for this client module, but I've seen some very > helpful responses here before so I thought I'd try. > > I even tried to specifically set the Artifact Parameter in the > ServiceProperties bean to "ticket" (even though it should be that by > default), but nothing changed. I've also looked through the > spring-security-cas > <https://github.com/spring-projects/spring-security/tree/master/cas> code > and haven't come across any code that would be removing the ticket. > > This is creating some problems with routing in the front end, so I'd > appreciate some advice on how to do this and send the 302 to the proper URL > (without the ticket parameter). > > Thanks in advance! > > > > > -- > > > Ray Bon > Programmer Analyst > Development Services, University Systems > 2507218831 | CLE 019 | [email protected] > > I respectfully acknowledge that my place of work is located within the > ancestral, traditional and unceded territory of the Songhees, Esquimalt and > WSÁNEĆ Nations. > > -- > > > Ray Bon > Programmer Analyst > Development Services, University Systems > 2507218831 | CLE 019 | [email protected] > > I respectfully acknowledge that my place of work is located within the > ancestral, traditional and unceded territory of the Songhees, Esquimalt and > WSÁNEĆ Nations. > > -- > > Ray Bon > Programmer Analyst > Development Services, University Systems > 2507218831 | CLE 019 | [email protected] <javascript:> > > I respectfully acknowledge that my place of work is located within the > ancestral, traditional and unceded territory of the Songhees, Esquimalt and > WSÁNEĆ Nations. >
-- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/37c1e92a-ee6e-4c15-8ca3-b975c93445ee%40apereo.org.
