Re: Query parameters showing in URL on initial page access

Splash Forums PrettyFaces Users Query parameters showing in URL on initial page access Re: Query parameters showing in URL on initial page access

#22245

clemmonsm
Participant

@Christian – The first rewrite rule does not appear to be causing the redirect. When the rewrite rule is removed, behavior remains the same. I was wrong when I earlier wrote I did not explicitly call sendRedirect(). I do call it once in my prettyFacesRedirect method:

public void prettyFacesRedirect(String mappingId, Object[] params) {
try {

// PrettyFaces redirect
HttpServletRequest request =
(HttpServletRequest)FacesContext.getCurrentInstance().getExternalContext().getRequest();
HttpServletResponse response =
(HttpServletResponse)FacesContext.getCurrentInstance().getExternalContext().getResponse();
PrettyContext context = PrettyContext.getCurrentInstance(request);
PrettyURLBuilder builder = new PrettyURLBuilder();

// set PrettyFaces url-mapping id
UrlMapping mapping = context.getConfig().getMappingById(mappingId);

// IMPORTANT!!! Persist the _adf.ctrl-state parameter across requests so ADF session is not broken.
String targetURL =
context.getContextPath() + builder.build(mapping, true, params) +
"?_adf.ctrl-state=" + request.getParameterValues("_adf.ctrl-state")[0];

targetURL = response.encodeRedirectURL(targetURL);
response.sendRedirect(targetURL);
FacesContext.getCurrentInstance().responseComplete();

} catch (IOException e) {
e.printStackTrace(); // Can't redirect
} catch (Exception e) {
e.printStackTrace();
}
}

…but this method only fires when a non-pretty command link is required, so it does not help pinpoint the origin of the redirect. I do believe that ADF is again the culprit. When I add the following inbound rule:

<rewrite outbound="false" match=".*(^/$|/about-drees/|/finance/|/build-on-your-lot/|/new-homes/|/request-info/|/career/)+.*(?)" processor="siteUtils.PrettyFacesAdfProcessor" redirect="301" />

I can capture the inbound and then I can do the following to wipe the params and add back only the ADF params:

public String processInbound(final HttpServletRequest request, final HttpServletResponse response, final RewriteRule rewrite, final String url) {

// we have a URL with query params

if (request.getParameterValues("_adf.ctrl-state") != null && url.contains("_adf.ctrl-state")) {
// we have access to _adf.ctrl-state & query string includes _adf.ctrl-state, so we can begin rewriting the inbound
String newUrl = url.replaceAll("\?(.*)",""); // remove query string

newUrl = newUrl + "?_adf.ctrl-state=" + request.getParameterValues("_adf.ctrl-state")[0]; // add _adf.ctrl-state back

// add other required ADF params back

if (request.getParameterValues("_afrLoop") != null) {
newUrl = newUrl + "&_afrLoop=" + request.getParameterValues("_afrLoop")[0];
}

if (request.getParameterValues("_afrWindowMode") != null) {
newUrl = newUrl + "&_afrWindowMode=" + request.getParameterValues("_afrWindowMode")[0];
}

if (request.getParameterValues("_afrWindowId") != null) {
newUrl = newUrl + "&_afrWindowId=" + request.getParameterValues("_afrWindowId")[0];
}

return newUrl;
}

return url;
}

…this eliminates the params from the string on the initial request into the app. The problem with this is that my rewrite rule captures all inbound nav requests, including those fired from commandLinks. In these inbound requests, the “url” passed into processInbound is the POST URL (i.e. the page the user is on) and not the GET URL, so the current page ends up reloading. I think I’m on the right track, but I need to find a way to allow commandLink processing to avoid going through the processor I believe. What do you think? Am I on the right track here?

[EDIT – ADDED] Interestingly, all of my commandLink actions call prettyFacesRedirect, the code that contains HttpServletResponse.sendRedirect(). With the above changes, this method is never called, so the sendRedirect() never fires.

@lincoln – Thanks for the note on the regex. You are correct, the ‘.’ does not need escaping. However, it does not appear to prevent ” (at least when testing via RegExr). That said, I really only need to prevent ‘?’ and changing to ^[^?]*$ achieves this.