I'm trying to implement custom error messages on the SPS. Whenever I encounter a WebAgentException, I want to redirect to a jsp page, say error.jsp
I make this change in spsErrorMessages.properties in tomcat/conf and have the error.jsp URL corresponding to WebAgentException error.
It is redirecting correctly to the error.jsp.
However, I want to retrieve the original URL that the user was going to that generated this WebAgentException including the querystring params. No request header or attribute seems to contain this information. Anyone has any ideas?
If I understood correctly, you already configured your SPS to enable custom error messages, and modified your tomcat/properties/spsErrorMessages.properties file to send WebAgentException errors to your custom error.jsp page URL, instead the text error message, and now you would like to include in the error page information about the original URL and querystring, this is correct?
I think you could try to do the following from the error.jsp code, as the properties file cannot contain dynamic data or code:
1) Use the request.getHeader("referer"), just in case it is still there.
2) Use a custom field (header or hidden form field) containing that information, so it can be retrieved from error.jsp.
Albert_Fernandez Thank you for your reply.
I tried number 1 already. No referer header is set. It always returns null.
How would I do number 2? Where can I set this header? Because the redirect is done by tomcat itself. It doesn't hit a jsp or something in the middle for me to set the value.
You could set that header before being redirected, at the origin; I also mentioned a hidden field in case it is coming from a form page, as it could be easier. As you are being redirected after doing some operations (where you set querystring, and other variables at the URL you want to retrieve), you could set them prior to redirection.
Albert_Fernandez Hmm. Here is what is happening.
I have one website that uses User Directory 1 for authentication
The second website is a SAML partnership. The user could come in with either SPID=App1 or SPID=App2. These two partnerships use User Directory 2.
What I notice is when user comes in to the SPS with a SMSESSION cookie for User Directory 1, the SPS throws a web agent error. So all the user does is open the URL for the partnership, it hits the SPS tomcat container, and because I have the redirect to error.jsp in the SPSErrorMessage.properties, it redirects there. There are no points in between where I can set a custom header or a hidden variable. When Tomcat does this redirect, it strips off the query string. I only get the URL upto /affwebservices/public/saml2sso. So when I get to my error page, I don't know where to redirect the user to. I'm killing the SMSESSION when the user gets to error.jsp. but right now I don't know where to redirect the user so that I can present him with a login page instead of an error. Does that make sense?
I see multiple issues here.
Firstly, the federation journey does not look right to me.
When request arrives into /affwebservices/public/saml2sso with a SMSESSION which is invalid (because of UD2 latched to partnerships); I'd expect affwebservices to trigger the Authentication URL defined within the partnership and redirect the user to Authentication URL. Authentication URL is a protected page e.g. /affwebservices/redirectjsp/redirect.jsp and thus user would get a login page to login again.
Secondly, Why would you kill a valid SMSESSION. SMSession attached to UD1 is still a valid SMSESSION for that part of the journey. Why would you want the user to login again on the UD1 part of the journey.
I think we need to start planning user experience design more carefully rather than built solutions like this.
I am kind of lost in the above design. But I'll try to answer the core request of how you may try to get the TARGET. But these are options which are available after the WebAgent processes the request. On SPS WebAgent runs as Java code within Tomcat.
Check for a SiteMinder Header SM_LOCATION, this is normally populated with the TARGET URI.
However ---> 00338955: SM_USER and SM_LOCATION not working in configured Responses
In the Policy Server we have Variable Responses.
Variables Overview - CA Single Sign-On - 12.52 SP2 - CA Technologies Documentation
However ---> 00300147: Variables Request Context