RE: 302 to 301 redirect status

Developer Š, modified 5 Years ago. New Member Posts: 4 Join Date: 7/14/20 Recent Posts
Hello!
We would like to get some help with changing the default redirect status(302) to 301.

Liferay version:  6.2.0-ga1
Java version: 1.7.0_79


What we explored so far is this:
1.  Wrapping the response to a custom object via filter and overriding the sendRedirect method
public class ServletResponseWrapperFilter implements Filter {

    private static final Logger LOG = LoggerFactory.getLogger(ServletResponseWrapperFilter.class);

    @Override
    public void init(FilterConfig filterConfig) throws ServletException {
    }

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        ResponseStatusChangerWrapper wrap = new ResponseStatusChangerWrapper((HttpServletResponse) response);
        chain.doFilter(request, wrap);
    }

    @Override
    public void destroy() {
    }
}

where ResponseStatusChangerWrapper is 

public class ResponseStatusChangerWrapper extends HttpServletResponseWrapper {

    public ResponseStatusChangerWrapper(HttpServletResponse httpServletResponse) {
        super(httpServletResponse);
    }

    @Override
    public void sendRedirect(String location) {
        this.setStatus(301);
        this.setHeader("Location", location);
    }

}
and registering the filter right after the Absolute Redirects Filter
<servlet-filter>
   <servlet-filter-name>Response Status Wrapper Filter</servlet-filter-name>
   <servlet-filter-impl>...ServletResponseWrapperFilter</servlet-filter-impl>
</servlet-filter>
<servlet-filter-mapping>
   <servlet-filter-name>Response Status Wrapper Filter</servlet-filter-name>
   <after-filter>Absolute Redirects Filter</after-filter>
   <url-pattern>/*</url-pattern>
   <dispatcher>REQUEST</dispatcher>
   <dispatcher>FORWARD</dispatcher>
</servlet-filter-mapping>
2. Using the ext plugin

Created from archetype(we are using maven)
<groupid>com.liferay.maven.archetypes</groupid>
<artifactid>liferay-ext-archetype</artifactid>
<version>6.2.0-ga1</version>
Where we altered the AbsoluteRedirectsResponse 
via the plugin-impl module
package com.liferay.portal.servlet.filters.absoluteredirects;

import com.liferay.portal.util.PortalUtil;
import java.io.IOException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpServletResponseWrapper;

public class AbsoluteRedirectsResponse extends HttpServletResponseWrapper {
    private HttpServletRequest _request;

    public AbsoluteRedirectsResponse(HttpServletRequest request, HttpServletResponse response) {
        super(response);
        this._request = request;
    }

    public void sendRedirect(String redirect) throws IOException {
        redirect = PortalUtil.getAbsoluteURL(this._request, redirect);
        this._request.setAttribute(AbsoluteRedirectsResponse.class.getName(), redirect);
        // super.sendRedirect(redirect);
        this.setStatus(301);
        this.setHeader("Location", redirect);
    }
}

While #1 gets the job done we are not sure how safe it is. From what we have seen, the initial sendRedirect  is sent from com.liferay.portal.kernel.servlet.MetaInfoCacheServletResponse
public void sendRedirect(String location) throws IOException {
    if (this.isCommitted()) {
        throw new IllegalStateException("Send redirect after commit");
    } else {
        this.resetBuffer(true);
        this.setStatus(302);
        this._metaData._location = location;
        this._committed = true;
        super.sendRedirect(location);
    }
}
With #2,  we do not like the maintenance and extra complexity for removal/update and If it is possible, we would like to avoid it.
We would greatly appreciate any help.
thumbnail
Olaf Kock, modified 5 Years ago. Liferay Legend Posts: 6441 Join Date: 9/23/08 Recent Posts
Developer Š:

Hello!We would like to get some help with changing the default redirect status(302) to 301.Liferay version:  6.2.0-ga1
...  we do not like the maintenance and extra complexity for removal/update and If it is possible, we would like to avoid it.

For redirects, check https://liferay.dev/blogs/-/blogs/permanent-google-love

For not wanting to upgrade: I understand that it's comfortable not to do it, but that might not be for long. Insisting on running unchanged server software that has been published in 2013 and has seen several updates since then isn't the smartest choice. Check https://liferay.dev/blogs/-/blogs/security-patches-for-liferay-portal-6-2-7-0-and-7-1
thumbnail
Christoph Rabel, modified 5 Years ago. Liferay Legend Posts: 1555 Join Date: 9/24/09 Recent Posts
On top of what Olaf said:
Do you have a reverse proxy? If no, you really should add one to your setup.
You can do the redirects there, without code change to Liferay AND you can block the requests to /api/jsonws (second link in Olafs post). While you should upgrade in any case, installing an configuring a reverse proxy isn't a lot of work and you can probably do it immediately, while an upgrade/patching needs some planning.
Developer Š, modified 5 Years ago. New Member Posts: 4 Join Date: 7/14/20 Recent Posts
Yes, we do have a reverse proxy and already use it for some redirects. The problem is that the number of these pages is not that low. We agree that none of the above stated "solutions" are good and that we should leave the default functionality.
thumbnail
Olaf Kock, modified 5 Years ago. Liferay Legend Posts: 6441 Join Date: 9/23/08 Recent Posts
Developer Š:

Yes, we do have a reverse proxy and already use it for some redirects. The problem is that the number of these pages is not that low.

Even more: Long lists of redirects are great to manage in a single text file (reverse proxy configuration) rather than with 6-fold amount of mouse clicks plus getting an overview over what you did and checking if you caught all.

We agree that none of the above stated "solutions" are good and that we should leave the default functionality.


If this refers to the updates: Indeed. Think of it this way: You stated that you wouldn't like to go through the effort of an upgrade. Note that an upgrade would be largely at your own schedule (if done in time). In case someone utilizes a security vulnerability on your outdated system (and there are automated attacks out there currently), you'd have a lot of effort to clean up your system on their schedule. Not to mention unidentified collateral damage. 
Developer Š, modified 5 Years ago. New Member Posts: 4 Join Date: 7/14/20 Recent Posts
You probably misunderstood(or we worded it poorly) when we wrote:


With #2, we do not like the maintenance and extra complexity for removal/update and If it is possible, we would like to avoid it.

We are mentioning the  ext plugin under the second point(2. Using the ext plugin) and the process it involves when removing/updating the changes of plugin itself + maintaining it in future.

We would like to see the upgrade take place, sadly it probably will not.