Idea Details

Need to have agent correctly encode/decode hashtag in URL

Last activity 06-13-2019 09:42 AM
SamatBoA's profile image
07-22-2016 12:07 PM


We have an application that contains the hashtag character in the URL:

 

http://our-site/path1/path2/#/path3/destination

 

when redirected to the login page, the browser is correctly handling the hashtag but when the agent sends the user back to the target, it does not decode it so the URL becomes invalid.

 

We opened a support case and was told that hashtag was not in the list of special characters that the agent could handle and that an enhancement request was necessary.

 

Our immediate need is for web agent 12.51 cr7 enhancement.


Comments

10-10-2016 05:04 PM

Hi Chris,

 

Very detailed and excellent response.

This is exactly how this should be handled on the client side. 

 

Thanks for sharing.

 

Cheers,

Ujwol

10-10-2016 02:40 PM

This is being handled as a defect, so I'm marking this idea as 'not planned'. It will be resolved in upcoming CR's for both 12.51 and 12.52, so stay tuned.

 

Thanks, Rob

08-05-2016 12:22 PM

We added a little javascript to our login FCC files to handle anchor fragments. Problem is that anchor-fragment+string is not sent server-side (which I'm assuming is where it's pulling the actual target from), it's only client-side unless encoded.

 

So what we did since the browser will append it when sending it over to log in, we encode it at the fcc. For example "/app/#/blah/blah2" becomes "/app/%23/blah/blah2" which then gets posted as the target.

 

At that point the agent server-side will pick up that the target is actually someapp.com/app/%23/blah/blah2

 

YMMV depending on your setup. But works for us since we pass user through a redirect.aspx and on the final return to the application the fragment is decoded again so the app will be able to parse it properly.

08-04-2016 09:01 AM

So just to make sure nothing is missed, we did try to set the parameter "Localization=No".  It made no difference for us.

 

Thanks

07-22-2016 12:21 PM

Thanks for the quick response.  This was never mentioned in our support case and they were very clear that this is an enhancement request.  The tech not you reference is for 12.52.  We are on 12.51.  I'm not sure adding this aco parameter would help and then I'd also have to figure out what other things it might break.

07-22-2016 12:13 PM

Hi,

 

Could you please give try with below ACO Parameter  and let us know the results that resolves the issue or not?

 

Set the ACO Parameter:

Localization = No.

Refer below link:

http://www.ca.com/us/support/ca-support-online/product-content/knowledgebase-articles/tec1921813.aspx 

 

Thanks,

Santosh