Upgrade from 4.0.1 to 5.1.6 - Vanity URLs that Forward to Url Mapped Content Items Return 404 Errors - Others (Redirect Temporary and Permanent Work Well)

[Alex]

Hi,

After we upgraded to 5.1.6 from 4.01 everything works great except the Vanity URLs that have the forward directive to a URLMapContent item return a 404.  If the vanity url forward to an HTML page, it works well.

Does anyone know how to fix this or Vanity URLs no longer can handle forwards to UrlMapContents?  I can reproduce this exactly in the demo too.

It seems this was already reported but it is classified as "wontfix" https://github.com/dotCMS/core/issues/16684.  If this will not be fixed, does anyone know a way around to fix this issue.

The documentation recommends to use vanity urls for simple forward and redirects instead of the UrlRewrite Tuckey filter.  

Thanks for your help!

Alex

Here is a curl:

curl -I http://test.server.com/jaco

HTTP/1.1 404 Not Found

Server: nginx

Content-Type: text/html;charset=UTF-8

Connection: keep-alive

Vary: Accept-Encoding

Set-Cookie: JSESSIONID=8FFAXXXXXG66374F8E7122359654564; Path=/; HttpOnly

Set-Cookie: dmid=5ad44386-e559-4bf8-8a11-656f7e116adc; Max-Age=153792000; Expires=Mon, 26-Aug-2024 18:11:39 GMT; Path=/; HttpOnly

Date: Sat, 12 Oct 2019 18:11:39 GMT

X-Page-Speed: 1.13.35.2-0

Cache-Control: max-age=0, no-cache

[Alex]

Hi,

Is the forward directive behavior to urlmap content going to be deprecated? It does not work either on dotCMS 5.2.0

I created, complied, loaded and started successfully a urlrewrite tuckey plugin forwarding to a urlmap.

NormalRule forwardRule = new NormalRule();
forwardRule.setFrom( "^/jaco" );
SetAttribute attribute = new SetAttribute();
attribute.setName(Constants.CMS_FILTER_URI_OVERRIDE);
attribute.setValue("/blogs/fortune-brands-value-is-about-to-be-unleashed");
forwardRule.addSetAttribute(attribute);
addRewriteRule( forwardRule );

but it returns a 404 error.

curl -I https://demo.dotcms.com/jaco

HTTP/2 404 

set-cookie: JSESSIONID=87C63810FB8FD830FC4F9B57D25EF331.455ec36a0a64; Path=/; Secure; HttpOnly

set-cookie: opvc=af2d99b9-41a9-47ad-988a-37ca8afcf1ba; Path=/

set-cookie: sitevisitscookie=1; Max-Age=153792000; Expires=Tue, 27-Aug-2024 15:15:43 GMT; Path=/

set-cookie: dmid=86abbbfd-ccba-4dda-997f-3f0e73baa925; Max-Age=153792000; Expires=Tue, 27-Aug-2024 15:15:43 GMT; Path=/

set-cookie: dmid=20459810-ae10-478e-a6d8-401ab92b25cd; Max-Age=153792000; Expires=Tue, 27-Aug-2024 15:15:43 GMT; Path=/

content-type: text/html;charset=UTF-8

date: Sun, 13 Oct 2019 15:15:43 GMT

set-cookie: BACKENDID=172.18.0.3; path=/

cache-control: private

[Falzone, Chris]

So, I wasn't aware of the Vanity URL issue because we actually use Tuckey Rewrite Rules for all of our URLMapping.  The urlmaps we have need to work across different sites using different url patterns for each site.  The stock urlmapping doesn't handle this scenario.  It does look like Will has reopened the ticket and removed the won't fix, so they are looking into it now.  The bigger issue with using Vanity URLs is that they do not pass on url parameters.  

That being said, Check your filter order in web.xml to make sure that the URLRewriteFilter is firing before anything else, that is almost always the issue when tucky rules are not working properly.  If any of the dotcms filters are before URLRewriteFilter, they will stop the filter chain before it ever reaches your rule processing.  The only way to correct this order is to provide a custom ROOT file override in a static plugin (or modify the file directly which would be a bad idea).  

