[MGNLIMG-240] error page 500 Created: 15/Apr/21  Updated: 18/Oct/22  Resolved: 17/Mar/22

Status: Closed
Project: Imaging
Component/s: None
Affects Version/s: None
Fix Version/s: 3.5.3

Type: Bug Priority: Neutral
Reporter: Tomáš Gregovský Assignee: Jesus Alonso
Resolution: Fixed Votes: 6
Labels: VN-Testing
Remaining Estimate: Not Specified
Time Spent: 50m
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Task DoD:
[X]* Doc/release notes changes? Comment present?
[X]* Downstream builds green?
[X]* Solution information and context easily available?
[X]* Tests
[X]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:
Epic Link: AuthorX Maintenance
Sprint: AuthorX 5
Story Points: 1

 Description   

Originally reported one of our client, we provided fix but I believe this should be handled ootb by Magnolia:

 

Story:

Checking logs of live projects, we are maintaining in-house, all of them contains ERRORs 500. Most of them due to wrong links to imaging. There is recognised pattern which has cut original link and adds there dots ... at the end of it. for example:

https://demopublic.magnolia-cms.com/.imaging/mte/travel-demo-theme/1600x1200/dam/tours/flickr-surfer-mandolin-3730...

we are sure these are not generated by our templates but are more probably caused some external indexing robots, pages with links, etc.... and so we can't fix these links.

Anyway in this case of accessing mentioned link above, magnolia throws status 500 error with ugly stack trace.

  1. this is heavily spamming the logs
  2. shows magnolia's vulnerability for possible attacker

 

Possible fix:

similarly like 404 page, this piece of code should be added to web.xml:

<error-page>    
<error-code>500</error-code>    
<location>/docroot/500.html</location>  
</error-page>

plus some simple template in docroot itself.

 

Would be nice if Magnolia has this error handling already build in. Thank you.

 



 Comments   
Comment by Michael Duerig [ 02/Mar/22 ]

While I think it is a good idea to add error pages to `web.xml`, in this specific case we should also fix imaging. Accessing an non existing URL should not cause a 500 but a http status from the 400 range. E.g. a 404.

Comment by Jesus Alonso [ 16/Mar/22 ]

ImagingServlet is prepared for responding with a 404. The problem is simply that is expecting an ImagingException, but is receiving instead an UncheckedExecutionException which contains the ImagingException

Generated at Mon Feb 12 02:13:38 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.