(Vanity) URLs result in white page (dotCMS 5.2.6)

56 views
Skip to first unread message
Assigned to wi...@dotcms.com by danny.gl...@isaac.nl

Danny Gloudemans

unread,
May 20, 2020, 5:01:27 AM5/20/20
to dotCMS User Group
Hi,

In our dotCMS 5.2.6 we have an issue that multiple times a week we have an issue that when we hit an URL it will result in a white page, first we thought this is an issue with the Vanity URLs as most of the times we saw this issue with vanity URLs, but we also see it when we hit www.domain.com/login/ which should resolve in www.domain.com/login/index.html.

Once we clear the cache the issue is resolved. Unfortunately we aren't able to find the root cause and we also don't know how to reproduce it, but somehow it should be something cache related.

Are you aware of a similar issue or is there may be an hotfix available that we can deploy?

Thank you

Bart Plasmans

unread,
May 20, 2020, 6:09:36 AM5/20/20
to dotCMS User Group

Hi all, 

in the dotcms.log we saw also this error, there was a security scan on our domain, which seems to trigger the behaviour described by Danny.

Is is possible that when a request is done which has an invalid URI like the one below, the vanity url gets broken?

In the dotCMS 5.2.6 code we see that the method which call VanityUrlUtil.isValidRegex() is called by the CachedVanityUrl.init() and sets the CachedVanityUrl.regex to an empty String when the given regex is invalid:

Then when this empty pattern and regex are updated in the cache the vaniturl will not be working anymore?

Or are we looking in the wrong direction?


com.dotcms.util.VanityUrlUtil.java

  /**
     * Validates if the regular expression is valid
     *
     * @param regex Regular expression string
     * @return true if is a valid pattern, false if not
     */
    public static boolean isValidRegex(final String regex) {
        boolean isValid = false;
        try {
            Pattern.compile(regex);
            isValid = true;
        } catch (PatternSyntaxException e) {
            Logger.error(VanityUrlUtil.class,
                    "Error cause by invalid Pattern syntax. URI:" + regex, e);
        }
        return isValid;
    } // isValidRegex.


com.dotcms.vanityurl.model. CachedVanityUrl.java:
   * Generate a cached Vanity URL object
     *
     * @param vanityUrl The vanityurl Url to cache
     */
    public CachedVanityUrl(VanityUrl vanityUrl) {
        //if the VanityUrl URI is not a valid regex
        String regex = VanityUrlUtil.isValidRegex(vanityUrl.getURI()) ? vanityUrl.getURI()
                : StringPool.BLANK;
        this.pattern = Pattern.compile(regex, Pattern.CASE_INSENSITIVE);
        this.vanityUrlId = vanityUrl.getIdentifier();
        this.url = vanityUrl.getURI();
        this.languageId = vanityUrl.getLanguageId();
        this.siteId = vanityUrl.getSite();
        this.forwardTo = vanityUrl.getForwardTo();
        this.response = vanityUrl.getAction();
        this.order    = vanityUrl.getOrder();
    }

The loglines


