Right, but the encoding is inevitable in this case because I need to use "service" in the web.xml and I need it to contain parameters that need to be encoded. (something like "&")
I am still confusing by the SessionId added by the EncodeUrl. Would you mind qualifying that? I am seeing a URL encoder attempting to encode the service. From: Scott Battaglia [mailto:[email protected]] Sent: Tuesday, February 18, 2014 3:21 PM To: [email protected] Subject: RE: [cas-dev] Java CAS Client + Svc URL Encoding? EncodeURl shouldn't do anything other than add a sessionID. The issue here seems to be that you pre-encoded your URL in configuration and we assume you don't write your code pre-encoded? On Feb 18, 2014 5:11 PM, "Misagh Moayyed" <[email protected]> wrote: Yes, but that's not behavior I am seeing. Let me elaborate: When the authentication filter kicks in, it will attempt to construct the service url that will be encoded by default. (encodeUrl() here) The encoded service url is then used by the url redirection logic of the client, which in turn gets encoded via URLEncoder.encode(serviceUrl, "UTF-8"). This causes issues if I am using "service" in the configuration that is already encoded (because maybe the url has a character in it like "&") If I turn off the service url encoding at the first step via "encodeServiceUrl=false", it will eventually still be encoded again by the URLEncoder when the client redirects flow to the CAS login endpoint, and subsequently won't be recognized by the registry. I am trying to CASify an application that is super sensitive to url parameters, etc and I cant instruct the client to not touch the service url at all. Does that help? From: Scott Battaglia [mailto:[email protected]] Sent: Tuesday, February 18, 2014 2:17 PM To: [email protected] Subject: Re: [cas-dev] Java CAS Client + Svc URL Encoding? Do you mean the encodeUrl call? encodeUrl is different than URLEncoder.encode (one appends jsession fun and one actually encodes). On Tue, Feb 18, 2014 at 4:06 PM, Misagh Moayyed <[email protected]> wrote: Team, It appears that the java CAS client doubly encodes service urls; in particular the authentication filter. Once when the service url is constructed (which can be controlled via "encodeServiceUrl") and then once when the redirect url to CAS is constructed [1] Since service-url encoding is turned on by default, this causes the final url to be encoded twice. The protocol mentions that service urls are expected to be encoded, though I am not sure if CAS attempts to do any sort of decoding of urls internally? Might be better to modify the behavior of "encodeServiceUrl" to apply to the entire redirect url, only once? And CAS to attempt and decode? Misagh [1] https://github.com/Jasig/java-cas-client/blob/8742ed6f3747047da3aaf2f60591 d3d128193c84/cas-client-core/src/main/java/org/jasig/cas/client/util/Commo nUtils.java#L164 -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
