Hi, In fact, the service parameter should be handled properly. It it saved before the redirection to the external identity provider and restored after the successful delegated authentication. So you shouldn't have any problem with keeping your service.
It should be properly handled in case of an error as well and if it doesn't, it's somehow a bug. Can you copy/paste a stacktrace to see what kind of error breaks the flow? Thanks. Best regards, Jérôme LELEU Founder of CAS in the cloud: www.casinthecloud.com | Twitter: @leleuj Chairman of CAS: www.jasig.org/cas | Creator of pac4j: www.pac4j.org 2014-06-13 15:03 GMT+02:00 Jonathan <jhs...@mit.edu>: > With the CAS OAuth Support 3.5.2 workflow, when we encounter an > authentication error the exception handling code and web flow brings the > user back to a login page. > > But in our case the specific login page depends on what the service > parameter specified in the HTTP request URL. e.g. https:// > ....?service=http://.../j_spring_cas_security_check"; > > With the OAuth workflow, the service parameter is missing from the > callback url used by the oauth server to call back to the oauth client > application. In this case, when we have an authentication error, CAS uses > a default theme for the login page instead of an application specific theme > that we want. > > Has anyone else encountered this issue? Is this a common use case? What > is the recommended way to handle this scenario? > > Thank you. > > -- > You are currently subscribed to cas-user@lists.jasig.org as: > lel...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
