I have an ugly use case where the url redirections get a little deep. If a user is not logged in and accesses a secured resource at https://cms/secure/resource, they get redirected to https://cms/login?ret=secure%2fresource. 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, so https://account/?ret=https%3a%2f%2fcms%2flogin%3fret%3dsecure%252fresource.
https://account/ uses the dotnetcasclient 1.0.2 httpmodule (I've also reproduced the problem with the master branch source code). Since the user is not authenticated with https://account/, they get redirected to my CAS site with: https://cas/login?service=https%3a%2f%2faccount%2f%3fret%3dhttps%3a%2f%2fcms%2flogin%3fret%3dsecure%252fresource The service querystring parameter then decodes to: https://account/?ret=https://cms/login?ret=secure%2fresource. This causes me to get service ticket validation errors ERROR org.jasig.cas.CentralAuthenticationServiceImpl - ServiceTicket [ST-blah] with service [https://account/?ret=https://cms/login?ret=secure%2fresource] does not match supplied service [https://account/?ret=https://cms/login?ret=secure/resource] I believe the problem is in UrlUtil in CostructServiceUrl on line 101 (and probably in CostructProxyCallbackUrl on line 188) on the master branch and the 1.0.2 branch. The code says ub.QueryItems.Add(request.QueryString). According to the documentation (http://msdn.microsoft.com/en-us/library/system.web.httprequest.querystring(v=vs.110).aspx ) HttpRequest.QueryString values are automatically decoded. Debugging seems to verify this. They seem to lose their encoding when going from request.QueryString to ub.QueryItems. I replaced this line of code with: foreach (var qs in request.QueryString.AllKeys) ub.QueryItems.Add(qs, HttpUtility.UrlEncode(request.QueryString[qs])); This appeared to fix the problems I was having, and doesn't seem to cause any other issues. Before I deploy this change to production I wanted to verify if this seems correct. I would hate to naively make a change to the source code thinking I was fixing a bug and wind up introducing a security vulnerability because things were done the way they were done for a reason and I just lacked foresight. Thanks. Also, I manually edited some of these urls in the interest of brevity, so if it seems like a character is missing in the urls it's probably my fault. -- 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
