I’m a little confused here. I apologize if I misunderstood your response or if I was unclear. I know the urls are ugly but the problem only comes up when the nesting gets a little deep.
My original redirect url was https://account/?ret=https%3a%2f%2fcms%2flogin%3fret%3dsecure%252fresource, I’m not seeing how that’s different than what you suggested. I think the problem I was running into was after that. The login redirect url generated by dotnetcasclient going to CAS from account was https://cas/login?service=https%3a%2f%2faccount%2f%3fret%3dhttps%3a%2f%2fcms%2flogin%3fret%3dsecure%252fresource. That service querystring parameter, when decoded, is the malformed url you mentioned and I believe is the crux of the problem, but its generated by dotnetcasclient on the account site, not by the original site. Near as I can tell, the problem is dotnetcasclient is getting: https://account/?ret=https%3a%2f%2fcms%2flogin%3fret%3dsecure%252fresource and is redirecting from that request to: https://cas/login?service=https%3a%2f%2faccount%2f%3fret%3dhttps%3a%2f%2fcms%2flogin%3fret%3dsecure%252fresource which seems to not be properly encoded, as you mentioned. I think it SHOULD be: https://cas/login?service=https%3a%2f%2faccount%2f%3fret%3dhttps%253a%252f%252fcms%252flogin%253fret%253dsecure%25252fresource The problem seems to be in UrlUtil when it does ub.QueryItems.Add(request.QueryString). This has a hidden decoding step that happens when accessing request.QueryString, but is not encoded when it is put back together, causing a level of encoding to be lost. Regarding the changes to EnhancedUriBuilder, there was one compile time problem regarding the split. Instead of item.Split(‘=’, 2) you have to use item.Split(new char[] { ‘=’, 2 }). It is valid to use the former style when you don’t have a number, because there is a function signature with params when you just have a char array, but that doesn’t apply to the other overloads. After making that change, when I ran it, I provided the url: https://account/?ret=https%3a%2f%2fcms%2flogin%3fret%3dsecure%252fresource and got redirected to https://cas/login?service=https%253a%252f%252faccount%252f%253fret%253dhttps%2525253a%2525252f%2525252fcms%2525252flogin%2525253fret%2525253dsecure%252525252fresource This resulted in me getting an “Application Not Authorized to Use CAS” error message, which I think is happening because it is actually encoding one level too much. I did not debug the changes so I cannot say for certain why it was doing that, but I think the decode and the encode you added are unnecessary. If I removed both of those everything worked. This has the effect of preserving whatever level of encoding was provided to it in the first place. From: Scott [mailto:scottt...@gmail.com] Sent: Wednesday, December 17, 2014 1:12 AM To: cas-dev@lists.jasig.org Subject: Re: [cas-dev] dotnetcasclient nested url encoding in querystring "To authenticate with https://cms/ they need to have setup their account at a different site, so they get redirected there with a return url pointing back to the original site, sohttps://account/?ret=https%3a%2f%2fcms%2flogin%3fret%3dsecure%252fresource"; I think this redirect might be a problem. That literally UrlDecodes to "https://account/?ret=https://cms/login?ret=secure%2fresource"; which is invalid. Functionally, think of the redirect URL as AccountUrl(CmsUrl(OriginUrl)). OriginUrl should be double-encoded and CmsUrl should be encoded once. The redirect to your account site should look like this: https://account/?ret=https%3a%2f%2fcms%2flogin%3fret%3dsecure%252fresource -- You are currently subscribed to cas-dev@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-dev
