Misagh, The two different places which you have identified as 'encoding' perform entirely different kinds of encoding.
response.encodeURL(service) - does NOT have anything to do with %-encoding, it allows the servlet container to embed a session id in the URL in order to track sessions when the client browser does not support cookies. URLEncoder.encode(serviceUrl, "UTF-8") - this does do %-encoding It sounds to me like you are erroneously specifying an already %-encoded value in web.xml, which then gets %-encoded again in code. If you're trying to represent a literal & in an URL in web.xml, it should be written as & not %26. Max. On 19/02/14 03:39, Misagh Moayyed wrote: > 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] > <mailto:[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] > <mailto:[email protected]>] > *Sent:* Tuesday, February 18, 2014 2:17 PM > *To:* [email protected] <mailto:[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] > <mailto:[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/8742ed6f3747047da3aaf2f60591d3d128193c84/cas-client-core/src/main/java/org/jasig/cas/client/util/CommonUtils.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
