JSF Default Page (Resolved: Beware of 301-Caches of Browsers)

Question

We have a JSF-Application running. Ever since the default landing page was defined as /pages/dashboard.xhtml.

Shiro is catching the request, showing the login-page, and after successfull authentication, our servlet retrieves the stored request from shiro and forwards the user to that page.

So, every other kind of deeplink is possible ofc.

Now, we wanted to allow the user to define his default landing page. System is setup, if shiro does not provide a stored request, our application forwards the user to his defined landing-page.

(Other deeplinks still working ofc.)

If the user now calls https://example.com/app/login.xhtml directly, he is forwarded to his custom landing page. (after login)

The only thing that is strange - and drives me crazy by now: If a user only requests https://example.com/app - the first request hiting shiro is the link to the old dashboard again: https://example.com/app/pages/dashboard.xhtml

In the web.xml we mapped the servlet to *.xhtml

<servlet-mapping>
    <servlet-name>Faces Servlet</servlet-name>
    <url-pattern>*.xhtml</url-pattern>
  </servlet-mapping>

and defined the welcome-file-list as

  <welcome-file-list>
    <welcome-file>index.xhtml</welcome-file>
  </welcome-file-list>

where the file exists, and only contains

<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Refresh" content="0; URL=login.xhtml">
</head>
</html>

It seems like the file is never invoked. When removing the redirect, calling https://example.com/app immediately leads to https://example.com/app/login.xhtml - but shiro logs an access-request to https://example.com/app/pages/dashboard.xhtml, leading to a "stored request" then.

(Which we don't like, cause that szenario should use the users default landing page)

It's wildfly 8.1, I'm totally out of ideas where this "request" is triggered. (Obviously it's not a default page) - but it's the first request hitting our url-rewrite filter, so it musst happen before the application is invoked...

But where?

dognose · Accepted Answer · 2017-10-14T22:53:22.017

Awkward...

<meta http-equiv="Refresh" content="0; URL=login.xhtml">

is considered a 301 (Moved Permanently) and chrome is caching this redirect even if dev-tools (with cache disabled) are open. Only clearing the cache manually solves this.

Thus, chrome never invoked the (new) index.xhtml, cause prior to the change it was <meta http-equiv="Refresh" content="0; URL=/pages/dashboard.xhtml">

So, for the time that cache might be alive on any client the only option seems to be: considering a stored request to the old dashboard as no stored request...

Update: It seems like browser might cache 301s for an infinite amount of time: How long do browsers cache HTTP 301s?

Means: For now I need to ignore this stored request. If a user sets it up as custom landing page, this will be handled later.

        FacesContext context = FacesContext.getCurrentInstance();
        ServletRequest request = (ServletRequest) context.getExternalContext().getRequest();
        SavedRequest savedRequest = WebUtils.getAndClearSavedRequest(request);

        if ((savedRequest != null) && (savedRequest.getRequestUrl() != null)) {
            /**
             * Browser might cache the 301 redirect from index.xhtml
             * for an infinite amount of time. So, as of now, we can only consider
             * the old "dashboard" to be an "unstored request".
             *
             */
            if (!savedRequest.getRequestUrl().contains("/pages/dashboard.xhtml")) {
                return savedRequest.getRequestUrl();
            }
        }

        // No stored request. Get Custom Landingpage.
        String defaultLandingPage = this.userValueService.getValue(UserValueKey.defaultLandingPage);
        return ProjectStageConfiguration.getInstance().getWebContextPath() + defaultLandingPage;

JSF Default Page (Resolved: Beware of 301-Caches of Browsers)

1 Answers1