[cas-dev] Java CAS Client + Svc URL Encoding?
Misagh Moayyed
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
--
You are currently subscribed to cas...@lists.jasig.org as: jasig-cas-dev+...@googlegroups.com
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
Scott Battaglia
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
--
You are currently subscribed to cas...@lists.jasig.org as: scott.b...@gmail.com
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
Misagh Moayyed
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?
--
You are currently subscribed to cas...@lists.jasig.org as: mmoa...@unicon.net
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
Scott Battaglia
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?
Misagh Moayyed
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.
Robert Oschwald
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?
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
--
You are currently subscribed to cas...@lists.jasig.org as: roberto...@googlemail.com
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
Max Bowsher
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.
>
>
>
> *Sent:* Tuesday, February 18, 2014 3:21 PM
> *To:* cas...@lists.jasig.org
> *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" <mmoa...@unicon.net
>
> 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?
>
>
>
> <mailto:scott.b...@gmail.com>]
> *Sent:* Tuesday, February 18, 2014 2:17 PM
> *To:* cas...@lists.jasig.org <mailto:cas...@lists.jasig.org>
> *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 <mmoa...@unicon.net
> <mailto:mmoa...@unicon.net>> 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
--
Misagh Moayyed
all.
Nonetheless, while that substitution works for "&" I am not sure if that
would still apply over service urls that are auto-encoded and perhaps
incorrectly? perhaps a setting to turn off encoding completely? and as
well, I think the setting name "encodeServiceUrl" is actually kind of
misleading because that seems to indicate that if turned off, it will
actually turn off "utf-8 encoding".