cas redirect url has special characters like '#'

[Benny Lu]

Hello:

As shown in the pic
The original url is 
http://localhost:8881/login?service=http://localhost:9280/cas/login?ddtab=true%26target%3Dhttp%3A%2F%2Flocalhost%3A9999%2F%23%2Findex

but when the url got redirected the special characters disappears 

I wonder when the special characters disappears and how can i keep the characters remain in my target url


Thanks!
regards

[Ray Bon]

Benny,

Something is amiss with your service URL

service=http://localhost:9280/cas/login...

The service parameter is the URL of the protected application.

Assuming 8881 is your cas server, your url should look like (perhaps with more characters escaped)

http://localhost:8881/cas/login?service=http://localhost:9280/login?ddtab=true%26target%3Dhttp%3A%2F%2Flocalhost%3A9999%2F%23%2Findex

If this is not correct, please explain your arrangement (which is cas server, which is the application you are trying to log in to and what the third service is)?

Ray

On Thu, 2024-01-11 at 15:43 +0800, Benny Lu wrote:

Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information.

[Benny Lu]

Ray,

Thanks for your reply and Forgive my not expressing myself clearly.

My cas server is                                                   http://localhost:8881/login
My cas client which is my protected service is     http://localhost:9280/login/cas
My frontend target url is                                        http://localhost:9999/#/index

So the whole url before url encoding  is http://localhost:8881/login?service=http://localhost:9280/login/cas&target=http://localhost:9999/#/index

But as I have already login into my cas server and I input the above url on the browser  the redirected url became http://localhost:9999 instead of http://localhost:9999/#/index

Apparently the special characters which is  #  is missing and I don't know when the characters is missing.

BTW I have encoded  my url to like  http://localhost:8881/login?service=http://localhost:9280/login/cas%26target%3Dhttp%3A%2F%2Flocalhost%3A9999%2F%23%2Findex.

unfortunately It has not worked.

Benny

Ray Bon <rb...@uvic.ca> 于2024年1月12日周五 02:50写道：

--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/c4545a2eadfc0bb2c1516fefde2a0ce3c2e8fa04.camel%40uvic.ca.

[Pascal Rigaux]

On this subject, see https://github.com/apereo/cas/commit/1d9b5bad50493d6bca62f8e0ca38ca21c66199aa#r116140207 (*) where I explain two possibilities:

* hash not encoded in service : https://cas/login?service=http://localhost/#foo=bar

It happens when user browses http://localhost/#foo=bar and the server-side application redirects to CAS.
The browser is propagating the hash param (typical browser behavior in case of HTTP 302).

* hash encoded in service : https://cas/login?service=http://localhost/%23foo=bar

It happens when the redirect to CAS is browser initiated in javascript,
or when the server-side application forces a hash param
=> nothing to do in browser. location.hash is always empty




(*) here we have CAS >= 6.6.8 but we reverted the modification to have behaviour of CAS < 6.6.8

- action += location.search + encodeURIComponent(location.hash);
+ action += location.search + location.hash;

[Frovarp, Richard]

[richard.frovarp]

No idea why my reply got posted as completely empty.

The '#' is the URL fragment chunk of the URL. It is very unique and odd in how it works. The browser will not send it to the remote host. So you have to ensure that it is URL encoded on its way to CAS. If it isn't, the browser will likely interpret it as a fragment for the login page. Then you need to see what happens to it along the way. I would suggest using the network logger in the dev tools on your browser. From there you should be able to see what is happening to it. You should be able to see the fragment be present in the Location header from the redirect URL coming out of CAS back to your service. If it isn't in the Location header, then it got lost going to / in CAS. If it is in the Location header, then it is getting lost after CAS and in your app / browser.

Doing testing against CAS 6.6, so long as I URL encode in the service, it remains in the Location header going back to the service.