I haven't looked into it yet, but it also possible that the Rules Engine in dotCMS may handle some of this type of work as well. And lastly, this sort of url rejiggering can (and maybe should) happen before the request ever makes it to the dotCMS server.  For example an haproxy/nginx/apache server in front of dotCMS that handles stuff like SSL Cert termination, some sort of WAF solution, and url rewriting and forwarding.  

Hope it helps.

--
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/746a6905-5b4e-4709-9c7d-74d0007a6495%40googlegroups.com.

--

Christopher Falzone / Web Developer
https://aquent.com

[Alex]

Dear Chris:

Thank you for your in-depth response.

I have three instances of dotCMS behind the same firewall and proxy.  The 4.0.1 instance uses VanityURLs and all the VanityURLs set to send a 200 return to urlMap content items work well.

The 5.1.6 instance does not.  I tested with a static plugin moving UrlRewriteFilter  one position up to its original until it got to be the top of the list above the InterceptorFilter and I got the same issue.  I think it has to do with the URLMapFilter because the only time the forward does not work is when it is a forward to a UrlMapContent item.  For other pages or folders the forward works perfectly.

So you think it is best that I get all these url forwards into Nginx rather than dotCMS?

Regards,

Alex

To unsubscribe from this group and stop receiving emails from it, send an email to dot...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/dotcms/746a6905-5b4e-4709-9c7d-74d0007a6495%40googlegroups.com.

[Lex Medeiros]

Dear Chris:

I ended up replacing all my vanity urls that point to a urlmap by using our reverse proxy server.  

In case someone wonders how to do it, you just need to add a location block (see example below) into your nginx configuration.

~ means case insensitive

^ means begins with

? means with or without "/"

Note: You need to rewrite the uri in the block because you can not pass a uri on the proxy_pass directive.

For further reading:  https://stackoverflow.com/questions/21662940/nginx-proxy-pass-cannot-have-uri-part-in-location/21680744#21680744

location ~ ^/vanityURL/? {

     rewrite ^/desireURLMapContentURL$1;

    proxy_pass http://YOUR.IP. ADDRESS:YOURPORTNUMBER;

}

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/11b39664-f0fa-4071-8065-9deac4d1ae6f%40googlegroups.com.

[Falzone, Chris]

Was just thinking about this ...

you have a urlmap to something like ... /content-type-a/{url-title}

this urlmap is handled by some page like .. /content-type-a-detail-page

Then you have a vanity url like .. /other/{url-title}
Which forwards requests to /content-type-a/{url-title} <-- this part doesn't work

Instead of that why not make the vanity url go directly to the detail page?  You'll have to change some code in your detail page to make it work, but it would resolve the issue I think.

IOW, forward the vanity url to /content-type-a-detail-page?url-title={url-title}

Then in your code for the detail page ...
#if($UtilMethods.isSet($request.getParameter('url-title')
  #set($contentlist = $dotcontent.pull("...Pull content type a by url-title field...", ...))

  #if($contentlist.size() > 0)
    #set($URLMapContent = $contentlist.get(0))
  #end

#end

This way your detail page can handle both urlMapped content and a url parameter.  Thus working around the issue.  This same workaround would also work with Tuckey URLRewriteFilter Rules.

Make sense?

To view this discussion on the web visit https://groups.google.com/d/msgid/dotcms/CABzdpQmecW0hhck%3DbhHLqpeMn3BTem55FG3N04WQZuALKADQUA%40mail.gmail.com.

[Lex Medeiros]

Dear Chris:

That is a great idea!  I have not thought about it in that way.

Alex

To view this discussion on the web visit https://groups.google.com/d/msgid/dotcms/CAMAbHgWBckN0aZc%2B7NkieBfpLHUe00OU27e2Q3xY3d9mokW9EA%40mail.gmail.com.