0

i am working on the webseal authentication, i have created the junction with name /dgcontroller/services/dgsecure i have craeted the rest api with same name as junction.

Here is the rest api

@RequestMapping(value = "/dgsecure", method = RequestMethod.GET)
    public void handleRedirectionForDgsecure(HttpServletRequest request, HttpServletResponse response)throws IOException, DgException {
        try {
            System.out.println("inside my service");

            String userIdentifierWebSEAL = "";
            
            String redirectionURL = "";

            userIdentifierWebSEAL = request.getHeader("iv-user");
            
            redirectionURL = "http://192.168.2.80:10181/dgadmin/login.html";
                        
            response.sendRedirect(redirectionURL);

        } catch (Exception e) {
            logger.error("Error in webseal handleRedirectionForDgsecure Rest API", e);
            response.sendRedirect("/dgcontroller/error.jsp");
        }
    }

the iv-user is fetched successfully but after that it will not rediect to given redirectionURL. can anyone please help me to resolve this issue. Thanks

Jony Mittal
  • 151
  • 6
  • 23

1 Answers1

0

It is probable the absolute URL you are trying to redirect to does not match the junction server:port configuration. Per documentation, if it matches, WebSEAL should remove the server:port and rewrite to a relative URL. Best practice would be to use a relative URL in your application. If you trying to redirect AWAY from the WebSEAL hostname to a different host all-together, WebSEAL may be rewriting the URL when you don't want it to, in which case you need to disable that functionality.

Take a look at the documentation on modifying URLs. There are several things that could be of use if my first suggestion does not work. Between absolute URL rewriting within scripts, to the JMT (Junction Mapping Table), to scripting support using junction cookies, there are various ways to achieve the rewrite.

Now, for figuring out what is going on. The best thing to do is to perform a trace using pdweb.debug at level 9. You can enable that via the LMI if on the virtual appliances (best method, prevents sending the log files to places where you cannot clean them up), or using the pdadmin tool and the server task command. The pdweb.debug will give you the header trace (not the HTTP body content) and will show you the location header for the redirect. If that is not enough, then enable a pdweb.snoop trace at level 9 which will capture the HTTP body in the request and responses to and from the client, webseal, and backend application server. Enabling both the debug and snoop traces is a sure way to always figure out issues regarding redirection rewrites. If you can't stand to read through the snoop manually, L2 has some support utilities in Perl and HTML to help.

Matt
  • 731
  • 6
  • 7