[19/05/20 19:32:12:222 BST] (303744) ERROR util.VanityUrlUtil: Error cause by invalid Pattern syntax. URI:/"+"A".concat(70-3).concat(22*4).concat(102).concat(66).concat(111).concat(79)+(require"socket"
java.util.regex.PatternSyntaxException: Unclosed group near index 95
/"+"A".concat(70-3).concat(22*4).concat(102).concat(66).concat(111).concat(79)+(require"socket"
at java.util.regex.Pattern.error(Pattern.java:1969) ~[?:1.8.0_242]
at java.util.regex.Pattern.accept(Pattern.java:1819) ~[?:1.8.0_242]
at java.util.regex.Pattern.group0(Pattern.java:2922) ~[?:1.8.0_242]
at java.util.regex.Pattern.sequence(Pattern.java:2065) ~[?:1.8.0_242]
at java.util.regex.Pattern.expr(Pattern.java:2010) ~[?:1.8.0_242]
at java.util.regex.Pattern.compile(Pattern.java:1702) ~[?:1.8.0_242]
at java.util.regex.Pattern.<init>(Pattern.java:1352) ~[?:1.8.0_242]
at java.util.regex.Pattern.compile(Pattern.java:1028) ~[?:1.8.0_242]
at com.dotcms.util.VanityUrlUtil.isValidRegex(VanityUrlUtil.java:35) ~[dotcms_5.2.6_b69c38c.jar:?]
at com.dotcms.vanityurl.model.CachedVanityUrl.<init>(CachedVanityUrl.java:35) ~[dotcms_5.2.6_b69c38c.jar:?]
at com.dotcms.cache.VanityUrlCacheImpl.update(VanityUrlCacheImpl.java:253) ~[dotcms_5.2.6_b69c38c.jar:?]
at com.dotcms.services.VanityUrlServices.updateCache(VanityUrlServices.java:117) ~[dotcms_5.2.6_b69c38c.jar:?]
at com.dotcms.vanityurl.business.VanityUrlAPIImpl.add404URIToCache(VanityUrlAPIImpl.java:307) ~[dotcms_5.2.6_b69c38c.jar:?]
at com.dotcms.vanityurl.business.VanityUrlAPIImpl.getFallback(VanityUrlAPIImpl.java:382) ~[dotcms_5.2.6_b69c38c.jar:?]
at com.dotcms.vanityurl.business.VanityUrlAPIImpl.isVanityUrl_aroundBody4(VanityUrlAPIImpl.java:216) ~[dotcms_5.2.6_b69c38c.jar:?]
at com.dotcms.vanityurl.business.VanityUrlAPIImpl$AjcClosure5.run(VanityUrlAPIImpl.java:1) ~[dotcms_5.2.6_b69c38c.jar:?]
at org.aspectj.runtime.reflect.JoinPointImpl.proceed(JoinPointImpl.java:149) ~[aspectjrt-1.8.10.jar:?]
at com.dotcms.aspects.aspectj.AspectJDelegateMethodInvocation.proceed(AspectJDelegateMethodInvocation.java:42) ~[dotcms_5.2.6_b69c38c.jar:?]
at com.dotcms.aspects.interceptors.CloseDBIfOpenedMethodInterceptor.invoke(CloseDBIfOpenedMethodInterceptor.java:29) ~[dotcms_5.2.6_b69c38c.jar:?]
at com.dotcms.aspects.aspectj.CloseDBIfOpenedAspect.invoke(CloseDBIfOpenedAspect.java:41) ~[dotcms_5.2.6_b69c38c.jar:?]
at com.dotcms.vanityurl.business.VanityUrlAPIImpl.isVanityUrl(VanityUrlAPIImpl.java:195) ~[dotcms_5.2.6_b69c38c.jar:?]
at com.dotmarketing.filters.CMSUrlUtil.isVanityUrl(CMSUrlUtil.java:306) ~[dotcms_5.2.6_b69c38c.jar:?]

greetings Bart

Danny Gloudemans

unread,
Jun 8, 2020, 9:34:46 AM6/8/20
to dotCMS User Group
This is exactly the same issue as mentioned in
- https://github.com/dotCMS/core/issues/18364

- https://github.com/dotCMS/core/issues/17278

 

However it seems to be that the merge request will add the vanity URLs in a timed cache and flush it automatically. However that's not really a fix but a workaround as the issue can still happen for the configured cache time: https://github.com/dotCMS/core/pull/18378

Will Ezell

unread,
Jun 8, 2020, 10:03:49 AM6/8/20
to dot...@googlegroups.com
The current vanity urls cache loading pattern is definitely sub-par and we have a clean room re-implementation in code review right now. 


We'd expect it to be released within the next few releases, perhaps in a month or so.  In the meantime, on the pull request you referenced, the change that apparently resolves the issue is here, where the vanity is reloaded from the db if nothing is found in the cache.

Maybe that just shortens the window of time the code is broken. It could possibility be coupled with a fix for the bad regex Bart mentions in this thread.   





--
http://dotcms.com - Open Source Java Content Management
---
You received this message because you are subscribed to the Google Groups "dotCMS User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dotcms+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dotcms/9b089aa7-0a91-4631-9113-338cc6afe21eo%40googlegroups.com.


--



382 NE 191st St #92150
Miami, Florida 33179-3899
Main: 
305-900-2001 | Direct: 978.294.9429

   

--
http://dotcms.com - Open Source Java Content Management
---
You received this message because you are subscribed to the Google Groups "dotCMS User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dotcms+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dotcms/9b089aa7-0a91-4631-9113-338cc6afe21eo%40googlegroups.com.


--



382 NE 191st St #92150
Miami, Florida 33179-3899
Main: 
305-900-2001 | Direct: 978.294.9429

   
Reply all
Reply to author
Forward
0 new messages